yoklateknik mülakat

DevOps / Cloud Azure Iam Security Mülakat Soruları

75 doğrulanmış DevOps / Cloud Azure Iam Security mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Azure Iam SecurityZorluk 1
Azure RBAC hiyerarşisinde yukarıdan aşağıya doğru kapsam sırası nedir?
  • aSubscription > Management Group > Resource Group > Resource
  • bManagement Group > Subscription > Resource Group > Resource
  • cResource Group > Subscription > Management Group > Resource
  • dManagement Group > Resource Group > Subscription > Resource
Açıklama:Azure'un kapsam hiyerarşisi en üstte Management Group (subscription'ları gruplar), sonra Subscription, sonra Resource Group, sonra tekil Resource şeklinde ilerler. Daha üst bir kapsamda atanan bir rol, altındaki her şey tarafından miras alınır.
Azure Iam SecurityZorluk 1
Bir rol Resource Group kapsamında atanıyor. Grup içindeki kaynaklara ne olur?
  • aRol miras alınır; gruptaki her kaynak o erişimi otomatik olarak tanır
  • bHiçbir şey; her kaynağın erişim alması için ayrı bir rol ataması gerekir
  • cYalnızca atamadan sonra oluşturulan kaynaklar rolü miras alır
  • dRol yalnızca grubun kendi metadata'sına uygulanır, içindeki kaynaklara değil
Açıklama:Azure RBAC rol atamaları kapsam hiyerarşisinde aşağıya doğru miras alınır: Resource Group seviyesinde verilen bir rol, o grup içindeki her kaynağa (mevcut ya da yeni oluşturulan), kaynak başına ayrı atamaya gerek kalmadan otomatik olarak uygulanır.
Azure Iam SecurityZorluk 1
Kaynaklara tam yönetim erişimi veren ama BAŞKALARINA erişim vermeye izin vermeyen yerleşik Azure rolü hangisidir?
  • aOwner
  • bReader
  • cContributor
  • dUser Access Administrator
Açıklama:Contributor, kaynaklar üzerinde tam oluşturma/okuma/güncelleme/silme hakkı verir ama erişim yönetme (rol atama) yeteneğini açıkça hariç tutar — bu izin Owner ve User Access Administrator'a ayrılmıştır.
Azure Iam SecurityZorluk 1
System-assigned ve user-assigned Managed Identity arasındaki temel pratik fark nedir?
  • aUser-assigned identity'ler Azure AD'ye hiç kimlik doğrulayamaz
  • bSystem-assigned identity'ler user-assigned'dan daha fazla kaynak tipini destekler
  • cFark yoktur; ikisi de aynı özelliği tanımlar
  • dSystem-assigned identity'nin yaşam döngüsü bağlı olduğu kaynakla eşleşir, user-assigned identity ise birden fazla kaynağa bağlanabilen bağımsız bir kaynaktır
Açıklama:System-assigned bir Managed Identity, bağlı olduğu kaynakla birlikte oluşturulur ve silinir (1:1 yaşam döngüsü). User-assigned bir Managed Identity ise kendi yaşam döngüsüne sahip bağımsız bir Azure kaynağıdır ve aynı anda birden fazla kaynağa bağlanabilir.
Azure Iam SecurityZorluk 2
Key Vault'u çağıran bir VM için ekipler neden client-secret'lı bir service principal yerine Managed Identity'i tercih eder?
  • aManaged Identity yalnızca Azure'da değil her bulut sağlayıcısında çalışır
  • bManaged Identity, kod veya config'de bir credential saklama ve rotate etme ihtiyacını ortadan kaldırır
  • cService principal'lara Key Vault erişimi hiç verilemez
  • dManaged Identity varsayılan olarak her kaynakta Owner hakkı verir
Açıklama:Managed Identity'nin temel değeri credential yönetimini ortadan kaldırmasıdır: Azure, Entra ID'ye kimlik doğrulamayı ve token verilmesini otomatik olarak halleder, bu yüzden saklanacak/rotate edilecek/sızabilecek bir client secret veya sertifika yoktur. Sıradan bir service principal hâlâ elle yönetilen bir credential gerektirir.
Azure Iam SecurityZorluk 2
Azure Key Vault'un erişim-kontrol modelinde, ('Vault access policy' yerine) 'Azure RBAC' izin modelini etkinleştirmek neyi değiştirir?
  • aErişim, vault'a özgü access policy girdileri yerine, vault kapsamındaki standart Azure rol atamaları (Key Vault Secrets User gibi) kullanılarak verilir
  • bYeni bir vault oluşturulana kadar secret'lara tüm erişimi devre dışı bırakır
  • cYalnızca key'lerin dahili olarak nasıl saklandığını değiştirir, kimin erişebileceğini değil
  • dVault'u varsayılan olarak herhangi bir kimlik doğrulanmış Azure AD kullanıcısına erişilebilir yapar
Açıklama:Key Vault iki birbirini dışlayan izin modelini destekler: eski vault access policy (vault kaynağına gömülü bir liste) ve Azure RBAC modeli, burada erişim vault veya daha üst kapsamda standart rol atamaları (ör. Key Vault Secrets User, Key Vault Crypto Officer) ile verilir, diğer Azure kaynaklarında RBAC'ın çalışma şekliyle tutarlı biçimde.

3375 soruluk DevOps / Cloud bankasında kendini sına.

Mülakata başla