Google PCA: Organizasyon Tasarımı, IAM ve Bulut Yönetişimi — Çalışma kılavuzu

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Architect — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Kuruluş tasarımı, IAM ve yönetişim, tüm Google Cloud mimarilerinin üzerinde çalıştığı temeli oluşturur. İyi tasarımlar, net idari sınırlar oluşturur, etki alanını en aza indirir, en az ayrıcalık ilkesini mümkün kılar, maliyeti kontrol eder ve birçok ekip ve ortamda operasyonel olarak ölçeklenir. Yönetişim, yasaklayıcı denetimler yerine yönlendirici kuralları vurgulamalıdır: güvenli, ölçülebilir ve geri alınabilir varsayılanları otomatikleştirirken, günlük kontrolü iş yüküne en yakın ekiplere devretmelidir.

Kaynak Hiyerarşisi ve Kimlik Temelleri

Google Cloud kaynakları katı bir ağaç yapısı oluşturur: Kuruluş → Klasörler → Projeler → Kaynaklar (örneğin, Compute Engine örnekleri, bucket’lar). IAM politikaları ve Kuruluş Politikası kısıtlamaları ağaç yapısında aşağı doğru miras alınır.

Temel tasarım ilkeleri:

Yönetişimi merkezileştirmek için tek bir Kuruluş kullanın. Büyük idari sınırlar (örneğin, iş birimleri, bölgeler veya düzenlemeye tabi olan ve olmayanlar) için üst düzey Klasörler oluşturun.
Her sınır içinde, farklılaştırılmış politikalar uygulamak için ortam Klasörleri (üretim, üretim dışı) oluşturun. Etki alanını azaltmak ve maliyet yansıtmayı kolaylaştırmak için projeleri mümkün olduğunca iş yükü odaklı ve geçici tutun.
Miras: izin atamaları birikir (üst öğelerden ve düğümün kendisinden gelen izin bağlamalarının birleşimi). IAM Reddetme politikaları, eğer kullanılıyorsa, öncelikli olur ve bir izin olsa bile erişimi engelleyebilir. Ağaç yapısında üst seviyelere geniş roller yerleştirmekten kaçının; etki alanı büyüktür ve geri alınması zordur.

Kimlik kaynakları:

Cloud Identity, iş gücü kimlik düzlemidir. Kimlik doğrulama ve yaşam döngüsünü (işe başlayanlar, pozisyon değiştirenler, ayrılanlar) merkezileştirmek için kurumsal IdP’nizle (SAML/OIDC) entegre olun. Gerekirse nitelik ve grup senkronizasyonu için Google Cloud Directory Sync kullanın.
Gruplar, birincil IAM özneleridir. Grup tabanlı erişim, ölçeklenebilir değişiklikler ve denetlenebilir sahiplik sağlar. Bir gruplar grubu deseni (örneğin, net-admins, sec-admins, app-team-A) kullanın ve grup üyeliğini kimin yönetebileceğini kısıtlayın.
Hizmet hesapları iş yüklerini temsil eder. Saklanan anahtarlar yerine kısa ömürlü kimlik bilgileriyle hizmet hesabı kimliğine bürünmeyi tercih edin. Kullanıcı tarafından yönetilen hizmet hesabı anahtarlarından kaçının; bunları sıkı onaylar ve rotasyon gerektiren istisnalar olarak ele alın.
İş yükü kimlik desenleri:
- GKE Workload Identity, Kubernetes hizmet hesaplarını Google hizmet hesaplarına bağlar; düğüm genelindeki kimlik bilgilerini ortadan kaldırır.
- Workload Identity Federation, harici kimliklerin (şirket içi, diğer bulutlar, GitHub Actions) anahtarlar olmadan kısa ömürlü Google erişimi elde etmesini sağlar. Erişimi kısıtlamak için havuz/sağlayıcı kapsamlandırması ve nitelik koşulları kullanın.

Yaygın hata modları ve azaltma yöntemleri:

Klasör veya Kuruluş düzeyinde ilkel roller (Owner/Editor/Viewer) atamak, yaygın aşırı yetkilendirmeye yol açar. Yalnızca sıkı bir şekilde kapsamlandırılmış acil durum projelerinde kullanın.
Belirsiz sahipliğe sahip grup karmaşası, en az ayrıcalık ilkesini zayıflatır. Gruplarda adlandırma, amaç etiketleri ve sahip meta verilerini zorunlu kılın.
Sahipsiz hizmet hesapları ve eski bağlamalar risk biriktirir. Yinelenen erişim gözden geçirmeleri planlayın ve kullanılmayan izinleri azaltmak için IAM Recommender’ı kullanın.

IAM Modelleri, Rolleri ve Erişim İşlemleri

Roller ve bağlamalar:

Önceden tanımlanmış roller, belirli hizmetler için özel olarak hazırlanmıştır ve varsayılan seçenek olmalıdır.
Özel roller, önceden tanımlanmış rollerin çok genel kaldığı durumlardaki boşlukları doldurur. Gerekli olduğu gözlemlenen minimum izin setinden oluşturun; bunları versiyonlayın ve test edin.
Temel roller (Viewer/Editor/Owner) eski ve aşırı geniştir. Kuruluş ve Klasör kapsamlarında kaçının. Günlük operasyonlar için Owner kullanmayın; güçlü telafi edici kontrollerle platform acil durumları için ayırın.
Koşullu rol bağlamaları (IAM Koşulları), bir bağlamanın ne zaman ve nerede uygulanacağını resource.name, resource.matchTag, request.time veya request.auth.audiences gibi nitelikleri kullanarak kısıtlar. Zaman sınırlı erişim, üretime etiket kapsamlı erişim veya konum kısıtlamalı eylemler için koşulları kullanın.

En az ayrıcalık ve yetki yükseltme:

“Okuma”, “işletme” ve “yönetme” görevlerini ayırın. Örneğin, ağ, güvenlik ve uygulama ekipleri farklı kapsamlarda farklı roller alır.
Koşullar aracılığıyla zaman sınırlı rolleri bağlamak için Access Approval iş akışları veya talep tabanlı otomasyon ile tam zamanında yetki yükseltme kullanın.

Reddetme politikaları ve tehlikeleri:

IAM Deny, riskli izinleri (örneğin, resourcemanager.projects.delete) merkezi olarak engelleyebilir. Reddetme, izni geçersiz kılar ve tüm alt ağaca uygulanır. Kapsamlı bir şekilde doğrulayın; yanlış yapılandırılmış reddetmeler otomasyonu kilitleyebilir veya dağıtımları bozabilir.

Denetlenebilirlik ve gözden geçirmeler:

Kuruluş düzeyinde Yönetici Etkinliği günlüklerini etkinleştirin; bunlar varsayılan olarak 400 gün saklanır. Hassas hizmetler için Veri Erişimi günlüklerini etkinleştirin ve uzun süreli saklama ve denetim için bunları BigQuery’ye yönlendirin.
Periyodik erişim gözden geçirmeleri uygulayın: Cloud Asset Inventory ile bağlamaları listeleyin, sahiplik kayıtlarıyla karşılaştırın, IAM Recommender tarafından önerilen kullanılmayan rolleri kaldırın ve istisnaların sona erme tarihlerini doğrulayın.

Faydalı örnek (zaman sınırlı, etiket kapsamlı bağlama):

gcloud projects add-iam-policy-binding PROJECT_ID –member=“group:prod-ops@example.com” –role=“roles/compute.instanceAdmin.v1” –condition=‘title=ProdOnlyTemp,expression=resource.matchTag(“organizations/1234567890/env”,“prod”) && request.time < timestamp(“2026-01-01T00:00:00Z”)’

Finansal Yönetişim ve Organizasyon Politikası Korumaları

Faturalandırma mimarisi:

Bir veya daha fazla faturalandırma hesabını Finans departmanının sahipliğinde merkezileştirin. Yalnızca yasal veya operasyonel olarak gerekli olduğunda (örneğin, ayrı tüzel kişilikler veya bayi modelleri) birden fazla faturalandırma hesabı kullanın.
Projeleri faturalandırma hesaplarına otomasyon aracılığıyla bağlayın; onaylanmış iş akışları dışında manuel bağlamaya izin vermeyin.

Maliyet Yansıtma ve maliyet görünürlüğü:

Etiketleri (labels) ve maliyet ayırma etiketlerini (cost allocation tags) tutarlı bir şekilde kullanın. Etiketler, filtreleme ve raporlama için serbest biçimli meta verilerdir; etiketler (tags) ise hiyerarşiktir ve IAM Koşullarında (Conditions) ve politikalarda kullanılabilir. Seçilen etiketlerin faturalandırma dökümlerinde görünmesi için maliyet ayırmayı etkinleştirin.
Analiz için faturalandırma verilerini BigQuery’ye aktarın; sahip, maliyet merkezi ve ortama göre gösterge tabloları (dashboard) oluşturun. Her projenin sorumlu bir sahibi ve bütçesi olmasını zorunlu kılın.

Bütçeler ve anomali tespiti:

Klasör (Folder) ve proje seviyelerinde uyarılar içeren bütçeler oluşturun. Kontrolsüz harcamaları engellemek için programatik tepkiler (örneğin, nöbetçiyi bilgilendirme, talep (ticket) açma veya yeni kota artışlarını devre dışı bırakma) ekleyin.
Beklenen kullanımla uyumlu Kotalar (Quotas) ve taahhütler (CUDs) kullanın; kullanımı izleyin.

Kuruluş Politikası kısıtlamaları (varsayılan olarak güvenli):

Korumaları Kuruluş (Organization) veya Klasör (Folder) düzeyinde uygulayın ve yalnızca gerekçelendirildiğinde esnetin. Yaygın kısıtlamalar:
- constraints/iam.disableServiceAccountKeyCreation = true
- constraints/compute.requireOsLogin = true
- constraints/compute.trustedImageProjects ile VM imajlarını kısıtlama
- constraints/sql.restrictPublicIp = true
- constraints/storage.uniformBucketLevelAccess = true
- constraints/compute.disableSerialPortAccess = true
Hassas çevrelerdeki (perimeters) desteklenen hizmetler için veri sızdırma riskini azaltmak amacıyla VPC Service Controls kullanın.

Politika istisna yönetimi:

İstisnalar talep edilebilir, onaylanmış, zaman sınırlı ve denetlenebilir olmalıdır. İstisnaları etikete (tag)/zamana göre kapsamlandırmak için IAM Koşullarını (Conditions) tercih edin.
İstisnaları periyodik olarak mutabık kılın ve kod olarak politika (policy-as-code) işlem hatları (pipelines) aracılığıyla otomatik olarak sona ermelerini sağlayın.

Hizmet hesabı anahtarlarını devre dışı bırakmak için örnek Kuruluş Politikası (YAML):

name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
- enforce: true Ardından uygulayın: gcloud org-policies set-policy policy.yaml

Tüm alanlar · Compute →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →