Start here! Get your feet wet with the Microsoft cloud and begin your journey to earning your Microsoft Certified: Azure Fundamentals certification!
Resource locks are a security feature in Azure that protect critical components from accidental or intentional changes. They work alongside Azure role-based access control (Azure RBAC) to add an extra layer of protection. When you apply a lock, it prevents deletion or modification of resources, resource groups, or entire subscriptions without first removing the lock.
You can apply locks using three main methods. Through the Azure portal, navigate to the resource, select Locks under Settings, click Add, then choose a lock type and name. Using Azure PowerShell, run New-AzResourceLock with parameters like -LockLevel CanNotDelete, -LockName, and resource identifiers. With Azure CLI, execute az lock create --name --lock-type along with resource details.
Locks follow an inheritance model where applying a lock at a higher scope automatically protects all nested resources. If you lock a resource group, every resource inside that group shares the same protection. You can apply locks at the subscription, resource group, or individual resource level, and locks at higher levels flow down to child resources.
Azure offers two types of resource locks, each providing different levels of protection. The CanNotDelete lock allows users to read and update a resource's configuration but prevents deletion. The ReadOnly lock restricts users to only reading the resource; they cannot modify or delete it.
Choosing between these lock types depends on your operational needs. Use CanNotDelete when you need to guard against accidental deletion but still require the ability to make configuration changes. Choose ReadOnly when you want complete protection, ensuring no changes or deletions can occur.
A few important limitations exist that you should understand. Locking a storage account does not protect individual containers or blobs inside it from deletion or overwriting. A ReadOnly lock blocks all HTTP POST operations, including listing storage account keys, which means you may need to plan for alternative authentication using Microsoft Entra credentials.
Resource locks change how common operations behave in Azure. With a CanNotDelete lock, you can still update or redeploy resources, but any deletion attempt will fail. With a ReadOnly lock, all write operations—including updates and deletions—are blocked entirely.
Locks override role permissions in Azure RBAC, meaning even users with Contributor rights cannot delete a locked resource without first removing the lock. This makes locks an effective last line of defense. When a ReadOnly lock is set, operations like List Keys (which use HTTPS POST) are blocked, cutting off new key-based access to storage. Existing clients with keys can still access data, but new users must have both the Azure Resource Manager Reader role and appropriate data roles.
For comprehensive security, combine resource locks with other Azure governance tools and data protection features. Review lock scopes regularly to ensure they meet your organization's compliance requirements.
Managing locks involves knowing how to view, modify, and remove them when necessary. In the Azure portal, navigate to your resource's Settings section and select Locks to add, view, or delete locks. Through PowerShell, use New-AzResourceLock to create locks and Remove-AzResourceLock to remove them. With Azure CLI, use az lock create and az lock delete respectively.
To modify an existing lock, you typically remove the current lock and then reapply it with updated settings. Give each lock a meaningful name and add notes explaining why it exists—this helps your team understand the purpose and when the lock can be safely removed.
Best practices for managing locks include communicating lock intentions through documentation and team channels, reviewing locks regularly to ensure they still align with operational needs, and applying locks at the appropriate scope to avoid blocking necessary work.
Resource locks serve several important purposes in Azure environments. They protect critical infrastructure such as storage accounts and data clusters from unintended changes. They help ensure compliance with organizational policies by preventing unapproved alterations. They also prevent accidental deletions during maintenance or large-scale updates.
When you lock a storage account using CanNotDelete or ReadOnly, Azure blocks deletion or configuration changes while still allowing necessary read operations. Similarly, applying a lock to an Azure Data Explorer cluster ensures that data and services remain intact even if a user has high-level permissions.
It is important to note that while locks protect the resource itself, data within storage containers or blobs may still require additional safeguards for complete protection. By integrating resource locks into their governance model, teams can focus on innovation rather than firefighting accidental outages, creating a robust environment where critical services remain secure and compliant.
Gauge your current knowledge

Gauge your current knowledge
