Azure resource locks: purpose, types, scope, and how they relate to RBAC
Slide deck explaining Azure resource locks: governance controls that block specific management actions to prevent accidental deletion or unwanted changes. Covers lock types (CanNotDelete, ReadOnly), scope, inheritance, differences from RBAC, control plane vs data plane, and common scenarios.
Azure resource locks: purpose, types, scope, and how they relate to RBAC
Introduction to Azure resource locks: governance controls that block specific management actions to prevent accidental deletion or unwanted changes.
Azure resource locks: purpose, types, scope, and how they relate to RBAC
Introduction to Azure resource locks: governance controls that block specific management actions to prevent accidental deletion or unwanted changes.
Resource locks: a safety catch
Resource locks block specific management actions to prevent accidental deletion or unwanted changes. Protect critical resources from accidental delete/update. Works as a governance control (not a recovery tool). Two lock types: CanNotDelete and ReadOnly. Applied at subscription, resource group, or resource scope.
Locks are enforced via Azure Resource Manager (ARM)
If a management request goes through ARM, a lock can block it—no matter which tool you use. Azure Resource Manager (ARM) equals management layer. Portal, Azure CLI, PowerShell, ARM/Bicep deployments use ARM. Portal labels: 'Delete' / 'Read-only'. API/CLI labels: 'CanNotDelete' / 'ReadOnly'.
Lock types: CanNotDelete vs ReadOnly
Choose the lock based on whether updates should remain possible. CanNotDelete: read plus update allowed, delete blocked. ReadOnly: read allowed, update plus delete blocked. Rule of thumb: 'block deletion' vs 'freeze changes'. Be careful: ReadOnly can break normal operations.
Lock scope and inheritance
Locks apply at subscription/resource group/resource, and inherited locks can be more restrictive. Scopes: Subscription to Resource group to Resource. Locks are inherited down the hierarchy. Most restrictive lock in the chain wins. 'Can't delete?' Check higher scopes too.
Scenario: prevent deletions, allow changes
Use CanNotDelete when you want normal operations to continue but deletion to be blocked. Apply CanNotDelete at resource group scope. Updates (scale/config) still work. Deletes are blocked (inherited by resources). Avoid ReadOnly if you still need routine changes.
Scenario: freeze a resource
Use ReadOnly when you want to block both updates and deletions at the management layer. Apply ReadOnly at resource scope (or higher if needed). Blocks updates and deletes. Good for 'must not change' resources. CanNotDelete still allows updates.
Locks vs Azure RBAC
Azure RBAC controls permissions; locks can still block specific management actions even when permissions allow them. Azure role-based access control (Azure RBAC): who can do what. Locks: block delete/update even if RBAC allows it. Useful as a temporary 'safety catch'. Not a replacement for good role design.
Control plane vs data plane
Locks target control plane (management) actions, not the service's data operations. Control plane (management plane): create/update/delete resource via ARM. Data plane: use the service (read/write/query data). Locks apply to control plane actions. Data plane permissions depend on the service and access controls.
Delete fails even with strong roles: check locks
If delete fails unexpectedly, look for inherited locks at higher scopes. Check locks at: Resource to Resource group to Subscription. Inheritance can block deletes from higher scopes. Remove the lock before delete can succeed. You need permission to manage locks.
Locks ≠ backup or disaster recovery
Locks prevent certain management actions; they don't restore resources or data. Locks reduce accidental control plane changes. No backups, no restore points created. Still plan backup and/or disaster recovery. Combine: prevention plus recovery.
Recap
Know what locks block, where they apply, and how they relate to Azure RBAC and control vs data actions. Pick lock type: CanNotDelete vs ReadOnly. Apply at correct scope; remember inheritance. Azure RBAC (permissions) plus locks (block actions). Control plane blocked; data plane may still work.