Azure Resource Locks: Stop Accidental Deletions (AZ-900)

Azure Resource Locks are management locks applied to resources or resource groups to prevent accidental deletion or modification. The two types are "CanNotDelete" (allows reading and modifying but prevents deletion) and "ReadOnly" (prevents any modifications or deletions). These locks are inherited by all child resources within a resource group.

What Exactly Are Azure Resource Locks?

Imagine this: you're cleaning up a development environment on a Friday afternoon, and in a moment of distraction, you delete the production Virtual Network (VNet) instead of the test one. In a real-world enterprise setting, this mistake could cost a company thousands of dollars per minute in downtime. This is exactly why Azure Resource Locks exist. They act as a safety net, preventing users—even those with high-level permissions—from accidentally deleting or modifying critical infrastructure.

For those of you studying for the AZ-900 exam, you need to understand that locks are not about security or access control (that's what RBAC is for). Instead, locks are about operational safety. They don't stop a user from seeing a resource, but they stop a 'fat-finger' mistake from becoming a catastrophic outage. When you apply a lock, Azure essentially puts a 'do not touch' sign on the resource that must be explicitly removed before any restricted action can be taken.

What is the Difference Between Read-Only and CanNotDelete Locks?

Azure provides two distinct types of locks, and the AZ-900 exam loves to test your ability to distinguish between them. The first is the 'CanNotDelete' lock. This is the most common lock used in production. It allows you to read the resource and update its settings—meaning you can still change the SKU of a VM or update a firewall rule—but it strictly prohibits the deletion of the resource. It's the perfect balance between flexibility and safety.

On the other hand, the 'ReadOnly' lock is much more restrictive. When you apply a ReadOnly lock, you cannot delete the resource AND you cannot make any changes to it. It effectively freezes the resource in its current state. Be careful here: a ReadOnly lock can often cause unexpected issues with other Azure services. For example, if you apply a ReadOnly lock to a Storage Account, you might find that you can't even upload blobs or change keys because those actions are technically 'write' operations. Always choose the least restrictive lock that meets your safety requirements.

How Does Lock Inheritance Work in Azure?

One of the most powerful features of Azure Resource Locks is inheritance. You don't have to manually apply a lock to every single disk, network interface, and IP address in your environment. Instead, you can apply a lock at the Resource Group level. Because of the Azure hierarchy, any lock applied to a Resource Group is automatically inherited by every single resource contained within that group.

This means if you lock your 'Production-RG' as 'CanNotDelete,' every resource inside it is now protected. However, it's important to note that if there is a conflict—say, a Resource Group has a 'CanNotDelete' lock but a specific resource inside it has a 'ReadOnly' lock—the most restrictive lock always wins. In this scenario, the resource would be treated as ReadOnly. Understanding this hierarchy is crucial for managing large-scale environments and is a frequent topic in the Azure Fundamentals curriculum.

Who Can Manage or Override Resource Locks?

A common misconception is that locks are an absolute barrier. In reality, locks are designed to prevent accidents, not to stop authorized administrators from doing their jobs. To create or delete a lock, a user must have the appropriate Role-Based Access Control (RBAC) permissions. Specifically, the user needs the `Microsoft.Authorization/*` or `Microsoft.Authorization/locks/*` permission.

In practical terms, this usually means users with the 'Owner' or 'User Access Administrator' roles are the ones managing locks. If an administrator needs to delete a locked resource, they must first perform a two-step process: first, they must manually remove the lock, and then they can proceed with the deletion. This intentional friction is what prevents the 'accidental' part of accidental deletion. It forces the admin to stop and think, 'Do I really want to delete this?' before they commit to the action.

What Are the Best Practices for Protecting Production Workloads?

To keep your environments stable, we recommend a tiered locking strategy. First, always apply 'CanNotDelete' locks to your production Resource Groups. This ensures that your core infrastructure remains intact while still allowing your team to perform necessary updates and patches. Reserve 'ReadOnly' locks for highly sensitive, static resources that should never change, such as a master configuration vault or a legacy archive.

Second, implement a 'Lock Audit' as part of your monthly operational review. Ensure that locks haven't been left off new resources and that old locks aren't hindering necessary maintenance. Third, always test your locks in a staging environment. As mentioned earlier, ReadOnly locks can break application functionality by blocking write operations. By testing first, you can identify exactly which lock type is appropriate for your specific workload without risking a production outage.

How Do Resource Locks Impact Your AZ-900 Exam Preparation?

Resource locks are a key component of the 'Azure Management and Governance' domain of the AZ-900 exam. You will likely see questions asking you to choose the correct lock type for a specific scenario or to identify how inheritance affects a resource. To truly master this, you need to move beyond reading documentation and start practicing with realistic exam questions that challenge your understanding of these nuances.

This is where we come in. At Cert Sensei, we provide 1,000 expert-curated Microsoft Azure Fundamentals (AZ-900) practice questions designed to mimic the actual exam experience. Instead of just giving you a right or wrong answer, we provide detailed expert reasoning for every single question, explaining the 'why' behind the answer. Combined with our domain-level analytics, you can pinpoint exactly where you're struggling—whether it's resource locks or virtual networking—and focus your study hours where they matter most.

❓ Frequently Asked Questions