CanNotDelete Lock to Prevent Resource Group Deletion
Exhibit
Resource group: RG-Prod Current lock: - Type: None Change request: - Prevent accidental deletion of RG-Prod and its resources. - Allow administrators to change VM sizes, tags, and NSG rules when needed.
Based on the exhibit, the team must prevent accidental deletion of a resource group, but administrators still need to update settings on resources inside it. Which lock should you apply?
Quick Answer
The correct answer is to apply a CanNotDelete lock to the resource group. This lock type is the ideal choice because it blocks delete operations on the resource group itself while still allowing administrators to read and update settings on the resources inside it, perfectly matching the requirement to prevent accidental deletion without restricting management changes. On the AZ-104 exam, this scenario tests your understanding of Azure resource locks and their scope, often appearing as a trick where candidates mistakenly apply a ReadOnly lock, which would block all updates. A common trap is confusing the lock’s effect on the resource group versus its child resources—remember that a CanNotDelete lock on the parent does not prevent updates to the children. For a quick memory tip, think “CanNotDelete = Can still update, just can’t remove.”
⚠ Common exam trap
Many exam-takers confuse CanNotDelete with ReadOnly, mistakenly thinking that preventing deletion requires blocking all write operations, but CanNotDelete specifically targets delete operations while allowing updates.
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
✓
Apply a CanNotDelete lock to RG-Prod.
Applying a CanNotDelete lock to RG-Prod prevents the resource group from being deleted while still allowing administrators to update settings on resources inside it. This lock type blocks delete operations but permits read and update operations, which aligns with the requirement to prevent accidental deletion without restricting management changes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Apply no lock and rely on RBAC alone.
Why it's wrong here
RBAC does not stop deletion if someone already has sufficient permissions, so this does not meet the requirement.
When this WOULD be correct
If the question stated that all users should be able to delete the resource group but only specific actions need to be controlled via permissions, then RBAC alone would be sufficient.
- ✗
Apply a ReadOnly lock to RG-Prod.
Why it's wrong here
ReadOnly blocks write operations as well as delete operations, so it would prevent the updates the team still needs.
When this WOULD be correct
If the requirement were to prevent any modifications to resources (including updates) while still allowing read access, a ReadOnly lock would be correct. For example, a question stating 'Prevent all changes to resources in a resource group, but allow read access for auditing' would make B the correct answer.
- ✓
Apply a CanNotDelete lock to RG-Prod.
Why this is correct
CanNotDelete prevents accidental deletion while still allowing normal update operations on existing resources in the scope.
- ✗
Apply a Contributor role assignment to RG-Prod.
Why it's wrong here
Contributor is a permission role, not a protection control, and it does not prevent deletion.
When this WOULD be correct
This option would be correct if the question asked for granting full management access to resources within a resource group without preventing deletion, such as when a new administrator needs to manage resources but not modify access policies.
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.
✓Apply a CanNotDelete lock to RG-Prod.Correct answer▾
Why this is correct
CanNotDelete prevents accidental deletion while still allowing normal update operations on existing resources in the scope.
✗Apply no lock and rely on RBAC alone.Wrong answer — click to see why▾
Why this is wrong here
Relying solely on RBAC does not prevent accidental deletion of the resource group; a user with delete permissions (e.g., Contributor) could still delete it. The question requires a lock to block deletion.
★ When this WOULD be the correct answer
If the question stated that all users should be able to delete the resource group but only specific actions need to be controlled via permissions, then RBAC alone would be sufficient.
Why candidates choose this
Candidates may think RBAC is enough to control deletion, overlooking that locks provide an additional layer of protection against accidental deletion even for authorized users.
✗Apply a ReadOnly lock to RG-Prod.Wrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock prevents any changes to resources, including updates to settings, which contradicts the requirement that administrators still need to update settings on resources inside the resource group.
★ When this WOULD be the correct answer
If the requirement were to prevent any modifications to resources (including updates) while still allowing read access, a ReadOnly lock would be correct. For example, a question stating 'Prevent all changes to resources in a resource group, but allow read access for auditing' would make B the correct answer.
Why candidates choose this
Candidates may think a ReadOnly lock is a stronger protection against accidental deletion, but they overlook that it also blocks updates, which is not allowed here. They might confuse the lock's effect on deletion versus modification.
✗Apply a Contributor role assignment to RG-Prod.Wrong answer — click to see why▾
Why this is wrong here
A Contributor role assignment allows users to manage resources, including deletion, which does not prevent accidental deletion of the resource group.
★ When this WOULD be the correct answer
This option would be correct if the question asked for granting full management access to resources within a resource group without preventing deletion, such as when a new administrator needs to manage resources but not modify access policies.
Why candidates choose this
Candidates may confuse role assignments with locks, thinking that limiting permissions via roles can prevent deletion, but RBAC does not override owner-level actions or provide the same protection as locks.
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
Privileged Identity Management (PIM)
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
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 →
Same concept, more angles
8 more ways this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. During a change freeze, the operations team wants to prevent accidental deletion of a production resource group and everything in it. They still need to update VM settings, change tags, and modify network rules. Which lock should be applied?
medium- A.Apply a ReadOnly lock to the resource group.
- ✓ B.Apply a CanNotDelete lock to the resource group.
- C.Assign the Reader role to all operators.
- D.Assign an Azure Policy deny assignment at the subscription.
Why B: The CanNotDelete lock (Option B) prevents deletion of the resource group and all resources within it, while still allowing read and update operations such as modifying VM settings, changing tags, and updating network rules. This lock type is specifically designed to protect against accidental deletion during a change freeze without blocking management operations.
Variation 2. A production resource group must be protected from accidental deletion during a change freeze. Administrators still need to update VM sizes, rotate tags, and change NSG rules. Which action should the administrator take?
medium- ✓ A.Apply a CanNotDelete lock to the resource group.
- B.Apply a ReadOnly lock to the resource group.
- C.Apply a CanNotDelete lock to each individual resource in the resource group.
- D.Use Azure Policy to deny all delete requests.
- E.Add a Protected=true tag and use it to prevent deletion.
Why A: Applying a CanNotDelete lock to the resource group is the correct action. It prevents deletion of the resource group and all current and future resources while allowing read/write operations. ReadOnly locks would block updates, and Azure Policy or tags cannot provide the same built-in deletion protection.
Variation 3. 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?
medium- A.A ReadOnly lock
- ✓ B.A CanNotDelete lock
- C.A deny assignment
- D.A budget alert
Why B: 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.
Variation 4. You need to prevent accidental deletion of a resource group while still allowing administrators to create and modify resources inside it. Which lock should you apply?
medium- A.ReadOnly
- ✓ B.CanNotDelete
- C.Delete lock
- D.No lock and a budget alert
Why B: The CanNotDelete lock prevents the resource group from being deleted while still allowing all operations (including create and modify) on resources within it. This is the correct choice because the requirement is specifically to block deletion, not to restrict modifications or read access.
Variation 5. 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?
medium- A.ReadOnly
- ✓ B.CanNotDelete
- C.Delete lock
- D.No lock and a budget alert
Why B: 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.
Variation 6. You need to ensure that administrators cannot accidentally delete a production virtual network, but they must still be able to update subnet settings. Which Azure feature should you apply?
medium- ✓ A.A CanNotDelete lock
- B.A ReadOnly lock
- C.An Azure Policy deny assignment
- D.A budget alert
Why A: A CanNotDelete lock (Azure resource lock) prevents accidental deletion of the virtual network while allowing all other operations, including updates to subnet settings. This lock type blocks DELETE requests at the Azure Resource Manager level, but permits PUT and PATCH operations, so administrators can still modify subnet configurations.
Variation 7. A production resource group must not be deleted accidentally, but administrators still need to update resources inside it. Which lock should you apply to the resource group?
easy- A.ReadOnly lock
- ✓ B.CanNotDelete lock
- C.Contributor role
- D.Azure Policy deny assignment
Why B: The CanNotDelete lock (option B) is correct because it prevents deletion of the resource group while still allowing all other operations, including updates to resources within it. This lock type is specifically designed to protect against accidental deletion without blocking read, write, or modify actions, which aligns perfectly with the requirement that administrators need to update resources inside the group.
Variation 8. A production resource group contains VMs, public IP addresses, and a storage account. During a migration window, administrators must still be able to change settings and resize VMs, but nobody should accidentally delete any resource. Which lock should you apply to the resource group?
medium- A.ReadOnly
- ✓ B.CanNotDelete
- C.Contributor
- D.Azure Policy
Why B: The CanNotDelete lock prevents any user or process from deleting the resource group or its resources, while still allowing all other operations including read, write, and configuration changes such as resizing VMs. This matches the requirement that administrators must be able to change settings and resize VMs but must not accidentally delete any resource.
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.