Hi, I’m Makoto, a freelance engineer.
One of the benefits of the cloud is that you can easily create resources and delete them when you don’t need them anymore. However, sometimes we accidentally delete resources in unintended ways.
One reason is that you don’t use it as carefully in your personal environment, but here’s a common example:
- Deleting an entire resource group that accidentally included resources you wanted to keep
- Accidentally deleting the wrong virtual machine due to similar names
Ideally, we should work with a user who doesn’t have delete permissions, but there are cases where we want to use an admin user, such as for personal learning.
In this article, I’ll introduce the “lock” feature that prevents Azure resources from being deleted. It’s very easy to set up, but there are also important considerations you need to know, so please read to the end.
Let’s get started!
Types of Resource Locks
Locks are a feature that prevents accidental deletion of created resources. There are two types:
| Lock Type | Modify | Delete |
|---|---|---|
| Read-only | × | × |
| Delete | 〇 | × |
Read-only locks prevent both modification and deletion. The resource becomes ReadOnly state.
Delete locks allow modification but prevent deletion. The resource becomes CanNotDelete state.
Both types of locks still allow you to view the locked resources.
Although it’s not very common, you can apply both types of locks to a single resource. In this case, the more stringent read-only lock takes precedence.
To delete a locked resource, you must first remove the lock and then delete the resource. Even administrators cannot delete a resource without first removing the lock.
Key Points:
To delete a locked resource, you must first remove the lock.
Scope of Lock Application
Locks can be applied to subscriptions, resource groups, and individual resources. They cannot be applied to management groups.
For more details on the Azure resource hierarchy structure, see this article.
When you apply a lock to a parent scope, all resources within that scope inherit the same lock. In this case, the more stringent read-only lock takes precedence.
Let me show you examples using the Azure Portal screens.
In the Subscription, Resource Group, and Resource menus, you can find the Locks menu, where you can add, edit, or delete locks.
This screen example shows adding a “Read-only Lock” to a resource group. The registered lock appears in the list and can be edited or deleted later.
Next, if we check the locks on a virtual machine within the resource group, we can see that the lock set on the resource group is inherited, and editing or deleting it is not allowed.
I have added a delete lock to the virtual machine. In this case, the more stringent read-only lock takes precedence.
When we try to resize the virtual machine, we get an error saying “Please remove the lock and try again”. By the way, you can’t stop, restart, or start the virtual machine in a read-only state. (These actions are possible with a delete lock).
Key Points:
You can set locks on subscriptions, resource groups, and resources. Locks on parent scopes are inherited.
Things to Know About Resource Locks
As mentioned in the “Considerations before applying your locks” section of the official documentation, applying locks can lead to unexpected results. Here are some important points to consider.
We’ve seen an example where you can’t stop/start a virtual machine, but be especially careful with read-only locks because they prevent any modification operations.
Auto-Scale Stops Working
If you set a read-only lock on a virtual machine scale set or App Service, you will not be able to create or delete new instances, and as a result, auto-scaling will not work.
Data Stored in Azure Resources Is Not Locked
Locking a storage account or SQL Database does not protect the data stored in it.
For example, even if you apply a delete lock to a storage account, you can still delete blobs within it.
Data protection should be handled using service features like versioning or backups.
Azure Advisor May Not Function Properly
If you set a read-only lock on a subscription, Azure Advisor will not work correctly.
However, all resources under the subscription will become unchangeable, and you will not be able to create new resources, so I don’t think you will make a mistake.
Azure May Automatically Apply Locks
This is more of a “good to know” point than a consideration, but some resources may be automatically locked by Azure.
For example, when you purchase a domain using the App Service Domains service in Azure, a “DNS zone” is automatically created because the domain is managed by Azure DNS.
To manage these domains, it is important not to accidentally delete the App Service Domains and DNS Zone, so Azure will automatically register a delete lock.
Summary
In this article, we introduced the lock feature that prevents Azure resources from being deleted and showed examples using Azure Portal screens.
| Lock Type | Modify | Delete |
|---|---|---|
| Read-only | × | × |
| Delete | 〇 | × |
The key points likely to be tested on the AZ-900 exam are:
- The difference between a read-only lock and a delete lock
- Whether locks are inherited
- How to delete a locked resource
Also, while probably not tested on the exam, make sure you understand the important considerations when using locks in practice.
See you next time!
