Microsoft AZ-104: Resource Locks and Operational Safety
Azure resource locks protect management-plane resources from accidental deletion or modification even when a user otherwise has sufficient RBAC permission. Azure supports two primary lock levels: CanNotDelete, which blocks deletion while still allowing authorized updates, and ReadOnly, which blocks updates and deletion. Because locks override user permissions at the management plane and inherit from parent scopes, they are powerful safety controls—but they can also break legitimate operations if applied without understanding the resource lifecycle.
Microsoft’s current guidance is explicit that locks are not an authorization substitute. Azure RBAC grants permissions; locks add a broad restriction across users and roles. Locks also apply only to management-plane operations, so some data-plane actions can remain possible even when the resource itself is locked. Architecture should therefore use locks to protect critical lifecycle actions, while RBAC and service-specific controls protect access and data.
Operational safety through locks belongs inside Azure Architecture in Practice.
Use CanNotDelete for critical shared resources
Delete locks are useful for resources whose accidental removal would create a large outage, such as shared networking, key platform components, critical databases, or recovery infrastructure.
Policy and locks solve different problems: Policy evaluates resource configuration, while a lock prevents particular management operations.
Use locks where deletion risk is real and the operational team understands the required removal process.
Use ReadOnly sparingly
A ReadOnly lock can block legitimate configuration updates because it effectively prevents management-plane writes.
That can interfere with services, automation, extensions, diagnostic settings, and operational workflows that need to modify child or extension resources.
Reserve ReadOnly for resources that are intentionally static and have a tested maintenance procedure.
Understand lock inheritance
A lock at subscription or resource-group scope is inherited by resources below that scope, including resources added later.
The most restrictive inherited lock applies.
deployment boundaries should therefore avoid mixing highly protected resources with frequently changing resources if one group-level lock would make routine operations difficult.
Remember extension resources inherit locks
Microsoft documents that extension resources can inherit locks from the parent resource.
This matters for configuration such as diagnostic settings, because operators can discover they cannot delete or update an extension even though the extension itself has no visible lock.
Troubleshooting should inspect parent-scope locks before assuming RBAC is the cause.
Keep locks separate from data protection
A management lock can prevent deletion of a storage account resource while users with data-plane permissions may still modify or delete blobs according to the service’s data authorization model.
Use soft delete, versioning, immutable storage, backup, or service-specific retention where data protection is required.
Azure recovery combines management controls with recovery controls because a locked resource can still suffer data corruption or application-level deletion.
Document who can remove locks
Operational runbooks should identify the roles and process required to change or remove a lock.
Too many administrators with lock-management rights weaken the safety value; too few can delay legitimate recovery or maintenance.
RBAC design should treat lock administration as a privileged control-plane capability.
Protect backup and recovery infrastructure
Locks are useful around critical recovery resources when applied according to service guidance.
Azure Backup also offers purpose-built controls such as soft delete, immutability, and multi-user authorization that protect recovery points more directly.
Use locks as one layer rather than assuming a vault lock alone makes backups tamper resistant.
Test maintenance before locking broadly
Apply candidate locks in lower environments or on representative resources and run deployment, scaling, patching, diagnostics, backup, and monitoring changes.
A lock that blocks the deployment pipeline or required service updates can create operational pressure to remove it permanently.
Safety controls are strongest when routine procedures work with them instead of around them.
Use locks as intentional friction
For Azure administration, the durable rule is: RBAC decides who may act, Policy decides what configuration should be allowed, and locks add friction against destructive management operations.
Use the smallest lock scope that protects the critical lifecycle boundary and review it when resources or automation change.
Operational safety comes from layered controls plus tested recovery, not from freezing an entire environment indiscriminately.
Locks can also affect resource-group deletion. A delete lock on one child resource can block deletion of the entire resource group because Azure does not partially delete a group and leave the locked child behind. This is useful protection but can surprise cleanup automation.
Subscription cancellation is different: Microsoft notes that resource locks do not prevent cancellation of the subscription itself. Enterprise offboarding therefore needs billing and subscription-governance controls as well as resource locks.
IaC pipelines should detect and manage expected locks explicitly. Avoid scripts that remove locks globally before deployment and recreate them afterward, because a failed run can leave critical resources unprotected. Prefer targeted changes with clear guard conditions.
Review locks periodically. A lock created for a migration or cutover can become technical debt once the resource enters a different lifecycle. Every lock should have an owner, reason, and maintenance procedure so the safety control remains understood instead of becoming unexplained friction.
Lock scope should match the failure consequence. A subscription-level lock is extremely broad and can block normal operations across many teams, while a resource-level lock can protect one critical object with less collateral impact. Resource-group locks are useful only when the group truly shares lifecycle and protection requirements.
Locks and deployment pipelines should be designed together. If a deployment legitimately replaces a resource, the pipeline should have a controlled method to remove and restore the relevant lock rather than depend on manual portal work. That workflow should fail safely if the deployment aborts before the lock is recreated.
ReadOnly locks can have unexpected effects because many Azure services manage child or extension resources behind the scenes. Before applying them to production, test monitoring, backup, autoscale, diagnostics, policy remediation, extension updates, and service-specific maintenance operations.
CanNotDelete is often a better default for critical shared resources because it preserves configuration changes while preventing accidental removal. Even so, deletion might be a valid recovery action during a migration, so the lock owner and approved removal process should be documented.
Locks should not be used to compensate for weak RBAC. A user with overly broad Contributor or Owner access can still make harmful modifications when only a delete lock exists. Narrow permissions first, then add locks for destructive operations whose accidental execution remains unacceptable.
Likewise, locks do not replace Azure Policy. Policy can prevent or remediate disallowed configurations such as public exposure or missing tags. Locks do not evaluate configuration; they simply restrict management operations on the locked scope.
Backup and security teams should agree which recovery resources require locks and which require immutability or multi-user authorization instead. An immutable backup vault is designed to resist destructive backup changes more directly than a generic resource lock, while the lock can still protect the vault object itself from accidental deletion.
Operational runbooks should include lock discovery. When an update returns authorization-like errors despite correct RBAC, check locks on the resource, resource group, and subscription before escalating. This small diagnostic step avoids unnecessary role changes that weaken security without solving the real problem.
Resource locks should have business context. A description or external inventory can record owner, reason, protected service, expected duration, and required approver for removal. Unexplained locks become technical debt because future operators cannot tell whether removing them is safe.
Review locks after migrations, cutovers, and project completion. Temporary protection during a risky change is useful; permanent protection without continued need adds friction and can interfere with automation years later.
Extension-resource behavior should be part of lock design because some platform features create child configuration under the resource ID. Diagnostic settings, private endpoint connections, and certain service operations can inherit a parent lock in ways that surprise teams who only inspect the child object.
Resource providers may also use POST operations for actions that feel like reads. A ReadOnly lock can therefore block service operations that do not look like conventional updates. Test the actual management workflow rather than infer behavior from the UI label.
Lock administration should appear in audit and incident review. An unexpected lock removal before a resource deletion can be a meaningful security signal, while a new broad lock can be an availability risk if it blocks automation.
During recovery, operators should know whether a lock is protecting the damaged resource or preventing the recovery action. The runbook should identify which locks can be removed temporarily, who approves that change, and how the lock is restored after recovery.
Operational safety comes from making destructive actions difficult but still supportable. A lock that nobody understands often becomes an obstacle; a lock with owner, purpose, and tested maintenance path becomes a reliable guardrail.
Locks should be included in service ownership documentation. If a central platform team owns a locked hub resource and a workload team owns the dependent application, both sides need to know how emergency changes are requested and who can approve them.
Use automation to report existing locks and detect unexpected changes. Inventory by subscription and resource group can expose forgotten ReadOnly locks or critical resources that lost their expected delete protection after a migration.
Do not lock ephemeral or frequently redeployed resources without understanding the deployment model. Immutable infrastructure often replaces resources by design, so a delete lock can directly conflict with the intended release strategy.
The best lock strategy is selective: protect the few resources whose accidental lifecycle change would create disproportionate harm, preserve normal automation elsewhere, and rely on RBAC, Policy, backup, and service-specific controls for the other security objectives.