AZ-104 Manage Azure Identities and Governance Practice Question
You need to prevent accidental deletion of a resource group while still allowing administrators to create and modify resources inside it. Which Azure lock should you apply?
⚠ Common exam trap
Many candidates confuse the CanNotDelete lock with the ReadOnly lock, mistakenly thinking ReadOnly still allows modifications, or they invent a non-existent 'Delete lock' option because it sounds plausible.
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
✓
CanNotDelete
The CanNotDelete lock prevents deletion of the resource group while still allowing all operations (read, write, modify) on resources within it. This lock type is designed specifically to protect against accidental deletion without restricting administrative actions like creating or updating 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.
- ✗
ReadOnly
Why it's wrong here
A ReadOnly lock is a valid resource lock level, but it is too restrictive for a resource group that must continue to be updated. It denies all write operations, including create, modify, and delete, so routine changes and deployments would be blocked. If the goal is merely to prevent deletion while still allowing updates, CanNotDelete is the appropriate lock level instead.
When this WOULD be correct
A ReadOnly lock would be correct if the requirement was to prevent any changes to the resource group and its resources, such as protecting a production environment from accidental modifications while still allowing read access.
- ✓
CanNotDelete
Why this is correct
A CanNotDelete lock is the correct Azure resource lock level for this requirement. It blocks delete operations at the assigned scope (for example, the resource group) while still permitting read, update, and management operations on contained resources. This balances protection against accidental deletion with continued operational flexibility, and it overrides any permissions, including Owner, for the deletion action.
- ✗
Delete lock
Why it's wrong here
There is no officially supported Azure resource lock level called 'Delete lock'. Resource Manager only recognizes two lock levels: CanNotDelete and ReadOnly. Attempting to configure a nonexistent lock name would fail validation, so it cannot prevent deletion; the closest valid option is CanNotDelete.
When this WOULD be correct
This option would be correct if the question asked about a custom lock name or a fictional scenario where a 'Delete lock' is defined as a custom role or policy. However, in standard Azure RBAC, no such lock exists.
- ✗
No lock and a budget alert
Why it's wrong here
A budget alert is purely a monitoring feature that sends notifications when cost thresholds are exceeded; it performs no governance or control-plane enforcement. Without a lock, any user with delete permissions can still remove the resource group, and the alert would only inform you after the fact, not halt the deletion. Therefore it is an ineffective safeguard for this scenario.
When this WOULD be correct
When the question asks for a method to be notified if resource costs exceed a threshold, or to enforce cost limits without blocking administrative actions, a budget alert would be correct.
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.
✓CanNotDeleteCorrect answer▾
Why this is correct
A CanNotDelete lock is the correct Azure resource lock level for this requirement. It blocks delete operations at the assigned scope (for example, the resource group) while still permitting read, update, and management operations on contained resources. This balances protection against accidental deletion with continued operational flexibility, and it overrides any permissions, including Owner, for the deletion action.
✗ReadOnlyWrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock prevents all modifications, including creating and modifying resources inside the resource group, which contradicts the requirement to allow administrators to create and modify resources.
★ When this WOULD be the correct answer
A ReadOnly lock would be correct if the requirement was to prevent any changes to the resource group and its resources, such as protecting a production environment from accidental modifications while still allowing read access.
Why candidates choose this
Candidates may confuse 'prevent deletion' with 'prevent changes' and think that a ReadOnly lock is needed to block deletion, not realizing it also blocks modifications.
✗Delete lockWrong answer — click to see why▾
Why this is wrong here
Azure does not have a 'Delete lock'; the correct lock type to prevent deletion is 'CanNotDelete'. 'Delete lock' is not a valid Azure lock type.
★ When this WOULD be the correct answer
This option would be correct if the question asked about a custom lock name or a fictional scenario where a 'Delete lock' is defined as a custom role or policy. However, in standard Azure RBAC, no such lock exists.
Why candidates choose this
Candidates may be misled by the name 'Delete lock' as it intuitively suggests preventing deletion, but Azure's actual lock types are 'CanNotDelete' and 'ReadOnly'.
✗No lock and a budget alertWrong answer — click to see why▾
Why this is wrong here
A budget alert does not prevent deletion; it only notifies about spending. The question requires a lock that blocks deletion, which budget alerts cannot do.
★ When this WOULD be the correct answer
When the question asks for a method to be notified if resource costs exceed a threshold, or to enforce cost limits without blocking administrative actions, a budget alert would be correct.
Why candidates choose this
Candidates may confuse cost management controls with operational controls, thinking a budget alert can also prevent deletion by triggering an action, but alerts are read-only notifications.
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
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.
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.
About these practice questions
One of 1,049 original AZ-104 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-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.