AZ-305 Practice Question: Design identity, governance, and monitoring solutions
Network Topology
Refer to the exhibit. A user reports they cannot access a secret in the vault 'vault-prod'. The user has a Contributor role at the subscription scope and a Key Vault Secrets User role at the specific vault scope. What is the most likely reason for the failure?
⚠ Common exam trap
Watch out — candidates often assume RBAC roles always apply to Key Vault data plane operations, forgetting that the vault's authorization model must be set to RBAC for those roles to take effect; otherwise, access policies override them.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The vault uses access policies instead of RBAC for authorization.
The user has the Key Vault Secrets User role at the vault scope, which grants read permissions to secrets via Azure RBAC. However, if the vault is configured to use access policies instead of RBAC for authorization, the RBAC role assignment is ignored. In that case, the user must be granted explicit permissions through the vault's access policy to read secrets. The Contributor role at subscription scope does not include data plane permissions for Key Vault secrets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The user does not have write permissions on the vault.
Why it's wrong here
The reported symptom is that the user cannot read a secret, not that they cannot modify it. In Azure Key Vault, retrieving a secret requires the 'Microsoft.KeyVault/vaults/secrets/getSecret/action' permission (which maps to Get in an access policy), while write permissions like Set or Delete are irrelevant to reading. Even a user with full write permissions would be denied a read operation if they lack a read/data-plane permission, so the cause of the failure cannot be absent write permissions.
- ✓
The vault uses access policies instead of RBAC for authorization.
Why this is correct
Key Vault can authorize data-plane access either through the older vault access policy model or through Azure RBAC, and the two are mutually exclusive for a given vault. When the vault is set to use access policies, Azure RBAC role assignments such as Key Vault Secrets User are not evaluated at all by the data plane, so the user will be denied even though the role appears correct. The fix is to switch the vault's access configuration to Azure RBAC, or more directly, add the user to the vault's access policy with Get and List permissions on secrets.
- ✗
The Key Vault Secrets User role does not allow reading secrets.
Why it's wrong here
The Key Vault Secrets User built-in role is defined with data-plane actions 'Microsoft.KeyVault/vaults/secrets/getSecret/action' and 'Microsoft.KeyVault/vaults/secrets/listSecret/action', which explicitly permit reading secret metadata and the secret value. Therefore, the role absolutely does allow reading secrets, so this option is factually incorrect as an explanation for the access failure. The role may still not work in practice, but only because the vault's permission model ignores RBAC assignments — not because the role lacks the read action.
- ✗
The scope of the Key Vault Secrets User role is incorrect.
Why it's wrong here
The role assignment shown in the exhibit is scoped directly to the Key Vault resource, typically written as '/subscriptions/<id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<name>'. This narrow scope is exactly the right level for granting access to all secrets in that one vault, and RBAC rules are inherited by the vault as a resource, so the scope is not the problem. If the vault used Azure RBAC for data plane, this assignment would work; since it does not, the issue lies upstream in the permission model rather than in where the role is assigned.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
This AZ-305 question is part of Courseiva's 795-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-305 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-305 exam.