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.
\nMicrosoft’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.
\nA 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.
\nThe following steps are DSE recommendations based on the cited source.
\nCanNotDelete unless a tested need justifies ReadOnly.CanNotDelete.