Manage Azure Identities and Governance →mediumMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

You need to ensure that administrators cannot accidentally delete a production virtual network, but they must still be able to update subnet settings. Which Azure feature should you apply?

⚠ Common exam trap

It's easy for candidates to confuse Azure Policy (which enforces rules on resource properties) with resource locks (which control deletion or modification permissions), leading them to select a deny assignment instead of the simpler CanNotDelete lock.

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

A CanNotDelete lock (Azure resource lock) prevents accidental deletion of the virtual network while allowing all other operations, including updates to subnet settings. This lock type blocks DELETE requests at the Azure Resource Manager level, but permits PUT and PATCH operations, so administrators can still modify subnet configurations.

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 CanNotDelete lock
Why this is correct
A CanNotDelete lock is the correct solution because it specifically blocks delete operations on the subnet while leaving all read and update operations untouched. Administrators can continue to modify address ranges or linked resources, but any attempt to delete the subnet fails until the lock is removed. The lock is enforced at the control plane and requires an explicit unlock action, making accidental deletion extremely unlikely.
✗
A ReadOnly lock
Why it's wrong here
A ReadOnly lock would indeed prevent deletion, but it also blocks all modifications to the subnet, such as changing its service endpoints or delegating it to a PaaS service. Since the requirement is only to prevent accidental deletion while still allowing administrators to manage the subnet, a ReadOnly lock is overly restrictive and would hinder routine administrative tasks. This overprotection makes it an incorrect answer.
When this WOULD be correct
A ReadOnly lock would be correct if the requirement were to prevent any modifications to the virtual network and its subnets, while still allowing read access. For example, to protect a critical network configuration from any changes during an audit period.
✗
An Azure Policy deny assignment
Why it's wrong here
An Azure Policy deny assignment is not the correct feature because policies are designed to enforce compliance of resource properties during create, update, and some delete actions, not to provide a direct, universal guard against deletion. While a custom policy could include a 'Microsoft.Network/virtualNetworks/subnets/delete' action in its deny effect, policy evaluation for delete is inconsistent across resource providers and policies are often scoped to audit or deny configurations, not operational protection. A lock is the standard, built-in mechanism for this scenario.
When this WOULD be correct
When the requirement is to prevent any configuration changes to a resource, such as ensuring that no one can modify the network security group rules on a production subnet, while still allowing read access.
✗
A budget alert
Why it's wrong here
A budget alert is a cost-management tool that sends notifications when spending exceeds a defined threshold; it does not interact with Azure Resource Manager delete operations. Even if a subnet deletion were to incur some cost, the alert only informs you after the fact (or when the forecasted cost hits the threshold) and has no ability to block the deletion. Therefore, it cannot ensure that administrators do not accidentally delete a subnet.
When this WOULD be correct
A budget alert would be correct in a scenario where you need to monitor and receive notifications when spending on a virtual network or its associated resources exceeds a defined cost threshold, without any access control requirements.

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

Why this is correct

A CanNotDelete lock is the correct solution because it specifically blocks delete operations on the subnet while leaving all read and update operations untouched. Administrators can continue to modify address ranges or linked resources, but any attempt to delete the subnet fails until the lock is removed. The lock is enforced at the control plane and requires an explicit unlock action, making accidental deletion extremely unlikely.

✗A ReadOnly lockWrong answer — click to see why▾

Why this is wrong here

A ReadOnly lock prevents all write operations, including updating subnet settings, which contradicts the requirement that administrators must still be able to update subnet settings.

★ When this WOULD be the correct answer

A ReadOnly lock would be correct if the requirement were to prevent any modifications to the virtual network and its subnets, while still allowing read access. For example, to protect a critical network configuration from any changes during an audit period.

Why candidates choose this

Candidates may think a ReadOnly lock is the only way to prevent deletion, but they overlook that it also blocks updates, which are explicitly required in the question.

✗An Azure Policy deny assignmentWrong answer — click to see why▾

Why this is wrong here

An Azure Policy deny assignment prevents any updates to the resource, including subnet settings, which contradicts the requirement that administrators must be able to update subnet settings.

★ When this WOULD be the correct answer

When the requirement is to prevent any configuration changes to a resource, such as ensuring that no one can modify the network security group rules on a production subnet, while still allowing read access.

Why candidates choose this

Candidates may confuse Azure Policy's ability to enforce compliance and prevent modifications with the more granular resource lock, thinking a deny assignment can selectively block deletions while allowing updates.

✗A budget alertWrong answer — click to see why▾

Why this is wrong here

A budget alert only notifies about spending thresholds; it does not prevent deletion or allow subnet updates, so it fails to meet the requirement of preventing accidental deletion while permitting subnet configuration.

★ When this WOULD be the correct answer

A budget alert would be correct in a scenario where you need to monitor and receive notifications when spending on a virtual network or its associated resources exceeds a defined cost threshold, without any access control requirements.

Why candidates choose this

Candidates might confuse budget alerts with governance controls, thinking they can block actions via cost limits, or they may misremember the purpose of budget alerts as a security feature.

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?”

Visual reference

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