AZ-104 Manage Azure Identities and Governance Practice Question
A production resource group contains web and data resources. Administrators must be able to update, scale, and restart resources, but they must not delete the resource group or any resource inside it during maintenance windows. Which two actions should the administrator take? Select two.
⚠ Common exam trap
Many exam-takers confuse the CanNotDelete lock with the ReadOnly lock, mistakenly thinking a ReadOnly lock still allows updates and scaling, or they assume tags can enforce deletion prevention, when in reality tags are purely organizational and have no security or governance enforcement capabilities.
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 the resource group.
Applying a CanNotDelete lock to the resource group prevents the deletion of the resource group and all resources within it, while still allowing administrators to update, scale, and restart resources. This lock type blocks delete operations but permits read and update operations, which aligns with the requirement to perform maintenance actions without risking deletion. The lock is inherited by all child resources in the resource group, ensuring comprehensive protection.
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 a CanNotDelete lock to the resource group.
Why this is correct
A CanNotDelete lock applied at the resource group scope prevents the resource group and every child resource from being deleted, while still allowing read and write operations such as changing configurations, scaling instances, and deploying updates. This is the correct choice for a production environment that needs to remain fully manageable during maintenance windows but must be safeguarded against accidental removal. The lock is inherited by all current and future resources in the group, providing comprehensive protection with a single action.
- ✗
Apply a ReadOnly lock to the resource group.
Why it's wrong here
A ReadOnly lock blocks all write operations, including updates, scaling, and even the ability to start or stop virtual machines, because Azure denies any management-plane change to the resource group and its children. This level of restriction would break routine production maintenance tasks and prevent legitimate administrative actions, making it too overly restrictive for the stated requirement, which only demands deletion protection, not immutable infrastructure.
When this WOULD be correct
If the requirement was to prevent any changes to resources (e.g., during a security audit or compliance hold) while still allowing read access, a ReadOnly lock at the resource group scope would be correct.
- ✗
Apply a CanNotDelete lock only to the individual virtual machines.
Why it's wrong here
Locking only the individual virtual machines leaves the resource group itself and other child resources—such as databases, app services, and storage accounts—unprotected from deletion. Although deleting the resource group may still be blocked because some of its resources are locked, the scope is incomplete and still leaves non-VM resources exposed to accidental deletion or overridden by RG-level deletions in some scenarios. A single resource-group-level lock is far simpler and covers everything, whereas per-VM locks require ongoing tracking and miss new or non-VM resources.
When this WOULD be correct
In a scenario where the requirement is to prevent deletion of specific virtual machines only, while allowing deletion of other resources in the same resource group, applying a CanNotDelete lock at the individual VM level would be correct.
- ✓
Apply the lock at the resource group scope so it covers child resources.
Why this is correct
Placing the lock on the resource group extends the protection to resources within that group. This is the cleanest way to prevent accidental deletion of the group or its contents while keeping the group manageable.
- ✗
Use tags to mark the resources as production and prevent deletion.
Why it's wrong here
Tags are purely metadata keywords used for organization, cost reporting, filtering, and automation; Azure does not enforce any deletion protection based on a tag's value. To actually prevent deletion using tags, you would need a separate Azure Policy definition with a Deny effect, which is not the same as simply marking resources as production. Therefore, tagging alone cannot block a delete operation and provides no safety guarantee during maintenance windows.
When this WOULD be correct
In a scenario where you need to categorize resources for cost tracking or policy enforcement (e.g., apply a policy that prevents deletion of resources with a 'production' tag), tags would be the correct choice.
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 the resource group.Correct answer▾
Why this is correct
A CanNotDelete lock applied at the resource group scope prevents the resource group and every child resource from being deleted, while still allowing read and write operations such as changing configurations, scaling instances, and deploying updates. This is the correct choice for a production environment that needs to remain fully manageable during maintenance windows but must be safeguarded against accidental removal. The lock is inherited by all current and future resources in the group, providing comprehensive protection with a single action.
✗Apply a ReadOnly lock to the resource group.Wrong answer — click to see why▾
Why this is wrong here
A ReadOnly lock prevents all write operations, including update, scale, and restart actions, which are explicitly required in the question.
★ When this WOULD be the correct answer
If the requirement was to prevent any changes to resources (e.g., during a security audit or compliance hold) while still allowing read access, a ReadOnly lock at the resource group scope would be correct.
Why candidates choose this
Candidates may confuse 'prevent deletion' with 'prevent changes' and think ReadOnly is safer, or they may not realize that update/scale/restart are write operations blocked by ReadOnly.
✗Apply a CanNotDelete lock only to the individual virtual machines.Wrong answer — click to see why▾
Why this is wrong here
Applying a CanNotDelete lock only to individual virtual machines leaves other resources in the resource group (e.g., databases, web apps) unprotected from deletion, failing to meet the requirement that administrators must not delete any resource inside the group.
★ When this WOULD be the correct answer
In a scenario where the requirement is to prevent deletion of specific virtual machines only, while allowing deletion of other resources in the same resource group, applying a CanNotDelete lock at the individual VM level would be correct.
Why candidates choose this
Candidates may think that locking only the most critical resources (VMs) is sufficient, overlooking that the requirement applies to all resources in the group, not just VMs.
✗Use tags to mark the resources as production and prevent deletion.Wrong answer — click to see why▾
Why this is wrong here
Tags do not enforce access control or prevent deletion; they are metadata only. The question requires a mechanism to block deletion, which tags cannot provide.
★ When this WOULD be the correct answer
In a scenario where you need to categorize resources for cost tracking or policy enforcement (e.g., apply a policy that prevents deletion of resources with a 'production' tag), tags would be the correct choice.
Why candidates choose this
Candidates may think tags can be used with Azure Policy to prevent deletion, but the question asks for a direct action, not a policy setup, and tags alone have no effect on deletion 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
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
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.