Azure Resource Locks & Resource Movement

📋 Table of Contents

What Are Resource Locks in Azure?
Lock Types: CanNotDelete vs ReadOnly
Lock Scope & Inheritance
Resource Movement in Azure
Movement Prerequisites & Limitations
Lab: Creating & Testing Resource Locks
Lab: Moving Resources Across Resource Groups
PowerShell & CLI Commands
Best Practices & Key Takeaways

What Are Resource Locks in Azure?

In enterprise cloud environments, accidental deletion or modification of critical Azure resources can lead to catastrophic outages, data loss, and compliance violations. Microsoft Azure addresses this risk through a built-in governance feature called Resource Locks.

Azure Resource Locks are governance controls that can be placed at the subscription, resource group, or individual resource level. They prevent unauthorized or unintended modifications to Azure resources — independent of the Azure Role-Based Access Control (RBAC) permissions a user holds.

Key Insight for AZ-104 Exam: Resource Locks override RBAC permissions. Even if a user has Owner-level access, a lock will prevent them from deleting or modifying a resource unless the lock itself is removed first. This is a critical distinction tested in the AZ-104 exam.

💡

Real-world Use Case: In your AZ104-Governance-RG resource group, applying a CanNotDelete lock on a Production Virtual Network ensures that no team member — regardless of their RBAC role — can accidentally delete it during a maintenance window.

Lock Types: CanNotDelete vs ReadOnly

Azure provides two types of resource locks, each offering a different level of protection based on your governance requirements.

🔴

CanNotDelete

Users can read and modify the resource, but cannot delete it. This is the most commonly used lock type in production environments.

Read operations: ✅ Allowed
Modify/Update: ✅ Allowed
Delete: ❌ Blocked

High Protection

🟡

ReadOnly

Users can only read the resource. No modifications, updates, or deletions are permitted. Equivalent to applying Reader RBAC role.

Read operations: ✅ Allowed
Modify/Update: ❌ Blocked
Delete: ❌ Blocked

Maximum Restriction

⚠️

ReadOnly on Storage Accounts: Applying a ReadOnly lock to a Storage Account will prevent listing storage keys — since listing keys is classified as a POST action, not a GET. This can break applications that rely on key-based access. Plan carefully before applying ReadOnly locks to storage resources.

Section 03 — Scope & Inheritance

Lock Scope & Inheritance

One of the most important concepts for the AZ-104 exam and real-world usage is how lock inheritance works across the Azure resource hierarchy.

Lock Applied At	Subscription Protected	Resource Group Protected	Individual Resource Protected
Subscription Level	✔ Yes	✔ Yes (inherited)	✔ Yes (inherited)
Resource Group Level	✘ No	✔ Yes	✔ Yes (inherited)
Resource Level	✘ No	✘ No	✔ Yes

In your AZ104-Governance-RG, if you apply a lock at the resource group level, all child resources (VMs, Storage Accounts, VNets, NSGs, etc.) will inherit that lock automatically — you do not need to apply it individually to each resource.

Resource Movement in Azure

Azure Resource Movement is the capability to move resources from one resource group to another, or from one subscription to another, without losing any configuration, data, or existing connections — in most cases.

Moving resources is essential for scenarios like organizational restructuring, subscription consolidation, environment promotion (Dev → Prod), and cost management.

SCENARIO 01

🔄 Cross-RG Move

Move resources from AZ104-Governance-RG to another resource group within the same subscription.

SCENARIO 02

🌐 Cross-Subscription Move

Transfer resources to a different Azure subscription — both subscriptions must be in the same Azure AD tenant.

SCENARIO 03

🌍 Cross-Region Move

Use Azure Resource Mover to relocate resources to a different Azure region — this is a separate service with a different workflow.

Section 05 — Prerequisites & Limitations

Movement Prerequisites & Limitations

🚫 Resources That Cannot Be Moved

Resource Type	Can Move Same Sub	Can Move Cross-Sub
Azure AD Domain Services	✘	✘
Recovery Services Vault (with data)	✘	✘
Azure Kubernetes Service (AKS)	✘	✘
Virtual Machines (Classic)	✘	✘
App Service Certificates	✔	✘
Virtual Machines (ARM, no ext.)	✔	✔
Storage Accounts	✔	✔

Required RBAC Permissions to Move

To move resources, the user account must have the following permissions on both the source and destination resource groups:

Microsoft.Resources/subscriptions/resourceGroups/moveResources/action
Microsoft.Resources/subscriptions/resourceGroups/write

🔒

Lock Impact on Movement: A CanNotDelete lock does NOT block resource movement. However, a ReadOnly lock WILL block movement because movement is a write operation on the resource group. Always remove ReadOnly locks before attempting a resource move.

🔬 Creating & Testing Resource Locks

In this lab, we will work inside AZ104-Governance-RG to create both lock types and verify their behavior using the Azure Portal and Azure CLI.

Part A — Create a CanNotDelete Lock via Azure Portal

Resource Group: AZ104-Governance-RG

Open Your Resource Group In the search bar, type Resource groups and click the service. Locate and click on AZ104-Governance-RG.

Azure Resource Locks & Resource Movement 8

Navigate to Locks In the left-hand menu (Settings section), click Locks. Home › Resource groups › AZ104-Governance-RG › Settings › Locks

Add a New Lock Click + Add button at the top. Fill in the form: • Lock name:DoNotDelete-Governance-Lock
• Lock type: Delete

• Notes: Prevents accidental deletion of governance resources

Save the Lock Click OK to apply the lock. The lock will appear in the Locks list within seconds.

✅ Verify: Attempt to delete the resource group by clicking “Delete resource group” in the Overview blade. You should see the error: “The scope ‘AZ104-Governance-RG’ cannot be deleted because it has a delete lock.”

Part B — Create Locks Using Azure CLI

PowerShell & CLI approach for automation

Azure CLI — CanNotDelete Lockbash

# Create a CanNotDelete lock on AZ104-Governance-RG
az lock create \
  --name "DoNotDelete-Governance-Lock" \
  --resource-group "AZ104-Governance-RG" \
  --lock-type CanNotDelete \
  --notes "Protects governance resources from accidental deletion"

# List all locks on the resource group
az lock list \
  --resource-group "AZ104-Governance-RG" \
  --output table

# Delete the lock when no longer needed
az lock delete \
  --name "DoNotDelete-Governance-Lock" \
  --resource-group "AZ104-Governance-RG"

PowerShell — ReadOnly Lockps1

# Connect to Azure (if not already connected)
Connect-AzAccount

# Create a ReadOnly lock on the resource group
New-AzResourceLock `
  -LockName "ReadOnly-Governance-Lock" `
  -LockLevel ReadOnly `
  -ResourceGroupName "AZ104-Governance-RG" `
  -LockNotes "Full read-only protection during maintenance" `
  -Force

# View all locks
Get-AzResourceLock -ResourceGroupName "AZ104-Governance-RG"

# Remove the lock
$lock = Get-AzResourceLock `
  -LockName "ReadOnly-Governance-Lock" `
  -ResourceGroupName "AZ104-Governance-RG"

Remove-AzResourceLock -LockId $lock.LockId -Force

🚀 Lab: Moving Resources Across Resource Groups

In this lab, we will move a resource from AZ104-Governance-RG to a new destination resource group using the Azure Portal and PowerShell.

📌

Pre-requisite: Ensure no ReadOnly lock is active on AZ104-Governance-RG before proceeding. A CanNotDelete lock is fine — it will not block the move operation.

Part A — Move Resource via Azure Portal

Move a storage account or VM to a new resource group

Create Destination Resource Group In the Azure Portal, go to Resource groups → click + Create. Create a new group named AZ104-Destination-RG in the same region as AZ104-Governance-RG.

Select the Resource to Move Open AZ104-Governance-RG. In the resource list, check the checkbox next to the resource you want to move (e.g., a Storage Account).

Initiate the Move Click the Move button in the top toolbar. Select “Move to another resource group” from the dropdown. AZ104-Governance-RG › [Select Resource] › Move › Move to another resource group

Configure Move Destination In the Move Resources blade: • Subscription: Keep the same subscription
• Resource group: Select AZ104-Destination-RG
• Review the listed dependent resources — Azure will automatically include all required dependencies
Validate & Confirm Azure performs an automatic validation check. Wait for the validation to complete (this may take 1–3 minutes). Once validation passes, check the “I understand that tools and scripts associated with moved resources will not work until I update them to use new resource IDs” checkbox and click Move.
✅ Verify: After the move completes, navigate to AZ104-Destination-RG. The resource should appear there. Check its Resource ID in Properties — it will now show /resourceGroups/AZ104-Destination-RG/.

Part B — Move Resource Using PowerShell

Automate resource movement via PowerShell

PowerShell — Move Resourceps1

# Define variables
$sourceRG      = "AZ104-Governance-RG"
$destinationRG = "AZ104-Destination-RG"
$subscriptionId = "<your-subscription-id>"

# Get the resource you want to move
$resource = Get-AzResource `
  -ResourceGroupName $sourceRG `
  -ResourceName "myStorageAccount"

# Create destination resource group (if not exists)
New-AzResourceGroup `
  -Name $destinationRG `
  -Location "East US"

# Validate the move first (recommended)
Invoke-AzResourceAction `
  -Action "validateMoveResources" `
  -ResourceId "/subscriptions/$subscriptionId/resourceGroups/$sourceRG" `
  -Parameters @{
    resources           = @($resource.ResourceId)
    targetResourceGroup = "/subscriptions/$subscriptionId/resourceGroups/$destinationRG"
  }

# Perform the actual move
Move-AzResource `
  -ResourceId $resource.ResourceId `
  -DestinationResourceGroupName $destinationRG `
  -Force

Write-Host "✅ Resource moved successfully to $destinationRG"

Azure CLI — Move Resourcebash

# Get Resource ID of the resource to move
RESOURCE_ID=$(az resource show \
  --resource-group "AZ104-Governance-RG" \
  --name "myStorageAccount" \
  --resource-type "Microsoft.Storage/storageAccounts" \
  --query id --output tsv)

# Create destination resource group
az group create \
  --name "AZ104-Destination-RG" \
  --location "eastus"

# Move the resource
az resource move \
  --destination-group "AZ104-Destination-RG" \
  --ids $RESOURCE_ID

# Confirm the move
az resource list \
  --resource-group "AZ104-Destination-RG" \
  --output table

Essential Commands Cheat Sheet

Operation	Azure CLI	PowerShell
Create CanNotDelete Lock	`az lock create --lock-type CanNotDelete`	`New-AzResourceLock -LockLevel CanNotDelete`
Create ReadOnly Lock	`az lock create --lock-type ReadOnly`	`New-AzResourceLock -LockLevel ReadOnly`
List Locks	`az lock list -g <RG>`	`Get-AzResourceLock -ResourceGroupName <RG>`
Delete Lock	`az lock delete --name <name>`	`Remove-AzResourceLock -LockId <id>`
Move Resource	`az resource move --ids <id>`	`Move-AzResource -ResourceId <id>`

Best Practices & Key Takeaways

Always apply CanNotDelete locks to production resource groups like AZ104-Governance-RG to prevent accidental deletion by authorized users.
Use ReadOnly locks sparingly — they block write operations and can break running services. Reserve them for maintenance freeze periods only.
Locks cascade down the hierarchy. A lock on a subscription applies to all resource groups and resources within it — plan your lock placement accordingly.
Remove ReadOnly locks before moving resources. Resource movement is a write operation and will be blocked by ReadOnly locks on both source and destination.
Validate before moving. Always run the validation step before a resource move — Azure will identify dependencies you may have missed.
Update resource IDs after moving. ARM templates, Terraform state files, deployment scripts, and monitoring configurations must be updated after a move since resource IDs change.
Leverage Azure Policy in combination with locks to enforce governance at scale — Policy can automatically apply locks to newly created resource groups.
For cross-subscription moves, ensure both subscriptions are in the same Azure AD tenant and both have the necessary resource providers registered.