AZ-305 Practice Question: Design identity, governance, and monitoring solutions
Your company is implementing a new Azure subscription for a project that requires strict separation of duties. The security team requires that all resource creation must be approved by a central IT team. Additionally, any resource that does not comply with company tagging standards should be automatically reported. You need to design a solution that meets these requirements using Azure Policy and Azure Role-Based Access Control (RBAC). What should you do?
⚠ Common exam trap
It's easy for candidates to think a simple RBAC role assignment (like Owner or Contributor) combined with an Audit policy is sufficient, but they overlook the need for a Deny policy to actively block unapproved resource creation, which is essential for strict separation of duties.
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
✓
Create a custom RBAC role that allows only the IT team to add a specific 'Approved' tag. Use Azure Policy with 'Deny' effect to block resources without that tag. Use a separate 'Audit' policy for other tagging standards.
It uses a custom RBAC role to restrict the ability to add an 'Approved' tag to the IT team, combined with a Deny policy that blocks creation of any resource lacking that tag, ensuring all resource creation requires IT approval. The separate Audit policy automatically reports resources that fail to meet other company tagging standards, fulfilling both the approval and compliance reporting requirements without manual intervention.
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 Policy with 'Audit' effect to report non-compliant resources. Use Azure RBAC to assign Owner role to IT team.
Why it's wrong here
The Audit effect only reports resources that do not match the policy definition; it does not actively block non-compliant resources from being created, so it cannot enforce an approval gate. Assigning the Owner role to the IT team grants full management access, including the ability to change role assignments and bypass any approval workflow, which is unnecessarily permissive. This combination fails to prevent unapproved resource creation, unlike a Deny-based policy.
- ✗
Use Azure Policy with 'Append' effect to automatically add required tags at creation. Use Azure Monitor alerts for non-compliance.
Why it's wrong here
The Append effect mutates a resource during deployment to automatically add or modify the required tag, but it does not check whether the resource was approved by the IT team; it simply inserts the tag and lets the deployment proceed. Azure Monitor alerts can notify you after the resource exists, but they are reactive and do not stop unapproved resources from being provisioned. The core requirement of enforcing approval before resource creation is not met, because unapproved resources are still created and merely tagged.
- ✗
Create an Azure Policy with 'DeployIfNotExists' to deploy a tagging template. Use Azure RBAC to assign Contributor role to IT team.
Why it's wrong here
DeployIfNotExists (DINE) triggers a remediation task only after a resource has been created, so it does not act as a pre-creation approval gate; non-compliant resources can be deployed and then later brought into compliance. Assigning the Contributor role to the IT team allows them to manage all resources but still does not restrict who can create unapproved resources—any Contributor can create resources and trigger the remediation. This approach neither prevents unapproved creation nor implements a least-privilege approval role, so it fails the requirement.
- ✓
Create a custom RBAC role that allows only the IT team to add a specific 'Approved' tag. Use Azure Policy with 'Deny' effect to block resources without that tag. Use a separate 'Audit' policy for other tagging standards.
Why this is correct
This solution enforces approval at the point of creation by combining a custom RBAC role that grants the IT team exclusive permission to write the 'Approved' tag (via Microsoft.Resources/tags/write) with an Azure Policy using the Deny effect that blocks any resource lacking that tag. When a deployment attempts to create a resource without the approved tag, the Deny policy causes the deployment to fail, making the approval a mandatory part of the provisioning process. A separate Audit policy then monitors other tagging standards, providing compliance visibility without blocking deployments, while the Deny policy enforces the critical approval requirement.
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-305 question from scratch — 795 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-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.