AZ-104 Manage Azure Identities and Governance Practice Question
You need to prevent accidental deletion of a production resource group while still allowing administrators to update resources inside it. What should you apply to the resource group?
⚠ Common exam trap
Candidates often confuse a ReadOnly lock with a CanNotDelete lock, assuming that preventing deletion requires a more restrictive lock, but the correct lock is the one that specifically targets deletion only.
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
✓
A CanNotDelete lock
A CanNotDelete lock (B) prevents the resource group from being deleted while still allowing all operations (including updates) on resources within it. This is the correct choice because the requirement is to block accidental deletion of the entire resource group, not to restrict modifications to its resources.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A ReadOnly lock
Why it's wrong here
A ReadOnly lock allows all management endpoints to return read operations, but it denies both delete and update operations at the scope, which is contrary to the requirement to permit ongoing change. Applying a ReadOnly lock would block necessary configuration updates to the production resource group, making it an overrestrictive solution that fails the stated goal of preventing only accidental deletion.
When this WOULD be correct
Apply a ReadOnly lock to a resource group when you need to prevent any changes to resources, such as in a production environment where configuration must remain static for compliance or auditing purposes.
- ✓
A CanNotDelete lock
Why this is correct
A CanNotDelete lock is an Azure Resource Manager lock at the resource group level that denies any delete operation against the resource group or its child resources, while still allowing read and update operations. This means administrators can modify configuration or deploy updates, but the lock prevents accidental deletion by any user, including Owners, unless the lock itself is explicitly removed first.
- ✗
A deny assignment
Why it's wrong here
A deny assignment is a defensive Azure RBAC construct that explicitly denies access for specific principals to perform actions, often used by managed applications or Azure Blueprints, but it is not the standard, simple mechanism for accidental deletion protection. Creating and maintaining a custom deny assignment requires careful management of principal and scope definitions, and an overly broad assignment could inadvertently block legitimate management operations, unlike a straightforward resource lock.
When this WOULD be correct
A deny assignment would be correct in a scenario where you need to enforce a policy that explicitly denies specific actions (e.g., preventing deletion of a resource group) while allowing all other actions through role-based access control, such as when using Azure Blueprints or managed applications.
- ✗
A budget alert
Why it's wrong here
A budget alert in Cost Management tracks actual or forecasted spending against a defined monetary amount and sends notifications when a threshold is reached, but it has no enforcement capability in the Azure control plane. Cost monitoring alerts cannot block ARM operations, so they are purely informational and would not prevent anyone from deleting the production resource group.
When this WOULD be correct
You need to be notified when costs for a resource group exceed a certain amount, but no action should be taken automatically. A budget alert would be correct in that scenario.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓A CanNotDelete lockCorrect answer▾
Why this is correct
A CanNotDelete lock is an Azure Resource Manager lock at the resource group level that denies any delete operation against the resource group or its child resources, while still allowing read and update operations. This means administrators can modify configuration or deploy updates, but the lock prevents accidental deletion by any user, including Owners, unless the lock itself is explicitly removed first.
✗A ReadOnly lockWrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock prevents all modifications, including updates to resources inside the resource group, which contradicts the requirement to allow administrators to update resources.
★ When this WOULD be the correct answer
Apply a ReadOnly lock to a resource group when you need to prevent any changes to resources, such as in a production environment where configuration must remain static for compliance or auditing purposes.
Why candidates choose this
Candidates may confuse 'prevent deletion' with 'prevent changes,' assuming a ReadOnly lock is the strictest protection, without realizing it blocks updates as well.
✗A deny assignmentWrong answer — click to see why▾
Why this is wrong here
A deny assignment blocks all actions that are not explicitly allowed, which would prevent administrators from updating resources inside the resource group. The question requires allowing updates while only preventing deletion, so a CanNotDelete lock is appropriate.
★ When this WOULD be the correct answer
A deny assignment would be correct in a scenario where you need to enforce a policy that explicitly denies specific actions (e.g., preventing deletion of a resource group) while allowing all other actions through role-based access control, such as when using Azure Blueprints or managed applications.
Why candidates choose this
Candidates may confuse deny assignments with locks because both are used to restrict operations, but deny assignments are more granular and typically used with Azure Policy, not for simple deletion prevention.
✗A budget alertWrong answer — click to see why▾
Why this is wrong here
A budget alert only sends notifications when spending exceeds thresholds; it does not prevent deletion of the resource group or its resources.
★ When this WOULD be the correct answer
You need to be notified when costs for a resource group exceed a certain amount, but no action should be taken automatically. A budget alert would be correct in that scenario.
Why candidates choose this
Candidates may confuse cost management controls with resource protection controls, thinking a budget alert can prevent accidental deletion by warning administrators.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
Resource group
A logical container in Microsoft Azure that holds related resources for an application or solution, enabling unified management, security, and billing.
Key term
Group
A group is a collection of users, devices, or other objects that are assigned permissions and policies together for simplified management in identity and governance systems like Microsoft Entra ID.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 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-104 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-104 exam.