Manage Azure Identities and Governance →easyMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

Exhibit

Resource group: RG-Finance
Current lock status: None
Business requirement:
- Administrators must still change settings on the VM and storage account.
- Nobody should be able to delete the resource group or the resources inside it accidentally.

Based on the exhibit, which lock should the administrator apply so resources can still be updated but cannot be deleted by mistake?

⚠ Common exam trap

Test-takers frequently confuse the ReadOnly lock with the CanNotDelete lock, mistakenly thinking that a ReadOnly lock still allows updates, when in fact it blocks all write operations including updates, making it unsuitable for the stated requirement.

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

The CanNotDelete lock (option B) is correct because it allows all operations including updates and reads, but explicitly prevents deletion of the resource. This meets the requirement that resources can still be updated but cannot be deleted by mistake. Azure resource locks operate at the scope level and override any role-based permissions, ensuring that even users with Contributor or Owner roles cannot delete the resource while the lock is active.

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
Why it's wrong here
The ReadOnly lock is incorrect because it prohibits any write or delete operations on the resource group and its resources, including legitimate configuration changes, updates, and deployments. While it does still allow read operations, it blocks the exact management flexibility the organization requires—the ability to modify settings while only preventing accidental deletion. This makes it far too restrictive for the stated goal, which is to allow normal administrative tasks but protect against deletion.
When this WOULD be correct
A ReadOnly lock would be correct if the question stated that resources must be protected from both deletion and modification (e.g., 'prevent any changes to resources').
✓
CanNotDelete lock
Why this is correct
CanNotDelete is the correct lock when the organization wants to allow configuration changes but prevent accidental deletion. It protects the resource group and its resources from delete operations while still letting administrators update settings and perform normal management tasks.
✗
Subscription lock
Why it's wrong here
Azure does not have a lock type called 'subscription lock.' Resource locks are limited to two types—CanNotDelete and ReadOnly—and these can be applied at the subscription, resource group, or resource scope. A subscription-scoped lock is still one of those two types, not a separate behavioral category. If applied at the subscription level, it would affect every resource group and resource under that subscription, which is overbroad compared to a focused lock on the specific resource group in question.
When this WOULD be correct
When the question asks for a lock that prevents all modifications (including updates) to an entire subscription, such as 'You need to ensure no one can modify or delete any resources in the subscription.'
✗
Management group lock
Why it's wrong here
A 'management group lock' is not a recognized lock type either; Azure only offers CanNotDelete and ReadOnly locks. Management groups are an organizational container for subscriptions, and locks can be assigned at that scope for inheritance, but they inherit as one of the two standard lock types, not a special delete-preventing behavior. Placing a lock at management group scope would also apply to all subscriptions and resources beneath it, making it an imprecise solution when the administrator needs to protect a single resource group from accidental deletion.
When this WOULD be correct
When the question asks for a lock that prevents deletion or modification of all resources across multiple subscriptions, such as enforcing compliance or governance at the top-level hierarchy. For example: 'An administrator needs to ensure that no resources can be deleted or modified in any subscription under a management group. Which lock should be applied?'

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 lockCorrect answer▾

Why this is correct

CanNotDelete is the correct lock when the organization wants to allow configuration changes but prevent accidental deletion. It protects the resource group and its resources from delete operations while still letting administrators update settings and perform normal management tasks.

✗ReadOnly lockWrong answer — click to see why▾

Why this is wrong here

A ReadOnly lock prevents any modifications, including updates, to resources. The question requires that resources can still be updated but not deleted, so a ReadOnly lock is too restrictive.

★ When this WOULD be the correct answer

A ReadOnly lock would be correct if the question stated that resources must be protected from both deletion and modification (e.g., 'prevent any changes to resources').

Why candidates choose this

Candidates may confuse 'cannot delete' with 'read-only', thinking that preventing deletion implies read-only access, but they overlook the requirement that updates must still be allowed.

✗Subscription lockWrong answer — click to see why▾

Why this is wrong here

A subscription lock applies to the entire subscription, not just the resources in the exhibit. The question asks for a lock that allows updates but prevents deletion of specific resources, which is the CanNotDelete lock at the resource or resource group scope.

★ When this WOULD be the correct answer

When the question asks for a lock that prevents all modifications (including updates) to an entire subscription, such as 'You need to ensure no one can modify or delete any resources in the subscription.'

Why candidates choose this

Candidates may think a subscription lock is a broad solution that covers all resources, but they overlook that it also blocks updates, which is not desired here, and that the scope is too wide for the specific requirement.

✗Management group lockWrong answer — click to see why▾

Why this is wrong here

A management group lock applies to all subscriptions within the management group hierarchy, not to individual resources. The question asks for a lock that allows updates but prevents deletion of specific resources, which is the CanNotDelete lock at the resource or resource group scope.

★ When this WOULD be the correct answer

When the question asks for a lock that prevents deletion or modification of all resources across multiple subscriptions, such as enforcing compliance or governance at the top-level hierarchy. For example: 'An administrator needs to ensure that no resources can be deleted or modified in any subscription under a management group. Which lock should be applied?'

Why candidates choose this

Candidates may think a management group lock provides broad protection and mistakenly believe it can be used to protect individual resources, or they confuse management group scope with resource group scope.

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