Azure Resource Locks – The One Feature You’re Probably Not Using (But Should Be)

Accidental deletion or modification of critical resources in Azure is more common than most teams would like to admit. And unlike on-prem environments, where layers of approvals or access barriers might slow someone down, Azure’s agility can sometimes be its own worst enemy — especially when production workloads are one click away from disappearing.

Enter: Azure Resource Locks — your environment’s seatbelt.

What Are Azure Resource Locks?

Azure Resource Locks are a built-in feature that allow you to restrict operations on resources, resource groups, or subscriptions. These locks act as a last line of defense — even if someone has Contributor or Owner permissions, a lock will block unwanted actions like deletion or configuration changes.

There are two types of locks:

1. ReadOnly

   • This mode allows viewing the resource, but no changes can be made.

   • It effectively turns the resource into a "look but don’t touch" object.

   • Note: Some services don’t support ReadOnly well — e.g., it may break monitoring agents or automation scripts.

2. CanNotDelete

   • The resource can still be modified, but cannot be deleted unless the lock is explicitly removed.

   • This is the most commonly used lock in production environments.

Applying Locks in Practice

You can apply locks at three scopes:

• Subscription

• Resource Group

• Resource

Example via Azure Portal:

1. Go to the resource/resource group.

2. Click on Locks in the sidebar.

3. Click Add, name your lock, choose the lock type (ReadOnly or CanNotDelete), and save.

Example via Azure CLI:

# Apply a ‘CanNotDelete’ lock on a resource group
az lock create \
  –name ProtectProdRG \
  –lock-type CanNotDelete \
  –resource-group Production-RG

Example via PowerShell:

New-AzResourceLock `
  -LockName "ProtectProdRG" `
  -LockLevel CanNotDelete `
  -ResourceGroupName "Production-RG"

Use Cases for Resource Locks

Let’s be real — you should be using locks if you’re managing live environments. Here’s where they make the most sense:

Resource Type	Recommended Lock	Reason
Resource Groups (Prod)	CanNotDelete	Prevent full RG wipeout
Azure VMs	CanNotDelete	Avoid deletion or re-creation by mistake
Key Vault	ReadOnly	Prevent unauthorized config changes
Storage Accounts	CanNotDelete	Ensure critical data isn’t lost
Azure Firewall / NSG	ReadOnly	Avoid accidental rule removal
Logic Apps / Functions	CanNotDelete	Prevent loss of core automation

Important Notes and Gotchas

Locks do not override RBAC, they supplement it. A user must still have permissions to create or remove a lock.

Locks can break automation — certain Azure services may fail to deploy or update if they’re under a ReadOnly lock.

Locks can be removed — so they’re not a security barrier. Treat them as operational safeguards.

Pro Tip: Automate Lock Enforcement with Azure Policy

If you’re managing a large-scale environment or multiple subscriptions, manually adding locks isn’t sustainable. Use Azure Policy to enforce locks across resource groups or tag-based conditions.

Example scenario:

Apply a CanNotDelete lock to all resources in RGs tagged with Environment = Production.

You can create a policy definition to audit or enforce lock usage — especially powerful when used in combination with Management Groups.

Final Thoughts

Resource Locks are not fancy. They’re not complex. But they’re absolutely essential.

If you’ve ever been called out at 3 a.m. because someone deleted the wrong resource — you’ll understand the value of a simple "CanNotDelete" lock. It costs nothing. Takes seconds to configure. And might just save your weekend.

---

Do it now: Review your production resource groups and apply at least CanNotDelete locks where needed. You’ll thank yourself later.