Manage Azure Identities and Governance →mediumMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

A shared resource group contains a VPN gateway and several virtual machines used by the finance department. Administrators must still be able to resize the VMs and update NSG rules, but no one should be able to delete the resource group or anything in it during the quarter-end freeze. Which lock should be applied?

⚠ Common exam trap

Test-takers frequently confuse ReadOnly locks with CanNotDelete locks, assuming that blocking all writes is necessary to prevent deletions, but ReadOnly locks also block updates like VM resizing and NSG rule changes, which are explicitly allowed in the 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 on the resource group

The CanNotDelete lock (option B) prevents deletion of the resource group and all resources within it, while still allowing read and update operations such as resizing VMs and modifying NSG rules. This meets the requirement to block deletions during the quarter-end freeze without hindering administrative changes. ReadOnly locks would block all write operations, including resizing and NSG rule updates, which is not desired.

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 on the resource group
Why it's wrong here
A ReadOnly lock is too restrictive because it blocks all Azure Resource Manager write operations, so resizing a VM, modifying NSG rules, and updating the VPN gateway configuration would fail with a conflict error. While it does prevent deletion, it also prevents legitimate changes that the team must continue to make, making it an unsuitable choice for this scenario. The goal is to stop deletion without freezing normal administrative activity.
When this WOULD be correct
A ReadOnly lock would be correct if the requirement was to prevent any changes to resources, such as during a security audit where configuration must remain static, but read access is still needed.
✓
CanNotDelete lock on the resource group
Why this is correct
A CanNotDelete lock on the resource group is the correct control because it prevents deletions of the resource group itself and any resources inside it—including the VPN gateway—while still allowing read and update operations. This means administrators can resize the gateway, adjust NSG rules, and apply configuration changes, but no one can accidentally remove the entire shared boundary. It provides a targeted safeguard at the exact scope where the shared resources live.
✗
Management group lock on the subscription
Why it's wrong here
Locks cannot be assigned at the management group level in Azure; they are supported only at the subscription, resource group, or resource scopes. Even if a lock were placed on the entire subscription, it would apply to every resource group and resource in that subscription, extending far beyond the shared resource group and needlessly blocking changes elsewhere. This overbroad approach does not isolate the VPN gateway and shared infrastructure as the specific change-control boundary described.
When this WOULD be correct
If the question required preventing deletion of all resources across multiple subscriptions (e.g., during a company-wide freeze) and the lock needed to be applied at a high scope to cover all child resources, a management group lock on the subscription would be correct.
✗
Azure Policy deny effect on the resource group
Why it's wrong here
An Azure Policy deny effect only blocks deployments or updates that violate a specific policy definition; it cannot block a direct DELETE call against a resource group or resource. Policy is condition-based and evaluated during create, update, or deployment operations, not against every destructive action such as Remove-AzResourceGroup. To enforce deletion protection regardless of user permissions or API call type, you need the Azure resource lock mechanism.
When this WOULD be correct
An Azure Policy deny effect would be correct if the requirement is to enforce specific rules (e.g., block all resources without encryption) across multiple subscriptions, not just prevent deletion during a freeze.

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 on the resource groupCorrect answer▾

Why this is correct

A CanNotDelete lock on the resource group is the correct control because it prevents deletions of the resource group itself and any resources inside it—including the VPN gateway—while still allowing read and update operations. This means administrators can resize the gateway, adjust NSG rules, and apply configuration changes, but no one can accidentally remove the entire shared boundary. It provides a targeted safeguard at the exact scope where the shared resources live.

✗ReadOnly lock on the resource groupWrong answer — click to see why▾

Why this is wrong here

A ReadOnly lock prevents all write operations, including resizing VMs and updating NSG rules, which administrators must still be able to perform.

★ When this WOULD be the correct answer

A ReadOnly lock would be correct if the requirement was to prevent any changes to resources, such as during a security audit where configuration must remain static, but read access is still needed.

Why candidates choose this

Candidates may think a ReadOnly lock is sufficient to prevent deletion, but it also blocks modifications, which is overly restrictive for this scenario.

✗Management group lock on the subscriptionWrong answer — click to see why▾

Why this is wrong here

A management group lock on the subscription would apply to all resource groups under that management group, which is too broad for a freeze limited to a single resource group. The question specifies a shared resource group, not the entire subscription or management group.

★ When this WOULD be the correct answer

If the question required preventing deletion of all resources across multiple subscriptions (e.g., during a company-wide freeze) and the lock needed to be applied at a high scope to cover all child resources, a management group lock on the subscription would be correct.

Why candidates choose this

Candidates might think a management group lock provides broader protection and is easier to apply, but they overlook that the question's scope is limited to a single resource group, making a resource group lock more appropriate.

✗Azure Policy deny effect on the resource groupWrong answer — click to see why▾

Why this is wrong here

Azure Policy deny effect can block actions based on conditions, but it is not a lock; it requires a policy definition and assignment, and it does not prevent deletion of the resource group itself unless explicitly configured. The question asks for a lock, and CanNotDelete lock directly prevents deletion.

★ When this WOULD be the correct answer

An Azure Policy deny effect would be correct if the requirement is to enforce specific rules (e.g., block all resources without encryption) across multiple subscriptions, not just prevent deletion during a freeze.

Why candidates choose this

Candidates may confuse Azure Policy with resource locks because both can restrict operations, but locks are simpler and directly prevent deletion or modification, while policies are for compliance and governance.

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

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question