Academmia

Azure resource locks: purpose, types, scope, and how they relate to RBAC

az-900•mixed•

Management and governance

Azure resource locks: purpose, types, scope, and how they relate to RBAC

Short Summary

Azure resource locks help you protect important resources from accidental deletion or unwanted changes. You’ll learn the two lock types and what actions each one blocks. You’ll also see where locks apply (scope and inheritance) and how they differ from Azure role-based access control (Azure RBAC).

Learning Objectives

By the end of this lesson, you will be able to:

  • Define the purpose of Azure resource locks
  • Differentiate between CanNotDelete and ReadOnly locks
  • Identify where locks can be applied and how inheritance works
  • Explain how locks interact with Azure RBAC and control plane vs data plane actions

Core Concepts

What a resource lock is

An Azure resource lock is a governance control that blocks certain management actions so you don’t accidentally delete or modify critical resources. Think of it as a “safety catch” for changes made through Azure’s management layer.

Locks are enforced through Azure Resource Manager (ARM), which is the service behind the Azure portal, Azure CLI, PowerShell, and ARM/Bicep deployments. If a management request goes through ARM, a lock can block it.

Tip: In the Azure portal, the lock types are shown as Delete and Read-only. In command-line tools and APIs, you’ll often see them as CanNotDelete and ReadOnly.

The two lock types

  • CanNotDelete: You can read and update the resource, but you can’t delete it.
  • ReadOnly: You can read the resource, but you can’t update or delete it.

A simple way to remember it:

  • CanNotDelete = “changes allowed, deletion blocked”
  • ReadOnly = “no changes, no deletion”

Where locks can be applied

You can apply a lock at these scopes:

  • Subscription
  • Resource group
  • Resource

Locks are inherited. If you lock a resource group, resources inside it inherit that lock. The most restrictive lock in the chain wins.

Locks vs Azure RBAC

These solve different problems:

  • Azure RBAC answers: “Who is allowed to do what?”
  • Locks answer: “Even if someone is allowed, should this action be blocked right now?”

That’s why a delete can fail even for someone with a powerful role: a lock can block the action even if RBAC permissions would otherwise allow it.

Control plane vs data plane

Azure actions fall into two buckets:

  • Control plane (management plane): create/update/delete the resource itself (via ARM).
  • Data plane: use the data capabilities of the resource (for example, query a database, read/write blobs).

Locks apply to control plane operations. They don’t automatically block data plane actions. For example, a lock can prevent deleting a database resource, but it doesn’t necessarily stop someone from deleting rows using database queries.

Practical Understanding

Practical Situation 1: “I want to stop deletions, but still allow changes.”

You have a production resource group. People need to update settings and scale resources, but you want to prevent accidental deletion.

How to think about it: Use a CanNotDelete lock at the resource group scope. Updates can continue, but delete operations are blocked at that scope (and inherited by resources under it).

Common misunderstanding: “ReadOnly is always better because it’s stricter.” ReadOnly will block the day-to-day updates you still need.

Practical Situation 2: “This resource must not change, period.”

You have a critical resource that should not be modified or deleted during normal operations.

How to think about it: Use a ReadOnly lock on the resource (or at a higher scope if you want the same rule for a set of resources). ReadOnly blocks both updates and deletions.

Common misunderstanding: “CanNotDelete also prevents changes.” CanNotDelete still allows updates.

Practical Situation 3: “I’m Owner/Contributor, but delete still fails.”

You try to delete a resource, but Azure rejects the operation even though your role normally includes delete permissions.

How to think about it: Check for a lock at the resource, resource group, or subscription scope. If a lock exists, you’ll need to remove it (and you must have permission to manage locks) before the delete can succeed.

Common misunderstanding: “RBAC permissions always win.” Locks can block actions even when RBAC allows them.

Practical Situation 4: “Is a lock the same as backup or disaster recovery?”

You want protection against losing a resource, and someone suggests adding a lock.

How to think about it: A lock is preventive (it reduces accidental management changes). It does not create copies or recovery points. For recovery after loss, you still need backup and/or disaster recovery planning.

Common misunderstanding: “If it prevents deletion, it’s basically a backup.” Prevention and recovery are different controls—you often want both.

Common Pitfalls

  • Mistake: Relying on Azure RBAC alone to prevent deletions. Correction: RBAC grants permissions, but locks can add a blanket “block delete/update” rule until the lock is removed.

  • Mistake: Choosing ReadOnly when you still need normal operations (scaling, config updates). Correction: Use CanNotDelete when you want to block deletion but still allow updates.

  • Mistake: Forgetting that locks inherit from higher scopes. Correction: If something “suddenly can’t be deleted,” check locks at the resource group and subscription scopes too.

  • Mistake: Treating locks as a backup/disaster recovery feature. Correction: Locks prevent specific management actions; they don’t restore data or resources.

  • Mistake: Assuming locks block all actions inside a service. Correction: Locks apply to control plane operations; data plane actions may still be possible depending on the service and how the action is performed.

Check Your Understanding

  1. Explain (in one sentence each) what Azure RBAC controls and what resource locks control.
  2. Write a rule of thumb for choosing between CanNotDelete and ReadOnly.
  3. If you apply a lock at the subscription scope, what happens to resources under that subscription, and why can that be useful?
  4. You can’t delete a resource even though your role includes delete. What are the first two scopes you check for a lock?
  5. Give one example where a lock helps prevent an incident, but you still need a recovery plan.

Further Reading