AZ-104 Manage Azure Identities and Governance Practice Question
A shared resource group contains a VM and a storage account used by payroll. Administrators still need to modify configuration and apply patches, but accidental deletion of either resource must be prevented. What should the administrator apply?
⚠ Common exam trap
Candidates often confuse resource locks with Azure Policy or RBAC, mistakenly thinking a policy or role assignment at the resource group scope will protect individual resources, when in fact locks must be applied directly to each resource to prevent its deletion.
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 on each resource.
A CanNotDelete lock prevents the deletion of a resource while still allowing all other operations, including configuration modifications and patching. This meets the requirement of protecting the VM and storage account from accidental deletion while preserving administrative access for updates.
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 on the entire resource group.
Why it's wrong here
A ReadOnly lock on the entire resource group blocks all write and delete operations for every resource inside the group, including the VM and storage account, which prevents configured patching, VM start/stop, and storage settings updates. Since the requirement explicitly states that changes still need to be made, ReadOnly is over-restrictive and contradicts the need for ongoing manageability. This lock type is designed for scenarios requiring complete immutability at the control plane, not for protecting specific resources from deletion while retaining operational flexibility.
When this WOULD be correct
A ReadOnly lock on the entire resource group would be correct if the requirement was to prevent any changes to resources, such as in a production environment where no modifications are allowed, and only read access is needed for auditing or reporting.
- ✓
A CanNotDelete lock on each resource.
Why this is correct
A CanNotDelete lock on each resource blocks Azure Resource Manager delete calls for the VM and the storage account while still permitting read and update operations, such as resizing the VM or modifying storage configuration. Per-resource locks are narrower than a resource-group-wide lock, limiting the protection to exactly the two assets that need it and avoiding unintended restrictions on other resources in the shared group. This directly satisfies the requirement because it prevents accidental deletion without freezing normal management-plane activities.
- ✗
A policy assignment that denies delete operations on the resource group.
Why it's wrong here
An Azure Policy assignment that denies delete operations on the resource group is a governance control, not a purpose-built deletion protection mechanism. Policy deny effects are evaluated for all resources within the assignment scope, which would also block deleting the resource group itself and could affect unrelated resources unless carefully scoped with exclusions. Resource locks are simpler and more direct; a policy adds definition and assignment overhead and may require exemptions to avoid interfering with legitimate operations, making it the wrong tool for this precise protection need.
When this WOULD be correct
This option would be correct if the question asked to prevent deletion of the entire resource group while still allowing deletion of individual resources (e.g., to protect the group structure but allow resource lifecycle management).
- ✗
A management group with a deny assignment.
Why it's wrong here
A management group deny assignment is far too broad because management groups sit above subscriptions and any deny assignment inherits to all subscriptions and resources underneath, creating an enormous blast radius that would block delete operations across many environments. It is not designed to surgically protect two resources in a single resource group; it is an organizational governance layer for policy and access control across an enterprise. Using a management group deny assignment would require complex exclusions and could break legitimate deletion workflows, making it an impractical and overly broad solution for this narrowly scoped requirement.
When this WOULD be correct
An administrator needs to prevent deletion of all resources across multiple subscriptions under a management group, while still allowing configuration changes. A deny assignment at the management group scope would enforce this restriction at a higher level.
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 lock on each resource.Correct answer▾
Why this is correct
A CanNotDelete lock on each resource blocks Azure Resource Manager delete calls for the VM and the storage account while still permitting read and update operations, such as resizing the VM or modifying storage configuration. Per-resource locks are narrower than a resource-group-wide lock, limiting the protection to exactly the two assets that need it and avoiding unintended restrictions on other resources in the shared group. This directly satisfies the requirement because it prevents accidental deletion without freezing normal management-plane activities.
✗A ReadOnly lock on the entire resource group.Wrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock prevents all modifications, including patching and configuration changes, which are still required by administrators. The question explicitly states that administrators need to modify configuration and apply patches, so a ReadOnly lock is too restrictive.
★ When this WOULD be the correct answer
A ReadOnly lock on the entire resource group would be correct if the requirement was to prevent any changes to resources, such as in a production environment where no modifications are allowed, and only read access is needed for auditing or reporting.
Why candidates choose this
Candidates may think a ReadOnly lock is a simple way to prevent deletion, overlooking that it also blocks modifications, which are explicitly needed in this scenario.
✗A policy assignment that denies delete operations on the resource group.Wrong answer — click to see why▾
Why this is wrong here
A policy assignment that denies delete operations on the resource group does not prevent deletion of individual resources within the group; it only prevents deletion of the resource group itself. The question requires preventing deletion of the VM and storage account, not the group.
★ When this WOULD be the correct answer
This option would be correct if the question asked to prevent deletion of the entire resource group while still allowing deletion of individual resources (e.g., to protect the group structure but allow resource lifecycle management).
Why candidates choose this
Candidates may think a policy can enforce a blanket deny on all delete operations within the scope, but policies at the resource group level do not automatically apply to child resources unless explicitly defined with appropriate effect and scope.
✗A management group with a deny assignment.Wrong answer — click to see why▾
Why this is wrong here
A management group with a deny assignment would apply to multiple subscriptions, not just the single resource group. It is overly broad and does not target the specific resources (VM and storage account) within that resource group.
★ When this WOULD be the correct answer
An administrator needs to prevent deletion of all resources across multiple subscriptions under a management group, while still allowing configuration changes. A deny assignment at the management group scope would enforce this restriction at a higher level.
Why candidates choose this
Candidates may confuse management groups with resource groups or think that a deny assignment is a more powerful version of a lock, not realizing it applies at a broader scope and requires Azure RBAC permissions.
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
Customer-Managed Keys (CMK) for Storage Encryption
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
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.