A compliance officer at Cascade Regional Airlines applies a CanNotDelete resource lock at the subscription level covering the entire Outstations subscription. Can a resource group owner within that subscription, who holds the Owner role on just their own resource group, delete that resource group?
Select an answer to reveal the explanation.
Short Explanation
A lock set at the subscription level rolls downhill onto everything underneath it, the same way a building-wide fire-exit rule applies to every floor whether or not each floor manager agrees with it. Owner on one floor doesn't get you an exemption from a rule set above you.
Full Explanation
Resource locks, like RBAC role assignments, are inherited down the Azure Resource Manager scope hierarchy: a lock placed at the subscription scope automatically applies to every resource group and resource contained within that subscription, without needing to be reapplied anywhere else. When multiple locks exist at different levels, the most restrictive one governs the outcome; a CanNotDelete lock at the subscription therefore blocks deletion of any resource group beneath it. Holding Owner on the resource group has no bearing here because the lock check is independent of RBAC permission evaluation; Owner grants extensive permissions but no exemption from a lock enforced above that scope. Adding User Access Administrator doesn't change this either, since that role only affects who can assign other roles, not whether a lock applies. The claim that the lock needs to be reapplied at each resource group gets the inheritance model backwards, one lock at the top is sufficient and is the more common way to protect an entire subscription's structure in one step. One caveat: only someone with permission to modify locks, typically at or above the scope where it was placed, can remove it. Confirm the effective lock state on a resource group using the Locks blade, which shows locks inherited from parent scopes as well as ones set directly.