Production Azure VMs without a CanNotDelete resource lock

Permissions allow deletion; locks override permissions

Azure RBAC decides who may delete a VM, and in most subscriptions plenty of identities can: contributors, automation accounts, CI pipelines. A management lock sits above those permissions. With a CanNotDelete lock, authorized users can still read and modify the VM but cannot delete it until someone removes the lock first.

That second step is the point. A mistyped script, a cleanup job with the wrong filter or a rushed console click fails loudly instead of taking production down.

Checking a VM for locks

az lock list --resource-group my-rg \
  --resource-name my-vm --resource-type Microsoft.Compute/virtualMachines --namespace ""

Locks applied at the resource group or subscription are inherited, so also run az lock list --resource-group my-rg to see locks at the group level.

Three gates before it fires

1. The VM is provisioned successfully or running.
2. The VM is classified as production. A name containing prod, production, prd or live counts, unless the name also marks it as dev or test; so does an env, environment, stage or tier tag whose value is one of those words.
3. Azure’s lock data for the VM shows it has no deletion protection. The finding says whether the name or the tag made the VM production.

When the finding is withheld

Non-production VMs are not evaluated; deletion protection is aimed at critical workloads. If ZopNight has no lock information for a VM, it does not assume the VM is unprotected. In that case it fires only if you have explicitly tagged the VM deletion_protection=false yourself.

A zero-cost safeguard

The estimate is fixed at $0 per month. Locks are free, and the risk they remove is the outage and restore effort that follows an accidental deletion.

Adding the lock

1. Make sure you have rights to manage locks. Microsoft notes that Owner and User Access Administrator have them, via Microsoft.Authorization/locks/*.
2. Create the lock:

az lock create --name protect-vm --lock-type CanNotDelete \
  --resource-group my-rg --resource-name my-vm \
  --resource-type Microsoft.Compute/virtualMachines

3. Consider locking the whole resource group instead, so disks, NICs and anything added later inherit the lock.
4. Run az lock list again to confirm the lock is in place.