Even a subscription Owner cannot delete a locked production vault until the lock is removed. What fundamentals idea about resource locks does that illustrate?
Select an answer to reveal the explanation.
Short Explanation
Locks sit above the usual permission story. Even Owner has to take the lock off before a protected delete goes through. That is the point—accidental heroics still get stopped.
Full Explanation
Resource locks restrict everyone—including Owners and other privileged roles—until the lock is removed. That is the fundamentals idea behind “even a subscription Owner cannot delete a locked production vault”: the lock is a management-plane safeguard layered on top of RBAC, not a soft suggestion that high privilege can ignore. Someone with rights to edit locks must explicitly remove the lock before the delete operation can succeed.
Owner role does not always bypass locks without an extra unlock step. Locks are not limited to Guest users and never applied to Owners—the opposite is true in production vaults. Locks also do not permanently convert Owner into Reader; once the lock is removed, role capabilities work again as assigned in Microsoft Entra ID and Azure RBAC.
Exam caveat: the people who can remove locks must themselves be tightly controlled and audited—otherwise the safeguard is only as strong as the weakest lock administrator on the municipal team. Operational check: as Owner on a lab vault or resource group, apply a CanNotDelete lock, attempt deletion and confirm failure, have a second authorized admin remove the lock, retry deletion successfully only in the lab, then document a two-person remove-lock procedure for production vaults.