Resource locks (delete, read-only) in Azure - Deep Dive

Overview - Resource locks (delete, read-only)

What is it?

Resource locks in Azure are settings you apply to cloud resources to prevent accidental changes or deletions. There are two main types: delete locks stop resources from being deleted, and read-only locks prevent any changes to the resource. These locks help protect important resources by adding a safety layer. They are easy to apply and remove when needed.

Why it matters

Without resource locks, important cloud resources could be accidentally deleted or changed, causing downtime or data loss. This could disrupt services and cost time and money to fix. Resource locks help avoid these mistakes by making sure critical resources stay safe, even if someone tries to delete or modify them by accident.

Where it fits

Before learning about resource locks, you should understand basic Azure resources and how to manage them. After this, you can learn about Azure role-based access control (RBAC) to control who can apply or remove locks. Later, you might explore Azure policies for broader governance.

Mental Model

Core Idea

Resource locks act like safety covers on your cloud resources, stopping accidental changes or deletions by requiring extra steps to remove the lock first.

Think of it like...

Imagine a valuable book on a shelf with a clear plastic cover. The cover lets you see the book but stops you from tearing pages or throwing it away without first removing the cover carefully.

┌───────────────────────────────┐
│        Azure Resource          │
│  ┌─────────────────────────┐  │
│  │      Resource Lock      │  │
│  │ ┌───────────────┐      │  │
│  │ │ Delete Lock   │      │  │
│  │ │ Read-Only Lock│      │  │
│  │ └───────────────┘      │  │
│  └─────────────────────────┘  │
└───────────────────────────────┘

Lock prevents delete or changes until removed.

Build-Up - 7 Steps

1

Foundation

What are Azure resource locks

Concept: Introduction to the idea of resource locks and their types.

Azure resource locks are simple settings you add to resources to protect them. There are two types: Delete locks stop anyone from deleting the resource. Read-only locks stop anyone from changing the resource but still allow reading it.

Result

You understand that locks protect resources from accidental deletion or modification.

Knowing that locks add a safety layer helps prevent costly mistakes in managing cloud resources.

2

Foundation

How to apply resource locks

Concept: Learning the basic steps to add locks to Azure resources.

In the Azure portal, you select a resource, go to the 'Locks' section, and add a new lock. You choose the lock type (Delete or Read-only) and give it a name. Once applied, the lock immediately protects the resource.

Result

You can protect any resource by applying a lock through the portal.

Understanding the simple process of applying locks empowers you to safeguard resources quickly.

3

Intermediate

Effects of delete locks

🤔Before reading on: do you think a delete lock also stops changes to a resource? Commit to your answer.

Concept: Delete locks prevent deletion but allow changes to the resource.

A delete lock stops anyone from deleting the resource, but you can still update or modify it. For example, you can change settings or add data, but you cannot remove the resource entirely while the lock is active.

Result

Resources with delete locks stay safe from deletion but remain usable and changeable.

Knowing that delete locks only block deletion helps you choose the right lock type for your protection needs.

4

Intermediate

Effects of read-only locks

🤔Before reading on: do you think a read-only lock allows deleting the resource? Commit to your answer.

Concept: Read-only locks prevent any changes, including deletion, but allow reading the resource.

A read-only lock stops all modifications and deletions. You can view the resource and its data, but you cannot update, delete, or change it in any way until the lock is removed.

Result

Resources with read-only locks are fully protected from changes and deletion.

Understanding that read-only locks provide the strongest protection helps you secure critical resources.

5

Intermediate

Scope and inheritance of locks

Concept: Locks can be applied at different levels and affect child resources.

You can apply locks not only on individual resources but also on resource groups or subscriptions. Locks set on a group or subscription automatically protect all resources inside them. This helps protect many resources at once without locking each one separately.

Result

You can protect multiple resources efficiently by locking higher-level containers.

Knowing lock inheritance helps manage protection at scale and avoid missing important resources.

6

Advanced

Removing and overriding locks

🤔Before reading on: do you think anyone can remove a lock at any time? Commit to your answer.

Concept: Only users with proper permissions can remove locks, and locks can block some operations even for admins.

To remove a lock, you need the right Azure permissions (like Owner or User Access Administrator). Locks prevent accidental changes, but authorized users can remove them when needed. Locks cannot be bypassed by normal operations; they enforce protection strictly.

Result

Locks provide strong protection but can be managed by authorized users.

Understanding permission control around locks prevents accidental lock removal and enforces security.

7

Expert

Locks in automation and deployment pipelines

🤔Before reading on: do you think resource locks can interfere with automated deployments? Commit to your answer.

Concept: Resource locks can block automated scripts or deployments if not handled properly.

When using automation tools like Azure DevOps or ARM templates, resource locks can cause deployment failures if the script tries to delete or modify locked resources. Best practice is to design pipelines to check for locks or remove them safely before changes, then reapply locks after deployment.

Result

Automation respects locks and avoids accidental resource damage during deployments.

Knowing how locks interact with automation helps build reliable, safe deployment processes.

Under the Hood

Azure resource locks work by adding metadata tags to resources that the Azure Resource Manager (ARM) service checks before processing any delete or update requests. When a request comes in, ARM verifies if a lock exists and blocks the operation if it violates the lock type. This check happens at the control plane level, ensuring protection regardless of the client or tool used.

Why designed this way?

Locks were designed to prevent accidental destructive actions without changing resource permissions or roles. This approach allows quick protection without complex access control changes. Using metadata and ARM checks keeps the system flexible and efficient, avoiding performance hits on resource operations.

┌───────────────┐       ┌───────────────────────┐
│ User Request  │──────▶│ Azure Resource Manager │
└───────────────┘       └──────────┬────────────┘
                                    │
                            ┌───────▼────────┐
                            │ Check for Lock │
                            └───────┬────────┘
                                    │
               ┌────────────────────┴────────────────────┐
               │                                         │
      ┌────────▼────────┐                      ┌─────────▼─────────┐
      │ Lock Present?   │                      │ No Lock Present    │
      └────────┬────────┘                      └─────────┬─────────┘
               │ Yes                                      │ No
      ┌────────▼────────┐                      ┌─────────▼─────────┐
      │ Block Operation │                      │ Allow Operation   │
      └─────────────────┘                      └───────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does a delete lock also prevent changes to a resource? Commit to yes or no.

Common Belief: A delete lock stops all changes to a resource, not just deletion.

Reality: A delete lock only prevents deletion; changes and updates are still allowed.

Why it matters: Misunderstanding this can lead to insufficient protection if you want to prevent all changes.

Quick: Can a read-only lock be bypassed by an admin? Commit to yes or no.

Common Belief: Admins can bypass read-only locks easily because they have full permissions.

Reality: Read-only locks block all changes and deletions even from admins until the lock is removed.

Why it matters: Assuming admins can bypass locks may cause accidental resource changes if locks are not respected.

Quick: If you lock a resource group, do locks apply to all resources inside? Commit to yes or no.

Common Belief: Locks on a resource group do not affect individual resources inside it.

Reality: Locks on a resource group apply to all resources within it, protecting them automatically.

Why it matters: Not knowing this can cause confusion about why resources are locked unexpectedly.

Quick: Do resource locks protect against all types of resource changes? Commit to yes or no.

Common Belief: Resource locks protect against every possible change to a resource.

Reality: Locks only protect against delete or update operations; they do not control access or data changes inside the resource itself.

Why it matters: Overestimating lock protection can lead to security gaps if access controls are not also used.

Expert Zone

1

Locks do not prevent resource creation; they only protect existing resources from deletion or modification.

2

Applying locks at subscription or resource group level can cause unexpected blocking of operations on nested resources, requiring careful planning.

3

Locks are enforced by Azure Resource Manager, so operations done outside ARM (rare) might bypass locks, which is important for advanced scenarios.

When NOT to use

Avoid using resource locks when you need dynamic, frequent changes to resources or during active development phases. Instead, use role-based access control (RBAC) to manage permissions more flexibly. Locks are best for stable, critical resources where accidental changes must be prevented.

Production Patterns

In production, teams often apply read-only locks on critical infrastructure like databases and networking resources to prevent accidental changes. Delete locks are common on storage accounts or virtual machines to avoid accidental deletion. Automation pipelines include steps to temporarily remove locks for updates and reapply them after deployment.

Connections

Role-Based Access Control (RBAC)

Builds-on

Understanding resource locks alongside RBAC helps create layered security by controlling who can apply or remove locks, combining permission and protection.

Version Control Systems

Similar pattern

Like locks prevent accidental changes to cloud resources, version control systems use locks or branches to prevent accidental overwrites in code, showing a shared principle of protecting important assets.

Physical Safety Locks

Analogous concept from a different field

Just as physical locks prevent unauthorized access or damage to property, resource locks prevent accidental or unauthorized changes to digital assets, illustrating universal safety principles.

Common Pitfalls

#1 Trying to delete a resource with an active delete lock.

Wrong approach:

az resource delete --ids

Correct approach:

az lock delete --name --resource-id
az resource delete --ids

Root cause:

Not realizing that the delete lock must be removed before deletion causes operation failure.

#2 Applying a read-only lock when only deletion protection is needed.

Wrong approach:

az lock create --lock-type ReadOnly --name ReadOnlyLock --resource-group MyGroup

Correct approach:

az lock create --lock-type Delete --name DeleteLock --resource-group MyGroup

Root cause:

Confusing lock types leads to overly restrictive protection, blocking needed updates.

#3 Assuming locks prevent unauthorized access to resource data.

Wrong approach:

Relying solely on locks to secure sensitive data inside resources.

Correct approach:

Use RBAC and network security groups alongside locks to control access and protect data.

Root cause:

Misunderstanding that locks only prevent changes, not access, causes security gaps.

Key Takeaways

Azure resource locks protect cloud resources from accidental deletion or modification by adding a safety layer.

Delete locks prevent resource deletion but allow changes; read-only locks prevent all changes including deletion.

Locks can be applied at resource, group, or subscription levels and affect all nested resources.

Only users with proper permissions can remove locks, ensuring controlled management.

Understanding how locks interact with automation and permissions is key to using them effectively in production.

Practice

1. What does a CanNotDelete resource lock do in Azure?

easy

A. Allows all actions without restrictions

B. Prevents all changes including reading the resource

C. Allows deletion but prevents modifications

D. Prevents deletion but allows modifications to the resource

Solution

1. Step 1: Understand the purpose of CanNotDelete lock

   The CanNotDelete lock is designed to stop accidental deletion of a resource but still allows changes to it.

2. Step 2: Compare with other lock types

   Unlike ReadOnly, which blocks all changes, CanNotDelete only blocks deletion but permits modifications.

3. Final Answer:

   Prevents deletion but allows modifications to the resource -> Option D

4. Quick Check:

   CanNotDelete = Prevent deletion, allow changes [OK]

Hint: CanNotDelete stops delete, ReadOnly stops all changes [OK]

Common Mistakes:

• Confusing CanNotDelete with ReadOnly lock
• Thinking CanNotDelete blocks all changes
• Assuming CanNotDelete allows deletion

2. Which of the following is the correct JSON snippet to create a ReadOnly lock on a resource in Azure?

easy

A. { "lockLevel": "ReadOnly", "notes": "Block all changes" }

B. { "level": "CanNotDelete", "notes": "Prevent deletion" }

C. { "level": "ReadOnly", "notes": "Block all changes" }

D. { "lock": "ReadOnly", "notes": "Block all changes" }

Solution

1. Step 1: Identify the correct property name for lock level

   The correct property to specify the lock type is "level" with values like "ReadOnly" or "CanNotDelete".

2. Step 2: Match the correct JSON structure

   { "level": "ReadOnly", "notes": "Block all changes" } uses "level": "ReadOnly" which is the correct syntax to create a ReadOnly lock.

3. Final Answer:

   { "level": "ReadOnly", "notes": "Block all changes" } -> Option C

4. Quick Check:

   Lock level property = "level" with value "ReadOnly" [OK]

Hint: Use "level": "ReadOnly" to set read-only lock [OK]

Common Mistakes:

• Using incorrect property names like lockLevel or lock
• Confusing CanNotDelete with ReadOnly in JSON
• Missing quotes around property names or values

3. If a resource has a ReadOnly lock applied, what will happen when you try to update its configuration via Azure Portal?

medium

A. The update will fail with a permission error

B. The update will be queued for later processing

C. The update will succeed but deletion will be blocked

D. The update will succeed without any restrictions

Solution

1. Step 1: Understand ReadOnly lock behavior

   A ReadOnly lock blocks all changes to the resource, including updates, but allows reading.

2. Step 2: Predict the outcome of an update attempt

   Trying to update a resource with ReadOnly lock will cause a permission error and the update will fail.

3. Final Answer:

   The update will fail with a permission error -> Option A

4. Quick Check:

   ReadOnly lock blocks updates = update fails [OK]

Hint: ReadOnly blocks all changes, so updates fail [OK]

Common Mistakes:

• Assuming updates succeed with ReadOnly lock
• Confusing ReadOnly with CanNotDelete lock
• Thinking updates are queued instead of blocked

4. You applied a CanNotDelete lock on a storage account but still accidentally deleted it. What is the most likely reason?

medium

A. The lock was applied at the resource group level, not the storage account

B. The lock was not saved or applied correctly

C. The lock was applied as ReadOnly instead of CanNotDelete

D. The user had Owner role which bypasses locks

Solution

1. Step 1: Understand CanNotDelete lock effect

   CanNotDelete lock prevents deletion of the resource it is applied to.

2. Step 2: Analyze why deletion still happened

   If deletion occurred, the lock was likely not applied or saved correctly on the storage account.

3. Final Answer:

   The lock was not saved or applied correctly -> Option B

4. Quick Check:

   Lock must be properly applied to prevent deletion [OK]

Hint: Ensure lock is saved and applied on correct resource [OK]

Common Mistakes:

• Assuming Owner role bypasses locks (it does not)
• Confusing lock scope levels
• Thinking ReadOnly lock prevents deletion

5. You want to protect a critical Azure VM from accidental deletion but allow configuration changes. You also want to prevent any changes to a storage account except reading. How should you apply resource locks?

hard

A. Apply CanNotDelete lock on VM and ReadOnly lock on storage account

B. Apply ReadOnly lock on VM and CanNotDelete lock on storage account

C. Apply CanNotDelete lock on both VM and storage account

D. Apply ReadOnly lock on both VM and storage account

Solution

1. Step 1: Determine lock for VM to prevent deletion but allow changes

   Use CanNotDelete lock on VM to block deletion but allow configuration changes.

2. Step 2: Determine lock for storage account to block all changes except reading

   Use ReadOnly lock on storage account to block all changes but allow reading.

3. Final Answer:

   Apply CanNotDelete lock on VM and ReadOnly lock on storage account -> Option A

4. Quick Check:

   CanNotDelete = block delete, ReadOnly = block all changes [OK]

Hint: Use CanNotDelete for delete protection, ReadOnly for full lock [OK]

Common Mistakes:

• Swapping lock types between resources
• Using ReadOnly lock where changes are needed
• Applying same lock to both resources without need