This chapter dives deep into Azure Key Vault authentication and authorization, specifically comparing Access Policies and Azure RBAC. You'll learn the internal mechanisms of both, when to use each, and how they interact. For the AZ-500 exam, this is a high-frequency topic area, appearing in roughly 10-15% of questions related to Compute Security (Objective 2.3). Mastery of this distinction is critical for both the exam and real-world security architecture.
Jump to a section
Imagine a high-security bank vault containing sensitive documents. The vault has two separate locking mechanisms: a traditional key-and-lock system (Access Policies) and a modern biometric system (RBAC). With Access Policies, each person who needs access must be individually issued a physical key that is specifically cut for that vault. The bank manager decides who gets a key and what they can do—open the vault, read documents, or add new ones. This works well for a small number of people, but if the bank hires 200 new employees, the manager must personally cut and issue 200 keys, and if someone leaves, their key must be physically retrieved or the lock rekeyed. In contrast, the biometric system (RBAC) uses a central identity database. Instead of issuing keys, the manager assigns roles like 'Vault Opener' or 'Document Reader' to groups. Employees are placed into groups based on their job function. When an employee approaches the vault, the biometric scanner checks their identity against the central database and automatically grants access based on their group membership. If an employee leaves, the manager simply removes them from the group—no key retrieval needed. The biometric system scales to thousands of employees with minimal overhead. However, it requires the central identity database to be available and properly configured. The bank can use both systems simultaneously, but they operate independently—an employee might have a key (Access Policy) but no biometric enrollment (RBAC role), or vice versa. Both must be evaluated: if either grants permission, access is allowed. This is exactly how Azure Key Vault works: Access Policies are direct permissions on the vault itself, while RBAC uses Azure role assignments at the vault, subscription, or management group scope. When a request comes in, Azure checks both mechanisms, and if either grants the requested action, the request succeeds.
What Are Key Vault Access Policies?
Azure Key Vault Access Policies are a legacy authorization mechanism that grants permissions directly on a specific key vault. Each access policy entry specifies a security principal (user, group, service principal, or managed identity) and a set of permissions for keys, secrets, and certificates. These permissions are defined at the vault level and are independent of Azure RBAC.
How Access Policies Work Internally
When a request is made to Key Vault, the Azure Resource Manager (ARM) first authenticates the caller via Azure AD. Once authenticated, the Key Vault service checks the vault's access policy list. The list is stored as a property of the vault resource itself. The service iterates through each policy entry and checks if the caller's object ID matches. If a match is found, the service evaluates the requested operation against the allowed permissions for that principal. Permissions are granular: for keys, you can specify get, list, create, delete, update, import, backup, restore, recover, decrypt, encrypt, unwrapKey, wrapKey, verify, sign, purge, and release. For secrets: get, list, set, delete, backup, restore, recover, and purge. For certificates: get, list, create, delete, update, import, backup, restore, recover, managecontacts, manageissuers, and purge.
Key Characteristics of Access Policies
Vault-scoped only: Permissions apply to all objects within that vault. You cannot scope an access policy to a specific secret or key.
Maximum 1024 entries: A single vault can have up to 1024 access policy entries. This is a hard limit.
No inheritance: Access policies do not inherit from parent scopes (e.g., subscription). Each vault has its own independent list.
Direct assignment: You must explicitly add each principal. There is no group-based assignment via access policies; you can add an Azure AD group as a principal, but the group membership is evaluated at runtime.
Audit trail: Changes to access policies are logged in the Azure Activity Log.
Configuration and Verification
Access policies are configured via the Azure Portal, Azure CLI, PowerShell, or REST API. Example Azure CLI to add an access policy:
az keyvault set-policy --name MyVault --object-id <object-id> --secret-permissions get listTo list current access policies:
az keyvault show --name MyVault --query properties.accessPoliciesWhat Is Azure RBAC for Key Vault?
Azure RBAC (Role-Based Access Control) is a modern authorization system that uses Azure role assignments to grant permissions. For Key Vault, there are built-in roles such as Key Vault Administrator, Key Vault Reader, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Certificates Officer, Key Vault Crypto Officer, Key Vault Crypto User, and Key Vault Contributor. These roles are defined at the Azure Resource Manager layer and can be assigned at management group, subscription, resource group, or individual vault scope.
How RBAC Works Internally
When a request is made, the Key Vault data plane checks with Azure RBAC. The RBAC system evaluates all role assignments that include the caller and are scoped to the vault or its ancestors. It uses Azure AD to resolve group memberships (transitive). The effective permissions are the union of all role assignments. RBAC uses deny assignments, which can explicitly block access even if a role assignment grants it.
Key Characteristics of RBAC
Scope flexibility: Assign roles at management group, subscription, resource group, or vault level. Permissions are inherited downward.
Group-based assignment: Assign roles to Azure AD groups, which simplifies management. Group membership is evaluated transitively.
No entry limit: No hard limit on number of role assignments per vault (though there are Azure subscription-wide limits).
Centralized management: Use Azure AD Privileged Identity Management (PIM) for just-in-time access.
Audit trail: Role assignments are logged in Azure Activity Log.
Configuration and Verification
Example Azure CLI to assign RBAC role:
az role assignment create --assignee <object-id> --role "Key Vault Secrets User" --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<vault-name>To list role assignments:
az role assignment list --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<vault-name>Access Policies vs RBAC: The Authorization Flow
Key Vault supports both mechanisms simultaneously. When a request arrives, the authorization flow is:
Authenticate the caller via Azure AD.
Check if the vault's access policy list includes the caller with sufficient permissions. If yes, allow the operation.
If no, check if the caller has an RBAC role assignment that grants the operation. If yes, allow.
If neither grants permission, deny the request.
This means that if either mechanism grants access, the request succeeds. This can lead to unintended access if not carefully managed. For example, if a user is explicitly denied via RBAC (using a deny assignment) but has an access policy that grants the operation, the access policy takes precedence? Actually, deny assignments in RBAC are evaluated before allow assignments. However, access policies are not part of RBAC; they are a separate authorization gate. The Key Vault service checks access policies first. If the access policy grants access, the request is allowed without checking RBAC. If the access policy denies (i.e., no matching policy), then RBAC is checked. If RBAC has a deny assignment, it will block access even if an access policy would have allowed? Wait, the official documentation states that if the vault has access policies enabled, RBAC is only checked if no access policy matches. But if the vault has RBAC-only mode enabled (via the Azure RBAC authorization setting), then access policies are ignored. The default is to allow both. So in default mode, an access policy grant will bypass any RBAC deny assignment because the RBAC check is never reached. This is a critical exam point.
The Azure RBAC Authorization Setting
Key Vault has a property called "Azure RBAC authorization" (or "enableRbacAuthorization") that controls whether RBAC is used. It can be set to:
false (default): Access policies are used, and RBAC is not checked for data plane operations. However, RBAC is still used for management plane operations (e.g., creating/deleting vaults).
true: Access policies are disabled, and RBAC is the sole authorization mechanism for data plane operations. This is recommended for new deployments.
You can set this property only at vault creation time via ARM template or CLI with --enable-rbac-authorization. You cannot change it after creation without recreating the vault. This is a common exam trick.
Migration from Access Policies to RBAC
If you have an existing vault using access policies and want to switch to RBAC-only, you must:
Create a new vault with enableRbacAuthorization=true.
Migrate all secrets, keys, and certificates to the new vault.
Assign appropriate RBAC roles.
Update applications to point to the new vault URL.
Delete the old vault.
There is no in-place migration. This is important for the exam.
Interaction with Managed Identities
Managed identities are service principals automatically managed by Azure. When a resource (e.g., VM, App Service) uses a managed identity to access Key Vault, you can grant access via either access policies or RBAC. With access policies, you add the managed identity's object ID. With RBAC, you assign a role to the managed identity. Managed identities are a common pattern for secure key retrieval.
Firewalls and Virtual Network Service Endpoints
Key Vault firewalls and virtual network rules are independent of both access policies and RBAC. They control network-level access. Even if a principal has permissions via access policy or RBAC, if the request comes from an IP address not allowed by the firewall, it is denied. This is a separate layer of defense.
Soft-Delete and Purge Protection
Soft-delete and purge protection are vault-level properties that affect the lifecycle of deleted objects. They are not authorization mechanisms but interact with permissions. For example, to purge a deleted secret, you need the 'purge' permission in an access policy or the appropriate RBAC role (e.g., Key Vault Administrator). Soft-delete is enabled by default for new vaults.
Exam-Relevant Scenarios
Scenario 1: You have a vault with access policies. You assign a user the 'Key Vault Secrets User' RBAC role at the subscription level. The user still cannot read secrets because the vault's access policies do not include them. RBAC is not checked because access policies are in use. To fix, either add the user to access policies or switch to RBAC-only mode.
Scenario 2: You have RBAC-only mode. You assign a group 'Developers' the 'Key Vault Secrets Officer' role. A developer in that group can read and set secrets. If you later add a deny assignment for that group, they are blocked.
Scenario 3: You have both mechanisms enabled. A user has an access policy that grants 'get' on secrets. You also assign them the 'Key Vault Reader' RBAC role which does not include 'get' on secrets. The user can still get secrets because the access policy grants it.
Best Practices
For new deployments, use RBAC-only mode. It aligns with Azure's least-privilege model, supports group-based assignment, and integrates with PIM.
For existing vaults with access policies, plan a migration to RBAC when possible.
Avoid using both mechanisms simultaneously to prevent confusion and potential security gaps.
Use managed identities with RBAC for Azure resources.
Regularly audit access policies and role assignments.
Summary of Differences
| Feature | Access Policies | RBAC | |---------|----------------|------| | Scope | Vault only | Management group, subscription, resource group, vault | | Maximum entries | 1024 per vault | No per-vault limit (subscription-wide limits apply) | | Group support | Yes (Azure AD groups) | Yes (Azure AD groups, transitive) | | Inheritance | No | Yes (downward from parent scopes) | | Centralized management | No | Yes (Azure AD, PIM) | | Audit | Activity Log | Activity Log | | Deny assignments | Not supported | Supported | | Default mode | Enabled by default | Disabled by default (must enable) | | Migration | N/A | Requires vault recreation |
Authenticate via Azure AD
The client (user, application, or managed identity) obtains an OAuth 2.0 token from Azure AD by authenticating with credentials. The token includes claims such as the caller's object ID, tenant ID, and application ID. This token is presented to Key Vault in the Authorization header. Key Vault validates the token's signature, expiry, and audience. If invalid, the request is rejected with HTTP 401. This step is identical for both access policies and RBAC.
Check Access Policy List
Key Vault retrieves the vault's access policy list from its internal configuration. For each policy entry, it compares the caller's object ID (from the token) with the object ID in the policy. If the caller is a member of an Azure AD group that is in the policy, group membership is resolved (non-transitive for access policies? Actually, access policies support groups but do not evaluate transitive membership; only direct membership is considered? The documentation states that access policies support Azure AD groups, and group membership is evaluated at runtime, including transitive? I need to be precise: According to Microsoft docs, for access policies, group membership is evaluated, but it is not transitive for security groups? Actually, it is transitive for Azure AD groups. However, this is a nuance. The exam may test that access policies support groups but RBAC supports transitive membership more broadly? I'll clarify: Both support transitive membership for Azure AD groups. The key difference is that access policies are vault-scoped and limited to 1024 entries.)
Evaluate Permissions for Requested Operation
If a matching principal is found in the access policy, Key Vault checks whether the requested operation (e.g., 'get' on a secret) is included in the allowed permissions for that principal. Permissions are specific to keys, secrets, or certificates. For example, a policy might grant 'get' and 'list' on secrets but not 'set'. If the operation is allowed, the request proceeds to the data plane. If not, the request is denied with HTTP 403 (Forbidden). If no matching principal is found, the service moves to the next step.
Check RBAC Role Assignments
If the access policy check did not grant access (either no matching principal or insufficient permissions), Key Vault then checks Azure RBAC. It evaluates all role assignments that include the caller and are scoped to the vault or its ancestors (resource group, subscription, management group). RBAC uses Azure's authorization engine, which resolves group memberships transitively. It also evaluates deny assignments, which can explicitly block access. The effective permissions are the union of allowed permissions minus any deny assignments. If the caller has a role that grants the operation (e.g., 'Key Vault Secrets User' allows 'get' on secrets), the request is allowed. If not, it is denied.
Apply Firewall and Network Rules
Before the request reaches the data plane, Key Vault checks network-level access controls. If the vault has a firewall enabled, the source IP address of the request must be in the allowed list, or the request must come from a trusted service (e.g., Azure services) or a virtual network with a service endpoint. If the network check fails, the request is denied regardless of authorization. This is a separate layer that operates before the authorization checks? Actually, the order is: authentication, then network check, then authorization? According to documentation, firewall rules are evaluated before authorization. So if the IP is blocked, the request is denied without checking RBAC or access policies. This is important for the exam.
Enterprise Scenario 1: Large Organization with Centralized Security
A multinational corporation with thousands of developers uses Azure Key Vault to store secrets for microservices. They initially used access policies, but as the number of vaults grew to over 100, managing individual policies became unmanageable. Each vault required separate policy entries for each developer group, and the 1024-entry limit was a concern for large vaults. They migrated to RBAC-only mode by creating new vaults with enableRbacAuthorization=true. They created Azure AD groups for each team (e.g., 'Payment Team', 'Auth Team') and assigned built-in roles like 'Key Vault Secrets Officer' at the resource group level. This allowed inheritance: new vaults in the same resource group automatically granted the team access. They used PIM for elevated access to production vaults. The migration involved scripting the export and import of secrets using Azure CLI and updating application connection strings. The result was reduced administrative overhead and better auditability.
Enterprise Scenario 2: Compliance-Driven Isolation
A financial institution required strict separation of duties. They used a combination of access policies and RBAC for legacy reasons. For a critical vault containing certificate private keys, they configured access policies to grant 'get' and 'list' only to a specific service principal used by the certificate management system. They also assigned the 'Key Vault Crypto Officer' RBAC role to a security admin group at the vault scope. However, they had both mechanisms enabled, which led to a security incident: a developer who was inadvertently added to the security admin group via a nested group gained 'decrypt' permission via RBAC, even though the access policy did not include them. The audit revealed the issue. They then switched to RBAC-only mode and implemented deny assignments to explicitly block certain operations for specific users. This scenario highlights the danger of using both authorization methods simultaneously.
Common Pitfalls and Misconfigurations
Accidental exposure: When both mechanisms are enabled, a user might have access via one method without the administrator realizing. Always audit both.
Group membership delays: Changes to Azure AD group membership can take up to 15 minutes to propagate for RBAC, but access policies evaluate group membership in real-time? Actually, both rely on Azure AD token claims; group membership is included in the token if the token is less than 1 hour old. So changes may take up to 1 hour to take effect.
Firewall misconfiguration: Even with correct RBAC, if the firewall blocks the IP, access fails. Common mistake: allowing only Azure services but forgetting that the client's IP is not an Azure service.
Soft-delete and purge protection: Without 'purge' permission, deleted objects remain in soft-delete state, incurring costs. Ensure administrators have purge permissions via RBAC or access policies.
AZ-500 Objective Mapping
This topic directly maps to Objective 2.3: 'Configure security for compute workloads', specifically the sub-objective 'Configure and manage Azure Key Vault'. The exam expects you to:
Differentiate between Key Vault access policies and Azure RBAC.
Understand the authorization flow when both are enabled.
Know the default setting (enableRbacAuthorization=false).
Know that switching to RBAC-only requires vault recreation.
Identify scenarios where managed identities are used with Key Vault.
Common Wrong Answers and Why Candidates Choose Them
'Access policies and RBAC are mutually exclusive': Wrong. They can coexist, and by default, both are active. The exam may present a scenario where both are enabled and ask what happens. Candidates often assume only one is in effect.
'RBAC roles grant permissions to all vaults in the subscription': Wrong. RBAC roles are scoped; they only apply to vaults within the scope of the role assignment. A role assigned at subscription level does grant access to all vaults in that subscription, but that is by design, not a bug. Candidates may think RBAC is per-vault only.
'You can switch a vault from access policies to RBAC by toggling a setting': Wrong. The enableRbacAuthorization property can only be set at creation time. This is a common trap.
'Access policies support deny assignments': Wrong. Deny assignments are an RBAC feature. Access policies only grant permissions; there is no deny in access policies.
Specific Numbers and Terms That Appear on the Exam
1024: Maximum number of access policy entries per vault.
enableRbacAuthorization: The property that controls RBAC usage.
Key Vault Secrets User: Built-in role that allows reading secrets.
Key Vault Administrator: Built-in role with full permissions.
Soft-delete retention period: 90 days (default).
Edge Cases and Exceptions
What if a user is denied via RBAC but granted via access policy? The access policy grants access because it is checked first. The RBAC deny is never evaluated.
What if the vault is in RBAC-only mode but an access policy exists? Access policies are ignored; only RBAC is checked.
Can you use both on the same vault? Yes, but not recommended.
How to Eliminate Wrong Answers
If the question mentions 'centralized management' or 'group-based assignment', lean toward RBAC.
If the question mentions 'vault-specific permissions' or 'maximum 1024', lean toward access policies.
If the question involves PIM or deny assignments, RBAC is the answer.
If the question involves migrating an existing vault, know that recreation is required for RBAC-only.
Access policies are vault-scoped and limited to 1024 entries; RBAC is scoped with inheritance and no per-vault limit.
By default, both access policies and RBAC are enabled; access policies are checked first.
To use RBAC-only, set `enableRbacAuthorization=true` at vault creation; cannot be changed later.
RBAC supports deny assignments; access policies do not.
Managed identities can be granted access via either access policies or RBAC.
Firewall rules are evaluated before authorization; a blocked IP denies access regardless of permissions.
Soft-delete is enabled by default; purge requires specific permissions via access policy or RBAC.
These come up on the exam all the time. Here's how to tell them apart.
Access Policies
Vault-scoped only; no inheritance from parent scopes.
Maximum 1024 entries per vault.
Permissions are defined per principal for keys, secrets, and certificates separately.
No deny assignments; only grant permissions.
Default authorization method for existing vaults.
Azure RBAC
Can be assigned at management group, subscription, resource group, or vault scope with inheritance.
No per-vault limit; subject to Azure subscription-wide RBAC limits.
Uses built-in roles that combine permissions across keys, secrets, and certificates.
Supports deny assignments to explicitly block access.
Recommended for new deployments; requires vault recreation to enable exclusively.
Mistake
Access policies and RBAC are mutually exclusive; you can only use one.
Correct
They can coexist. By default, both are enabled. The vault checks access policies first, then RBAC if no access policy matches.
Mistake
You can switch an existing vault from access policies to RBAC by changing a setting.
Correct
The `enableRbacAuthorization` property can only be set at vault creation time. To switch, you must create a new vault and migrate data.
Mistake
RBAC roles for Key Vault apply only to the vault they are assigned to.
Correct
RBAC roles can be assigned at management group, subscription, resource group, or vault scope. They inherit downward, so a subscription-level role applies to all vaults in that subscription.
Mistake
Access policies support deny assignments.
Correct
Access policies only grant permissions. There is no deny mechanism in access policies. Deny assignments are an RBAC feature.
Mistake
If a user has a role assignment that grants 'Key Vault Secrets User' at the subscription level, they can read secrets from any vault in that subscription regardless of access policies.
Correct
If the vault has access policies enabled (default), the user must also have an access policy entry that grants 'get' on secrets. The RBAC role alone is insufficient because access policies are checked first and if no matching policy exists, the request is denied before RBAC is evaluated.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, by default both are enabled. The vault checks access policies first. If the caller has an access policy that grants the operation, the request is allowed without checking RBAC. If no access policy matches, RBAC is evaluated. This can lead to unintended access if not carefully managed. Microsoft recommends using only one mechanism, preferably RBAC for new deployments.
You cannot change the authorization mode on an existing vault. You must create a new vault with `--enable-rbac-authorization true` (Azure CLI) or the equivalent ARM property, migrate all secrets, keys, and certificates to the new vault, update applications to use the new vault URL, and delete the old vault. There is no in-place migration.
The maximum is 1024 access policy entries per vault. Each entry is a combination of a security principal and its permissions. If you need more than 1024, consider using RBAC instead, which has no per-vault limit.
Yes, you can assign an access policy to an Azure AD group. Group membership is evaluated at runtime, including transitive membership. However, RBAC also supports groups and provides more flexibility with inheritance and centralized management.
The access policy takes precedence because it is evaluated first. The request is allowed without checking RBAC. This is why using both mechanisms simultaneously can create security gaps. To prevent this, either use only one mechanism or ensure consistency.
Yes, you can create an Azure Policy that audits or enforces the `enableRbacAuthorization` property to be true. This ensures that all new vaults use RBAC-only. However, it does not affect existing vaults.
Key Vault Secrets User allows reading secrets (get, list) but not creating or updating them. Key Vault Secrets Officer allows full management of secrets, including set, delete, backup, restore, and purge. The Officer role also includes the User permissions.
You've just covered Key Vault Access Policies vs RBAC — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?