AZ-900 Describe Azure management and governance Practice Question
A company wants to prevent any Azure resource from being accidentally deleted by anyone, including subscription owners. Which Azure feature accomplishes this?
⚠ Common exam trap
Watch out — candidates often confuse Azure Policy (which governs compliance and creation/modification) with Azure Locks (which specifically prevent deletion), or they assume RBAC roles like Owner can always delete, forgetting that locks override RBAC.
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
✓
Azure Resource Manager CanNotDelete lock
The Azure Resource Manager CanNotDelete lock is the correct feature because it prevents any user, including subscription owners, from deleting a resource. This lock overrides all RBAC permissions, ensuring that even users with Owner or Contributor roles cannot delete the resource until the lock is removed. It is specifically designed for accidental deletion prevention at the resource, resource group, or subscription level.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Azure Policy with Deny effect
Why it's wrong here
Azure Policy with the Deny effect is designed to deny resource create, update, or audit actions that violate policy rules, such as disallowing deployment of a resource with a specific SKU or tag. However, it does not intercept or prevent delete operations on existing resources; policy evaluation for delete actions is not supported for the Deny effect in the same way. To stop deletion of an existing resource, Azure Resource Manager locks are required, because they operate at the management plane independently of policy compliance and prohibit delete calls for the locked scope.
- ✓
Azure Resource Manager CanNotDelete lock
Why this is correct
An Azure Resource Manager CanNotDelete lock is the correct mechanism because it blocks any delete operation on the resource, resource group, or subscription where it is applied, regardless of the caller's RBAC role, including the subscription Owner. The lock overrides all permissions for the scoped resource, so even an Owner cannot delete it until the lock is explicitly removed. This lock still allows read and update operations, but it enforces that a locked resource must remain in place, making it the precise tool for preventing deletion.
- ✗
RBAC Reader role
Why it's wrong here
RBAC Reader role is an identity-based permission that grants read-only access to resources, but it only affects users or service principals assigned that role. It does not restrict users who hold higher roles, such as Owner, because an Owner can delete resources and also has permissions to remove role assignments. Moreover, Reader cannot prevent an Owner from deleting the resource itself; it only limits what the Reader-assigned identity can do, so it fails to block deletion by owners.
- ✗
Azure Blueprints
Why it's wrong here
Azure Blueprints is a orchestration service for defining repeatable deployment artifacts, including policies, role assignments, and resource templates. While a blueprint definition can include a resource lock artifact (e.g., CanNotDelete), the blueprint itself does not enforce deletion protection; it merely deploys the actual lock object to the target scope. The protection comes from the underlying Azure Resource Manager lock, and a blueprint assignment can be removed or altered, so Blueprints as an abstraction is not the direct mechanism that prevents deletion.
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
Learn chapter
Azure Cost Management and Billing
Key term
RBAC
RBAC is a method of restricting network access based on the roles of individual users within an organization, where permissions are assigned to roles rather than to individuals directly.
Key term
User
A user is any person, system, or device that interacts with an IT service, resource, or identity system, typically authenticated through credentials and authorized to perform specific actions.
About these practice questions
One of 981 original AZ-900 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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-900 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-900 exam.