Azure Resource Locks: Preventing Accidental Deletion

Introduction

If you’ve worked in Azure for any length of time, you’ve probably experienced that moment of panic after clicking Delete on the wrong resource—or at least worried that it could happen. Whether it’s a production virtual machine, a storage account, or an entire resource group, accidental deletion can cause unexpected downtime and significant business impact.

What are Azure Resource Locks?

Azure Resource Locks are management settings that protect Azure resources from accidental changes. Even if a user has permission to delete or modify a resource, a lock can prevent that action from happening.

Think of a Resource Lock as putting a safety lock on an important switch. Even though someone has access to the switch, they can’t turn it off unless the lock is removed first.

Resource Locks can be applied at three different levels:

  • Subscription
  • Resource Group
  • Individual Resource

One important thing to remember is that locks are inherited. For example, if you apply a lock to a Resource Group, all resources inside that Resource Group automatically inherit the same lock.

This makes Resource Locks a simple yet powerful governance feature for protecting production environments.

Types of Azure Resource Locks

Azure provides two types of Resource Locks.

  1. CanNotDelete Lock

A CanNotDelete lock prevents a resource from being deleted but still allows users to modify it.

This is the most commonly used lock in production environments because administrators can continue making configuration changes while ensuring that no one accidentally deletes the resource.

Example

Suppose your production environment contains:

  • Production Virtual Machine
  • Azure SQL Database
  • Storage Account

A CanNotDelete lock allows administrators to:

Resize the VM

Restart the VM

Modify NSG rules

Update VM extensions

But if someone tries to delete the VM, Azure blocks the request and displays an error message.

This provides an extra level of protection without affecting day-to-day administration.

  1. ReadOnly Lock

A ReadOnly lock is more restrictive.

It prevents both modification and deletion of a resource.

Users can still view the resource, but they cannot:

  • Delete it
  • Change its configuration
  • Update its settings

ReadOnly locks are useful for resources that should remain unchanged, such as compliance-related resources or shared infrastructure components.

 

Recent Posts