During a change freeze, an administrator applies a lock to a resource group. Users can still read resource details, but attempts to update tags, resize a VM, or change an NSG fail. Which lock was applied?

CanNotDelete lock, because it blocks all updates but allows reading.

CanNotDelete blocks deletion, not general write operations. If users are failing to update tags and resize resources, that behavior is not explained by CanNotDelete alone.

Reader role assignment, because it removes edit permissions from the group.

Reader is an RBAC role, not a lock. Although it grants read-only permissions, it would not be something you apply as a lock to a resource group. The symptom specifically points to a management lock.

Azure Policy audit assignment, because it reports changes without blocking them.

Audit policies only report compliance and do not stop updates. They would not cause tag edits or VM changes to fail at the management plane.

What does this AZ-104 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: ReadOnly lock, because it blocks write operations while allowing read access. — A ReadOnly lock prevents write operations while still allowing users to view the resources. That means configuration updates, tag changes, size changes, and many other management actions fail, which is exactly the behavior seen during the freeze. It is more restrictive than CanNotDelete and is commonly used when the goal is to temporarily freeze management-plane changes. Why others are wrong: CanNotDelete does not block updates; it only blocks deletion. Reader is an access role, not a lock, and Azure Policy audit only records compliance rather than blocking operations. The described failure pattern is the classic symptom of a ReadOnly lock at the resource group scope.

What should I do if I get this AZ-104 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.