Manage Azure Identities and Governance →easyMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

Exhibit

Resource group: RG-Prod-Shared
Resources:
- prodvm01 (Microsoft.Compute/virtualMachines)
- prodstore01 (Microsoft.Storage/storageAccounts)

Change control note:
- Updates must still be allowed
- Accidental deletion must be prevented
- Lock should apply to both resources in the group

Based on the exhibit, a shared resource group contains a production virtual machine and a storage account. Administrators must be able to update settings, but they must not be able to delete either resource by mistake. Which lock should be applied at the resource group scope?

⚠ Common exam trap

Many candidates confuse ReadOnly locks with CanNotDelete locks, mistakenly thinking that preventing all changes is safer, but the question explicitly requires allowing updates, making ReadOnly locks too restrictive.

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, because it allows updates but blocks deletion.

The CanNotDelete lock (option B) is correct because it allows administrators to update settings on the production VM and storage account while preventing accidental deletion of either resource. This lock operates at the resource group scope, applying to all resources within it, and is the appropriate choice for the stated requirement of allowing updates but blocking deletions.

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, because it prevents all changes and keeps resources fully protected.
Why it's wrong here
ReadOnly is too restrictive because it blocks write operations as well as deletions. The scenario says administrators must still be able to update settings, so a ReadOnly lock would prevent legitimate management tasks and break the requirement.
When this WOULD be correct
A ReadOnly lock would be correct in a scenario where the requirement is to prevent any changes to resources, such as protecting a critical production database from accidental modifications while still allowing read access.
✓
CanNotDelete lock, because it allows updates but blocks deletion.
Why this is correct
CanNotDelete is the correct choice when administrators still need to modify resource settings but must be prevented from deleting the resources. Applied at the resource group scope, it protects both the VM and the storage account from accidental deletion while preserving normal update operations.
✗
No lock is needed because Azure RBAC already prevents deletion by default.
Why it's wrong here
Azure RBAC does not block deletion by default; it only grants or denies permissions based on assigned roles. A user holding a role such as Contributor or Owner has the authority to delete resources unless an explicit deny assignment is in place. Resource locks function as an authoritative restriction that overrides RBAC for all users, protecting the resource group from accidental deletion even when administrators need update permissions.
When this WOULD be correct
If the question stated that administrators already have a custom RBAC role that denies delete actions, and the requirement is to prevent any further changes, then no additional lock is needed.
✗
Management group lock, because all changes in the tenant must be blocked centrally.
Why it's wrong here
Management groups are for organizing subscriptions and applying governance at a high level, but the question is about protecting one resource group. A management group lock is not the right concept here and would be far broader than required.
When this WOULD be correct
A management group lock would be correct if the question asked for a lock that prevents deletion of all resources across multiple subscriptions under a management group, such as when enforcing a policy that no resources in the entire organization can be deleted.

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, because it allows updates but blocks deletion.Correct answer▾

Why this is correct

CanNotDelete is the correct choice when administrators still need to modify resource settings but must be prevented from deleting the resources. Applied at the resource group scope, it protects both the VM and the storage account from accidental deletion while preserving normal update operations.

✗ReadOnly lock, because it prevents all changes and keeps resources fully protected.Wrong answer — click to see why▾

Why this is wrong here

The question requires that administrators can update settings, but a ReadOnly lock prevents all updates, which is too restrictive for the stated requirement.

★ When this WOULD be the correct answer

A ReadOnly lock would be correct in a scenario where the requirement is to prevent any changes to resources, such as protecting a critical production database from accidental modifications while still allowing read access.

Why candidates choose this

Candidates may think ReadOnly lock is the safest choice to prevent accidental deletion, overlooking that it also blocks necessary updates.

✗No lock is needed because Azure RBAC already prevents deletion by default.Wrong answer — click to see why▾

Why this is wrong here

Azure RBAC does not prevent deletion by default; the Contributor role, for example, allows deletion. A lock is required to explicitly block deletion while allowing updates.

★ When this WOULD be the correct answer

If the question stated that administrators already have a custom RBAC role that denies delete actions, and the requirement is to prevent any further changes, then no additional lock is needed.

Why candidates choose this

Candidates may confuse RBAC permissions with resource locks, assuming that default roles like Contributor already block deletion, which is incorrect.

✗Management group lock, because all changes in the tenant must be blocked centrally.Wrong answer — click to see why▾

Why this is wrong here

Management group locks apply to all subscriptions within a management group hierarchy, not to a single resource group. The question specifies a resource group scope, so a management group lock is too broad and would affect other resources unnecessarily.

★ When this WOULD be the correct answer

A management group lock would be correct if the question asked for a lock that prevents deletion of all resources across multiple subscriptions under a management group, such as when enforcing a policy that no resources in the entire organization can be deleted.

Why candidates choose this

Candidates may confuse management group locks with resource group locks, thinking that applying a lock at a higher scope is more effective or simpler, without considering the scope requirements of the question.

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

AZ-104 Manage Azure Identities and Governance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question