Skip to main content
Imagine you’re working late, deploying updates, and a stray command accidentally deletes a critical DNS zone or other important resource. Azure resource locks are a simple, built-in safeguard that prevents accidental modification or deletion of resources across the management plane — Portal, ARM templates, CLI, and SDKs.

​
What resource locks do

  • Protect resources from accidental modification or deletion.
  • Act like a safety cover on a switch: prevent unintended on/off or removal.
  • Can be applied at three scopes: subscription, resource group, or single resource. Locks at a parent scope are inherited by child scopes.
  • Enforced consistently across Azure Portal, ARM, CLI, and SDKs.

​
Types of locks

A presentation slide titled "Resource Locks" showing four colorful panels that explain avoiding accidental changes, inheritance, read-only locks, and delete locks with icons and brief descriptions. Each card summarizes how those locks protect resources from modification or deletion.
To create, modify, or delete management locks you need appropriate RBAC permissions (for example, Owner, User Access Administrator, or a custom role that includes Microsoft.Authorization/locks/* or Microsoft.Authorization/* actions for the target scope). Ensure your account has these permissions before planning lock changes.

​
Hands-on: Creating locks in the Azure portal

  1. In the Azure portal, open the target resource group that contains the resource to protect.
  2. Select the resource (for example, an Automation Account). In the resource’s left menu, choose Locks.
  3. Click Add to create a new lock:
    • Enter a name (for example, DND for Do Not Delete).
    • Choose the lock type: CanNotDelete (delete lock) or ReadOnly.
    • Optionally add a note explaining the lock’s purpose.
    • Select Save.
  4. With a delete lock in place, attempts to delete the resource will fail with a scope-locked error. To delete the resource you must first remove the lock.
A screenshot of the Microsoft Azure portal showing an Automation Account named "cleanup-env" with a modal error saying the account could not be deleted (buttons: Retry, Cancel). A notification panel on the right explains the delete failed because the resource scope is locked and asks to remove the lock and try again.

​
Difference between delete and read-only locks

  • CanNotDelete (Delete lock): You can still modify the resource (for example, add or edit runbooks in an Automation Account), but you cannot delete it.
  • ReadOnly: Blocks all modifications. Creating or updating child resources or properties is prevented while this lock is present.
Example flow demonstrated:
  • With a delete lock on an Automation Account you can create a new runbook (PowerShell or Python) — the operation succeeds.
  • Replace the delete lock with a read-only lock (for example, name it RO). Attempts to create new runbooks or change the resource will now fail with a ScopeLocked error.
Screenshot of the Microsoft Azure portal on the "Create a runbook" page with fields filled (Name: "demo2", Runbook type: Python, Runtime 3.8). A pop-up error on the right reports the runbook creation failed because the resource scope is locked (Error code: ScopeLocked).

​
Inheritance: locks at higher scopes

  • Locks applied at the resource group level are inherited by all resources in that resource group.
  • Locks applied at the subscription level apply to every resource in the subscription.
  • Inherited locks behave the same way as locks set directly on the resource: they block deletion or modification according to the lock type.
Practical example:
  • Add a CanNotDelete lock called RG lock to a resource group. Attempts to delete a VM (and its disks/NICs) inside that group will fail because the VM inherits the delete lock.

​
Best practices

Be careful when removing locks to perform changes. Only users with adequate RBAC should remove or alter locks. After completing the change, reapply the lock immediately to restore protection.
Locks are a lightweight but powerful governance tool. Apply them thoughtfully to reduce accidental deletions or modifications and combine them with RBAC and monitoring for strong operational safety.

Watch Video