2.3.3. Resource Locks
💡 First Principle: Some of the worst outages aren't caused by attackers — they're caused by an authorized person accidentally deleting or modifying a resource they had every right to touch. Resource locks add a deliberate speed bump specifically against accidental changes, independent of RBAC permissions.
A CanNotDelete lock allows authorized users to read and modify a resource but blocks deletion. A ReadOnly lock is stricter — it prevents any modification at all, including actions that RBAC would otherwise permit, effectively freezing the resource's configuration. Locks apply at the scope they're set (subscription, resource group, or individual resource) and are inherited downward.
⚠️ Exam Trap: A resource lock is not an access control mechanism and does not appear in RBAC role assignments — someone can still have full Owner rights on a locked resource and simply be blocked from the locked action specifically. Don't confuse "this resource is locked" with "this user lacks permission."
Reflection Question: A production database was accidentally deleted by an engineer who had valid Contributor rights to do so. Which resource lock type would have prevented this without needing to change the engineer's RBAC role at all?
