AZ-204 Practice Question: Key Vault RBAC vs access policies for multi-team…
Multiple teams need different levels of access to the same Azure Key Vault: the DevOps team needs to create and rotate secrets, the application team needs read-only secret access, and the auditing team needs list-only access. The security team wants audit logs of all access decisions and the ability to manage permissions through a single system. What access model should the developer recommend?
⚠ Common exam trap
Many exam-takers confuse the older Key Vault access policies (which are vault-specific and lack centralized audit integration) with Azure RBAC, or incorrectly assume that SAS tokens can be applied to Key Vault, when in fact SAS is exclusive to Azure Storage services.
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
✓
Use Azure RBAC for Key Vault with role assignments scoped per team: Key Vault Secrets Officer for DevOps, Key Vault Secrets User for the app team, and Key Vault Reader for auditing
Azure RBAC for Key Vault provides a unified, centralized access management system that meets all requirements. The Key Vault Secrets Officer role allows DevOps to create and rotate secrets, the Key Vault Secrets User role grants read-only access to the application team, and the Key Vault Reader role provides list-only access for auditing. Additionally, RBAC integrates with Azure Monitor to deliver audit logs of all access decisions, satisfying the security team's need for a single management plane.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use Azure RBAC for Key Vault with role assignments scoped per team: Key Vault Secrets Officer for DevOps, Key Vault Secrets User for the app team, and Key Vault Reader for auditing
Why this is correct
RBAC assignments are integrated with Azure's identity and access management plane. All access decisions are logged in Azure Activity Log, fulfilling the audit requirement. Roles can be assigned at vault scope or narrower scopes. RBAC policies are managed centrally in Azure IAM, consistent with how all other Azure resources are governed.
- ✗
Create separate access policies for each team with the minimum required permissions
Why it's wrong here
Access policies are a flat list at the vault level. They cannot be scoped to individual secrets. All policy assignments apply to the entire vault. Access policies are not integrated into Azure Activity Log as a unified RBAC audit trail — they have their own, separate logging mechanism.
- ✗
Create a separate Key Vault per team to enforce isolation between access levels
Why it's wrong here
Creating a separate Key Vault for each team to enforce access isolation introduces significant management overhead and unnecessary complexity. This approach multiplies the effort required for tasks such as key rotation, backup, monitoring, and cost management across multiple vaults. Azure RBAC, when applied within a single Key Vault, offers superior, fine-grained control over operations and secrets, providing the necessary isolation and granularity without the operational burden of maintaining numerous distinct vaults.
- ✗
Issue shared access signatures for each team scoped to the operations they need
Why it's wrong here
Issuing Shared Access Signatures (SAS) is an incorrect approach for Azure Key Vault access. SAS tokens are a feature exclusive to Azure Storage, designed for delegating access to storage resources with granular permissions and an expiry. Azure Key Vault, conversely, relies entirely on Azure Active Directory (Azure AD) for identity-based authentication and then enforces authorization through either Key Vault access policies or Azure Role-Based Access Control (RBAC), making SAS tokens incompatible with its security model.
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
Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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-204 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-204 exam.