Resource locks (delete, read-only) in Azure - Commands & Configuration

Introduction

Sometimes you want to protect important cloud resources from accidental changes or deletion. Azure resource locks help you do this by preventing users from deleting or modifying resources unintentionally.

When you want to stop accidental deletion of a virtual machine that runs critical applications.

When you want to prevent changes to a storage account that holds important backups.

When multiple team members manage resources and you want to avoid accidental updates.

When you want to protect a resource group from being deleted while still allowing read access.

When you want to ensure compliance by locking resources in a read-only state.

Commands

This command creates a delete lock named 'LockDelete' on the virtual machine 'example-vm' in the resource group 'example-rg'. It prevents the VM from being deleted accidentally.

Terminal

az lock create --name LockDelete --lock-type CanNotDelete --resource-group example-rg --resource-name example-vm --resource-type Microsoft.Compute/virtualMachines

Expected Output

{

  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Compute/virtualMachines/example-vm/providers/Microsoft.Authorization/locks/LockDelete",

  "name": "LockDelete",

  "properties": {

    "level": "CanNotDelete",

    "notes": null

  },

  "type": "Microsoft.Authorization/locks"

}

→

--lock-type - Specifies the type of lock: CanNotDelete or ReadOnly

→

--resource-group - Specifies the resource group containing the resource

→

--resource-name - Specifies the name of the resource to lock

This command creates a read-only lock named 'LockReadOnly' on the storage account 'example-storage' in the resource group 'example-rg'. It prevents any changes or deletion to the storage account.

Terminal

az lock create --name LockReadOnly --lock-type ReadOnly --resource-group example-rg --resource-name example-storage --resource-type Microsoft.Storage/storageAccounts

Expected Output

{

  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Storage/storageAccounts/example-storage/providers/Microsoft.Authorization/locks/LockReadOnly",

  "name": "LockReadOnly",

  "properties": {

    "level": "ReadOnly",

    "notes": null

  },

  "type": "Microsoft.Authorization/locks"

}

→

--lock-type - Specifies the type of lock: CanNotDelete or ReadOnly

→

--resource-group - Specifies the resource group containing the resource

→

--resource-name - Specifies the name of the resource to lock

This command shows details about the 'LockDelete' lock on the virtual machine 'example-vm'. It helps verify the lock is applied correctly.

Terminal

az lock show --name LockDelete --resource-group example-rg --resource-name example-vm --resource-type Microsoft.Compute/virtualMachines

Expected Output

{

  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Compute/virtualMachines/example-vm/providers/Microsoft.Authorization/locks/LockDelete",

  "name": "LockDelete",

  "properties": {

    "level": "CanNotDelete",

    "notes": null

  },

  "type": "Microsoft.Authorization/locks"

}

This command removes the 'LockDelete' lock from the virtual machine 'example-vm', allowing deletion or modification again.

Terminal

az lock delete --name LockDelete --resource-group example-rg --resource-name example-vm --resource-type Microsoft.Compute/virtualMachines

Expected Output

No output (command runs silently)

Key Concept

If you remember nothing else from this pattern, remember: resource locks protect important Azure resources from accidental deletion or changes by enforcing delete or read-only restrictions.

Common Mistakes

Trying to delete a locked resource without removing the lock first.

Azure blocks deletion or modification of locked resources, causing errors.

Remove the lock using 'az lock delete' before deleting or modifying the resource.

Applying a read-only lock when only deletion prevention is needed.

Read-only locks prevent all changes, which might block needed updates.

Use a delete lock to only prevent deletion but allow updates.

Not specifying the correct resource type or name when creating a lock.

The lock will not apply to the intended resource, leaving it unprotected.

Double-check resource type and name to match the exact resource you want to lock.

Summary

Use 'az lock create' with --lock-type CanNotDelete or ReadOnly to protect Azure resources.

Verify locks with 'az lock show' to ensure they are applied correctly.

Remove locks with 'az lock delete' before making changes or deleting resources.

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