AZ-104 Manage Azure Identities and Governance Practice Question
A production resource group contains several VMs and a storage account. The operations manager wants to prevent accidental deletion of the resource group and its resources, but still allow normal configuration changes during maintenance windows. Which lock should be applied to the resource group?
⚠ Common exam trap
Many candidates confuse ReadOnly locks with CanNotDelete locks, mistakenly thinking ReadOnly is safer, but ReadOnly blocks all write operations (including configuration changes), which is too restrictive for maintenance scenarios where updates are required.
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 lock at the resource group scope.
A CanNotDelete lock at the resource group scope prevents the deletion of the resource group and all its resources, while still allowing configuration changes (e.g., modifying VM settings or updating storage account properties). This meets the operations manager's requirement to block accidental deletion but permit normal maintenance operations. ReadOnly locks would block all write operations, which is too restrictive for maintenance windows.
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 lock at the resource group scope.
Why it's wrong here
A ReadOnly lock at the resource group scope blocks all write operations, not just deletes. This means common production maintenance actions such as resizing a VM, adding or updating tags, applying a new deployment, or writing blobs to the storage account would fail with a conflict error. It is intended for situations where the configuration must be frozen for audit or compliance, but it is too restrictive when routine configuration changes still need to be made.
When this WOULD be correct
If the requirement were to prevent any changes (including configuration) to the resource group and its resources, such as for a compliance or audit scenario where the environment must remain static, then a ReadOnly lock would be correct.
- ✓
CanNotDelete lock at the resource group scope.
Why this is correct
CanNotDelete is the correct lock when the goal is to prevent accidental removal while still allowing updates. It blocks delete operations for the resource group and its resources, but it does not stop normal configuration changes such as resizing, tagging, or network updates. That makes it suitable for production protection without freezing administration.
- ✗
Azure Policy assignment that denies all delete requests.
Why it's wrong here
An Azure Policy assignment denying delete requests would prevent accidental deletions and allow configuration changes, but it is a continuous governance mechanism, not a direct operational control. Policies are designed for broad, ongoing compliance enforcement rather than temporary removal and re-application for specific maintenance windows. This option is tempting because policies are excellent for enforcing organisational standards, such as preventing resource deletion across subscriptions or resource groups, ensuring continuous adherence to security or cost management rules.
When this WOULD be correct
This option would be correct in a scenario where the organization needs to enforce compliance rules (e.g., requiring specific tags or ensuring all resources are in allowed regions) across all resources, and deletion prevention is just one of many requirements. The question would ask for a governance solution that can audit or deny non-compliant resource creation or modification, not just prevent accidental deletion.
- ✗
Apply the lock only to individual virtual machines.
Why it's wrong here
Locking only the individual VMs would leave the storage account and any other resources in the resource group unprotected from accidental deletion. Because resource locks are inherited only from parent scopes, a VM-level lock does not extend to sibling resources, and every VM would need a separate lock assignment — including any future VMs added later. This approach is inconsistent and operationally fragile compared with a single CanNotDelete lock at the resource group scope, which inherits to all current and future child resources.
When this WOULD be correct
If the question specified that only the VMs must be protected from deletion while allowing deletion of other resources (e.g., storage account), then applying a CanNotDelete lock to each VM individually 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.
✓CanNotDelete lock at the resource group scope.Correct answer▾
Why this is correct
CanNotDelete is the correct lock when the goal is to prevent accidental removal while still allowing updates. It blocks delete operations for the resource group and its resources, but it does not stop normal configuration changes such as resizing, tagging, or network updates. That makes it suitable for production protection without freezing administration.
✗ReadOnly lock at the resource group scope.Wrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock prevents all modifications, including configuration changes during maintenance windows, which violates the requirement to allow normal configuration changes.
★ When this WOULD be the correct answer
If the requirement were to prevent any changes (including configuration) to the resource group and its resources, such as for a compliance or audit scenario where the environment must remain static, then a ReadOnly lock would be correct.
Why candidates choose this
Candidates may think a ReadOnly lock is sufficient to prevent deletion, but they overlook that it also blocks modifications, which is not desired here.
✗Azure Policy assignment that denies all delete requests.Wrong answer — click to see why▾
Why this is wrong here
Azure Policy assignments deny or audit actions based on rules, but they do not prevent deletion by default unless a specific deny effect is configured for delete operations. Even then, policy can be overridden by permissions, whereas locks provide a stronger, role-independent restriction.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the organization needs to enforce compliance rules (e.g., requiring specific tags or ensuring all resources are in allowed regions) across all resources, and deletion prevention is just one of many requirements. The question would ask for a governance solution that can audit or deny non-compliant resource creation or modification, not just prevent accidental deletion.
Why candidates choose this
Candidates may think Azure Policy is a catch-all for security and compliance, including deletion prevention, and overlook that locks are specifically designed for protecting against accidental deletion or modification.
✗Apply the lock only to individual virtual machines.Wrong answer — click to see why▾
Why this is wrong here
Applying the lock only to individual VMs does not protect the storage account or other resources in the resource group from accidental deletion, failing to meet the requirement to prevent deletion of all resources.
★ When this WOULD be the correct answer
If the question specified that only the VMs must be protected from deletion while allowing deletion of other resources (e.g., storage account), then applying a CanNotDelete lock to each VM individually would be correct.
Why candidates choose this
Candidates may think granular control is better and assume locking individual VMs is sufficient, overlooking that the storage account and other resources remain unprotected.
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
Storage account
A cloud storage account is a container that holds a set of cloud storage services and their data, providing a unique namespace and access policies for storing and managing unstructured data.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.