AZ-900 Practice Question 9: Resource Locks
Microsoft Azure Fundamentals (AZ-900) · Test 1 · question 9 of 10
A production resource group was deleted by mistake last quarter. Management now wants it to be impossible for anyone (including users holding the Owner role on the subscription) to delete the replacement resource group or anything inside it, while engineers keep the ability to reconfigure the resources it contains. What should be applied?
Show answer and explanation
Answer:
A management lock applies to all users and roles, overriding their permissions; that is what separates it from RBAC and makes it the right answer for "nobody, not even an Owner". A CanNotDelete lock (shown as Delete in the portal) lets authorized users read and modify a resource but not delete it, and locks applied at a parent scope are inherited by every resource in that scope, including ones added later.
Option B, a ReadOnly lock, also blocks deletion, but it additionally blocks updates (authorized users are effectively reduced to Reader) which contradicts the requirement that engineers keep reconfiguring resources. Option A is wrong because Azure Policy governs what resources may be created or how they must be configured; a Deny effect evaluates resource properties on write operations and is not the intended mechanism for protecting an existing object from deletion. Option D fails on two counts: Reader would also stop the engineers from making changes, and subscription-level Owners would still be able to delete the group because RBAC is inherited downward.
Reference: Lock your resources to protect your infrastructure