AZ-104 Practice Question 2: Resource Lock Types
Microsoft Azure Administrator Associate (AZ-104) · Test 1 · question 2 of 10
Your finance team runs a production workload in the resource group RG-Prod. Recent incidents were caused by engineers deleting resources by mistake. You must prevent every user, including subscription Owners, from deleting any resource in RG-Prod, while still allowing them to scale, restart, and reconfigure those resources day to day.
What should you configure?
Show answer and explanation
Answer:
A management lock applies across all users and roles, overriding their RBAC permissions, even an Owner cannot delete through a lock. CanNotDelete (shown as Delete in the portal) means authorized users can read and modify a resource but cannot delete it, which is exactly the stated requirement. Locks applied at a parent scope are inherited by every resource in that scope, including resources created later, so a single lock on the resource group covers the whole workload.
Option B, a ReadOnly lock, is too restrictive. It blocks updates as well as deletes, roughly reducing everyone to Reader permissions, so the team could no longer scale or reconfigure. It also blocks operations that use POST, such as restarting a VM or listing storage account keys.
Option A does not solve the problem. Reassigning Owner at a narrower scope still leaves those users with delete rights inside RG-Prod, and it weakens administration elsewhere.
Option D is aimed at the wrong operation. Azure Policy evaluates resource *creation and update* requests; the deny effect is not the tool for blocking deletion of existing resources, and locks are the documented mechanism for that.
Reference: Lock your resources to protect your infrastructure