Resource locks (delete, read-only) in Azure - Step-by-Step Execution

Process Flow - Resource locks (delete, read-only)

Start

↓

Apply Lock

↓

Lock Type?

Delete Lock→Block Delete Actions

↓

Block Delete & Modify Actions

↓

Try Operation

↓

Is Operation Allowed?

Yes→Operation Succeeds

↓

Operation Fails with Lock Error

↓

End

This flow shows how applying a resource lock in Azure controls what operations are allowed or blocked on that resource.

Execution Sample

Azure

az lock create --name Lock1 --lock-type CanNotDelete --resource-group MyGroup --resource MyVM --resource-type Microsoft.Compute/virtualMachines
az vm delete --name MyVM --resource-group MyGroup
az lock create --name Lock2 --lock-type ReadOnly --resource-group MyGroup --resource MyVM --resource-type Microsoft.Compute/virtualMachines
az vm update --name MyVM --resource-group MyGroup --set tags.env=prod

This sequence applies a delete lock, tries to delete a VM (blocked), then applies a read-only lock and tries to update the VM (blocked).

Process Table

Step	Action	Lock State	Operation Attempted	Allowed?	Result
1	Create Delete Lock on MyVM	Delete Lock	None	N/A	Lock applied successfully
2	Attempt to Delete MyVM	Delete Lock	Delete VM	No	Operation blocked: delete lock prevents deletion
3	Create Read-Only Lock on MyVM	Read-Only Lock	None	N/A	Lock applied successfully
4	Attempt to Update MyVM Tags	Read-Only Lock	Update VM	No	Operation blocked: read-only lock prevents modification
5	Attempt to Read MyVM Info	Read-Only Lock	Read VM	Yes	Operation succeeds: read allowed under read-only lock
6	Remove Locks	No Lock	None	N/A	Locks removed, operations allowed
7	Attempt to Delete MyVM	No Lock	Delete VM	Yes	Operation succeeds: no lock present

💡 Locks block operations based on type; delete locks block deletion, read-only locks block deletion and modification but allow reading.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 6	Final
Lock State	None	Delete Lock	Read-Only Lock	No Lock	No Lock
Operation Allowed	N/A	No (Delete)	No (Update)	N/A	Yes (Delete)

Key Moments - 3 Insights

Why does the delete operation fail at step 2 but reading the VM info at step 5 succeeds?

Because the delete lock blocks delete actions but allows read actions. At step 5, the read-only lock allows reading, so the operation succeeds (see execution_table rows 2 and 5).

What is the difference between a delete lock and a read-only lock?

A delete lock only blocks deletion, while a read-only lock blocks deletion and any modification but allows reading (see execution_table steps 1 and 3).

What happens after locks are removed at step 6?

All operations are allowed again, so deleting the VM at step 7 succeeds (see execution_table rows 6 and 7).

Visual Quiz - 3 Questions

Look at the execution table, what is the lock state after step 3?

A Read-Only Lock

B Delete Lock

C No Lock

D Unknown

💡 Hint

Check the 'Lock State' column at step 3 in the execution_table.

At which step does the delete operation become allowed?

A Step 2

B Step 7

C Step 5

D Step 4

💡 Hint

Look at the 'Operation Attempted' and 'Allowed?' columns for delete operations in the execution_table.

If the read-only lock was not applied at step 3, what would happen at step 4 when updating the VM?

A Update would be blocked

B Delete would be blocked

C Update would succeed

D Read would be blocked

💡 Hint

Refer to the 'Lock State' and 'Allowed?' columns at step 4 and consider absence of read-only lock.

Concept Snapshot

Resource locks in Azure protect resources from unwanted changes.
Delete lock blocks only delete operations.
Read-only lock blocks delete and modify operations but allows reading.
Locks help prevent accidental or unauthorized changes.
Locks can be applied or removed anytime via Azure CLI or portal.

Full Transcript

Resource locks in Azure help protect resources by blocking certain operations. There are two main types: delete locks and read-only locks. A delete lock prevents the resource from being deleted but allows other changes. A read-only lock prevents deletion and any modifications but still allows reading the resource. When a lock is applied, operations that are blocked will fail with an error. Removing the lock restores full access. This trace showed applying a delete lock, trying to delete the resource (blocked), then applying a read-only lock and trying to update the resource (blocked), and finally removing locks to allow deletion. Understanding these locks helps keep resources safe from accidental or unauthorized changes.

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