Use Azure resource locks as a deletion guard—not a backup or permission boundary

Bottom line: Azure Resource Manager locks can prevent deletion or make a resource read-only at the management plane. Locks inherit from a parent scope, and the most restrictive applicable lock controls the resource. They are guardrails against authorized management mistakes, not backups, immutable security boundaries, or universal blocks on data operations.

Source fact: what Microsoft documents

Microsoft’s resource-lock documentation defines two levels. CanNotDelete permits authorized updates but blocks deletion. ReadOnly permits reads but blocks updates and deletion. Locks can be assigned at subscription, resource-group, or resource scope and inherited by child resources.

Microsoft distinguishes lock behavior from Azure RBAC. A user may have permission to modify a resource but still be blocked by a lock; a user with appropriate lock-management permission can remove the lock. The page documents that locks apply to control-plane operations sent to Azure Resource Manager and may not block data-plane operations. It also lists resource-specific consequences: read-only locks can disrupt operations that use control-plane writes even when the action sounds observational or operational.

What the source does not establish

A lock does not create a recoverable copy, stop data deletion through every service API, prevent compromise by someone who can remove the lock, or make an application available. A lock at the wrong scope can block deployments, scaling, secret rotation, backup configuration, monitoring, or legitimate incident response. The presence of a lock does not prove that protected data is immutable.

Applicability questions

• Is the concern accidental resource deletion, unintended configuration change, data deletion, or all three?
• Which operations use the Azure control plane versus the service’s data plane?
• Should the lock be at resource, resource-group, or subscription scope, and what unrelated children inherit it?
• Who can create or remove locks and who approves temporary removal?
• Which deployment, backup, autoscale, monitoring, rotation, and incident workflows perform blocked writes?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Select critical resources whose accidental deletion has material consequence and prefer CanNotDelete unless a tested need justifies ReadOnly.
2. Apply at the narrowest useful scope and inventory inherited resources before creation.
3. Restrict lock-management permissions and require a ticket, approver, purpose, and short window for removal.
4. Test infrastructure deployment, maintenance, backup, monitoring, scaling, rotation, and recovery with the lock present.
5. Keep independent backup, immutability, data authorization, and recovery controls for the relevant service.

Verification and evidence

• Preserve lock name, level, scope, inheritance, owner, rationale, and approval.
• Demonstrate an authorized deletion is blocked and an expected allowed update still succeeds for CanNotDelete.
• Record data-plane tests separately; do not infer their result from a management-plane rejection.
• Audit lock creation and removal and alert on unplanned changes at critical scopes.

Official references

• Lock your Azure resources to protect your infrastructure — Microsoft