yoklainterview sim

DevOps / Cloud Azure Iam Security Interview Questions

75 verified DevOps / Cloud Azure Iam Security interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Azure Iam SecurityDifficulty 1
What is the correct top-to-bottom scope order in Azure's RBAC hierarchy?
  • aSubscription > Management Group > Resource Group > Resource
  • bManagement Group > Subscription > Resource Group > Resource
  • cResource Group > Subscription > Management Group > Resource
  • dManagement Group > Resource Group > Subscription > Resource
Explanation:Azure's scope hierarchy runs Management Group at the top (grouping subscriptions), then Subscription, then Resource Group, then individual Resource. A role assigned at a higher scope is inherited by everything nested below it.
Azure Iam SecurityDifficulty 1
A role is assigned at the Resource Group scope. What happens to resources inside that group?
  • aThe role is inherited; every resource in the group grants that access automatically
  • bNothing; each resource needs a separate role assignment to get any access
  • cOnly resources created after the assignment inherit the role
  • dThe role only applies to the group's own metadata, not resources inside it
Explanation:Azure RBAC role assignments are inherited downward through the scope hierarchy: a role granted at the Resource Group level automatically applies to every resource nested in that group, existing or newly created, without needing a separate assignment per resource.
Azure Iam SecurityDifficulty 1
Which built-in Azure role grants full management access to resources but does NOT allow granting access to others?
  • aOwner
  • bReader
  • cContributor
  • dUser Access Administrator
Explanation:Contributor grants full create/read/update/delete rights over resources but explicitly excludes the ability to manage access (assign roles) — that permission is reserved for Owner and User Access Administrator.
Azure Iam SecurityDifficulty 1
What is the main practical difference between a system-assigned and a user-assigned Managed Identity?
  • aUser-assigned identities cannot authenticate to Azure AD at all
  • bSystem-assigned identities support more resource types than user-assigned
  • cThere is no difference; both terms describe the exact same feature
  • dA system-assigned identity's lifecycle is tied to its resource
Explanation:A system-assigned Managed Identity is created and deleted together with the resource it's attached to (1:1 lifecycle). A user-assigned Managed Identity is its own independent Azure resource with its own lifecycle, and can be attached to multiple resources at once.
Azure Iam SecurityDifficulty 2
Why do teams prefer Managed Identity over a service principal with a client secret for a VM calling Key Vault?
  • aManaged Identity works across every cloud provider, not just Azure
  • bManaged Identity removes the need to store and rotate a credential in code or config
  • cService principals cannot be granted access to Key Vault at all
  • dManaged Identity grants Owner rights on every resource by default
Explanation:Managed Identity's core value is eliminating credential management: Azure handles authentication to Entra ID and token issuance automatically, so there's no client secret or certificate to store, rotate, or leak. A regular service principal still requires a manually managed credential.
Azure Iam SecurityDifficulty 2
In Azure Key Vault's access-control model, what does enabling the "Azure RBAC" permission model (instead of "Vault access policy") change?
  • aAccess is granted using standard Azure role assignments (like Key Vault Secrets User) scoped to the vault, instead of vault-specific access policy entries
  • bIt disables all access to secrets until a new vault is created
  • cIt only changes how keys are stored internally, not who can access them
  • dIt makes the vault accessible to any authenticated Azure AD user by default
Explanation:Key Vault supports two mutually exclusive permission models: the legacy vault access policy (a list embedded in the vault resource) and the Azure RBAC model, where access is granted via standard role assignments (e.g., Key Vault Secrets User, Key Vault Crypto Officer) at the vault or higher scope, consistent with how RBAC works for other Azure resources.

Test yourself against the 3375-question DevOps / Cloud bank.

Start interview