How Can Azure Resource Locks Prevent Accidental Infrastructure Changes?

Azure Resource Locks provide an additional control layer that helps protect important Azure resources from accidental deletion or modification through management operations. They are particularly useful for resources that are critical to production workloads. The two commonly discussed lock types are: Lock Type Effect CanNotDelete Prevents deletion while allowing other permitted management operations ReadOnly Prevents changes to the locked resource through management operations, subject to Azure's documented behaviour and exceptions A simplified production structure could look like: Production Subscription | +---- Resource Group | +---- Application +---- Database +---- Storage +---- Key Services | +---- Resource Lock The important point is that resource locks are not a replacement for Azure RBAC. RBAC determines what an identity is authorised to do, while a resource lock provides an additional protection mechanism against certain management operations. For example, an administrator may have sufficient permissions to delete a production resource, but a CanNotDelete lock can prevent the deletion operation. This creates an additional safety barrier. However, resource locks should be designed carefully. A ReadOnly lock can interfere with legitimate management operations, automation and configuration changes. Some operations may also involve dependent resources or operations that behave differently under locks. Therefore, teams should understand the documented behaviour of the specific Azure resource before applying a lock. For enterprise environments, combine resource locks with RBAC, Azure Policy, management groups, change management, deployment pipelines and monitoring. A strong cloud engineer should think of resource locks as one layer within a broader governance strategy—not as the complete security model.