Azure provides powerful tools to help manage and secure cloud resources, and Azure Resource Locks are among the most essential mechanisms for protecting critical workloads. By preventing accidental deletions or modifications, locks can safeguard production environments, enforce governance, and maintain infrastructure integrity.
However, improper use of resource locks can lead to unintended problems—such as breaking automation workflows, interfering with deployments, and creating administrative bottlenecks. In this article, we explore the best ways to implement locks while avoiding common pitfalls.
Understanding Azure Resource Locks
Azure Resource Locks come in two primary types:
Read-Only Lock (CanNotDelete + ReadOnly) – Prevents modifications while allowing read access.
Delete Lock (CanNotDelete) – Prevents deletion but allows modifications.
Where Can Locks Be Applied?
Resource locks can be placed at different levels within Azure:
Subscription Level – Affects all resources within a subscription.
Resource Group Level – Applies to all resources inside a specific resource group.
Individual Resource Level – Targets a specific resource, such as a virtual machine, storage account, or database.
Locks vs. RBAC (Role-Based Access Control)
While RBAC controls who can perform actions on a resource, locks provide an additional layer of protection by restricting what actions can be performed, even by administrators. This distinction makes locks a critical safeguard against unintended changes, even when RBAC permissions are configured correctly.
Real-World Use Cases
Protecting Production Workloads
In production environments, accidental deletions or modifications can cause outages. Applying Delete Locks to critical resources (e.g., production databases, networking components) prevents costly mistakes.
Ensuring Governance in Landing Zones
Organizations enforce Read-Only Locks on key infrastructure components, such as shared virtual networks or firewall rules, to prevent unauthorized modifications while still allowing teams to access necessary configurations.
Locking Shared Resources
Commonly shared resources (e.g., a centralized logging storage account or a primary Azure Key Vault) should be locked to prevent modifications that could impact multiple workloads.
The Dark Side of Resource Locks: Common Pitfalls
While resource locks are helpful, they can introduce several challenges:
Breaking Automation Pipelines
If a locked resource is part of an Infrastructure as Code (IaC) deployment (e.g., using Terraform or Bicep), the deployment might fail when attempting to modify or delete a locked resource.
Unintended Admin Overhead
Admins frequently need to remove and reapply locks, leading to delays and increased operational effort.
Conflicts with Azure Policies
In some cases, Azure Policies may enforce configurations that require modifying resources, but if a Read-Only Lock is in place, these policy assignments may fail.
Best Practices for Managing Locks Without Problems
Strategic Placement of Locks
Use Delete Locks on critical production resources to prevent accidental deletions.
Use Read-Only Locks only when absolutely necessary, as they can interfere with automation.
Apply locks at the resource group level instead of the resource level when protecting multiple resources.
Automating Lock Management with PowerShell & Azure CLI
Instead of manually adding and removing locks, use automation:
PowerShell Example
1
New-AzResourceLock -LockName "PreventDelete" -LockLevel CanNotDelete -ResourceGroupName "ProdRG"
Azure CLI Example
1
az lock create --name PreventDelete --lock-type CanNotDelete --resource-group ProdRG
Combining Locks with RBAC for Smarter Access Control
Instead of relying solely on locks, use RBAC policies to restrict actions while allowing DevOps teams necessary flexibility.
Advanced Lock Scenarios
Temporary Locking Strategies
For temporary changes, implement an automated time-based lock removal process using Azure Functions or Logic Apps.
Using Locks in Multi-Tenant Environments
Locks can be enforced at the subscription level to prevent accidental deletion of shared cross-tenant resources.
Locking Critical Resources While Maintaining DevOps Flexibility
Use custom automation scripts to dynamically remove locks during deployments and reapply them afterward.
Conclusion
Azure Resource Locks are a powerful tool for protecting critical resources but should be used strategically to avoid interfering with automation and operational workflows. By following best practices—such as applying locks at the right level, automating lock management, and combining locks with RBAC—you can enhance security while maintaining efficiency.
Implementing locks correctly ensures a balance between security, governance, and operational agility, helping organizations manage Azure environments safely and effectively.
I hope this was useful. Keep clouding around.
Vukasin Terzic