Örnek sorular
Gcp Iam SecurityZorluk 1
GCP'nin kaynak hiyerarşisinde, yukarıdan aşağıya doğru içerme sırası nedir?
- aFolder > Organization > Project > Resource
- bOrganization > Folder > Project > Resource✓
- cProject > Organization > Folder > Resource
- dOrganization > Project > Folder > Resource
Açıklama:GCP'nin kaynak hiyerarşisi en üstte Organization ile başlar, sıfır veya daha fazla Folder içerir, bunlar da Project'leri içerir, onlar da tekil kaynakları (VM, bucket vb.) içerir. Folder, Organization ile Project arasında opsiyonel bir gruplama düğümüdür, tersi değil.
Gcp Iam SecurityZorluk 1
Bir IAM allow policy, Folder seviyesinde roles/viewer veriyor. Bu Folder içindeki Project'lere varsayılan olarak ne olur?
- aİzin, Folder içindeki tüm Project'lere ve kaynaklarına miras yoluyla uygulanır✓
- bHiçbir şey olmaz; IAM policy'leri asla ayarlandıkları seviyenin altına uygulanmaz
- cHer Project'in etkili olması için aynı role'ü ayrıca yeniden vermesi gerekir
- dPolicy yalnızca Folder'ın kendi metadata'sına uygulanır, içindeki Project'lere değil
Açıklama:GCP IAM allow policy'leri kaynak hiyerarşisinde aşağıya doğru miras alınır: Folder seviyesindeki bir binding, altındaki her Project'e ve kaynağa, her alt seviyede yeniden verilmesine gerek kalmadan otomatik olarak uygulanır.
Gcp Iam SecurityZorluk 2
Bir ekip, bir Project'in üst Folder'ının allow policy'sinden miras aldığı bir izni, yalnızca Project'in kendi IAM policy'sini düzenleyerek kaldırmak istiyor. Bu mümkün mü?
- aEvet, binding'i Project'in policy'sinden kaldırmak her zaman miras alınanı geçersiz kılar
- bEvet, ama yalnızca predefined role'ler için, custom role'ler için değil
- cHayır — üst düzey erişimi Project allow policy'siyle kaldırılamaz; IAM Deny policy gerekir✓
- dHayır, miras alınan izinler hiçbir koşulda hiçbir seviyede iptal edilemez
Açıklama:Sıradan IAM allow policy'leri hiyerarşi boyunca yalnızca eklemeli çalışır — bir alt düzeyin kendi allow policy'sini düzenlemek, bir üst düzeyin verdiği erişimi söküp alamaz. Üst-düzey izinlerden bağımsız olarak erişimi açıkça engellemek için GCP ayrı bir mekanizma (IAM Deny policy) sunar, allow policy'nin kendisine güvenilmez.
Gcp Iam SecurityZorluk 1
GCP'de predefined IAM role ile custom IAM role arasındaki farkı en iyi ne açıklar?
- aPredefined role'ler yalnızca Project'lere uygulanabilir; custom role'ler yalnızca Organization'lara uygulanabilir
- bCustom role'ler, Google benzer bir predefined role'e her yeni izin eklediğinde otomatik olarak o izinleri kazanır
- cPredefined role'ler service account'lara bağlanamaz, yalnızca custom role'ler bağlanabilir
- dPredefined role'leri Google yönetir ve zamanla değiştirebilir; custom role'ler yalnızca elle güncellenir✓
Açıklama:Predefined role'ler (ör. roles/compute.viewer) Google tarafından yönetilir ve izin kümeleri zamanla Google tarafından güncellenebilir. Custom role'ler, kullanıcının desteklenen bir listeden kendi tam izin kümesini derlemesine izin verir ve biri custom role tanımını elle düzenlemedikçe o küme sabit kalır.
Gcp Iam SecurityZorluk 2
Bir ekip yalnızca storage.objects.get ve storage.objects.list içeren bir custom role oluşturuyor. Bugün aynı iki izne sahip predefined role roles/storage.objectViewer'ı vermeye kıyasla, pratik trade-off nedir?
- aCustom role'ün izinleri otomatik değişmez; predefined role'e yeni izin eklenirse elle güncellenmesi gerekir✓
- bHiç fark yoktur; GCP aynı izinlere sahip custom role'leri eşleşen predefined role'ün takma adı gibi ele alır
- cCustom role, policy-check anında predefined role'den her zaman daha maliyetli değerlendirilir
- dCustom role'ler yalnızca kullanıcılara verilebilir, predefined role'lerin aksine service account'lara asla verilemez
Açıklama:Bir custom role, predefined bir role ile tam olarak aynı izinlerle başlasa bile, ayrı ve statik bir tanımdır. Google predefined role'lerin izin kümesini zamanla değiştirebilir; custom role, biri elle güncelleyene kadar tanımlandığı gibi kalır — bu, custom role kullanmanın gerçek süregelen bakım maliyetidir.
Gcp Iam SecurityZorluk 2
Neden her IAM izni bir custom role'e dahil edilemez?
- aCustom role'lerin role başına sabit bir 5 izin sınırı vardır
- bYalnızca 3'ten az predefined role tarafından kullanılan izinler custom role için uygundur
- cYalnızca Google'ın custom role kullanımını desteklediğini belirttiği izinler eklenebilir✓
- dHer izin dahil edilebilir; custom role kompozisyonuna hiçbir kısıtlama yoktur
Açıklama:Google, custom role'leri destekleyen izinlerin bir listesini yayınlar. Tüm izinler uygun değildir — bazıları belirli predefined-role semantiğine veya parça parça açığa çıkarılması mantıklı olmayan iç uygulama detaylarına bağlıdır, bu yüzden custom role'ler yalnızca o desteklenen alt kümeden derlenebilir.