Mistakes are being made everywhere and every day. While being an administrator in Azure this could lead to serious issues! Think of removing a resource, resource group or modifying wrong fields, configurations or else.. This could probably happen to everyone or will happen someday.
Preventing accidental modifications or worse is very simple. Microsoft released Azure Locks in 2016 but is still not used very often, while implementing is very simple and will only costs you a little effort.
There are only two types of Azure Locks
- CanNotDelete means authorized users can still read and modify a resource, but they can’t delete the resource.
- ReadOnly means authorized users can read a resource, but they can’t delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role.
CanNotDelete prevents exactly what its called. If you configure Azure Locks on a resource group, it will prevent you from removing the resource group or one of the resources in this resource group.
Example 1: I’ve created a new resource group with a new storage account in it. I’ve configured “Delete Lock” on the resource group level. While trying to delete the storage account we see the following error.
If Azure Locks was not configured and this delete was a mistake, i could have a serious issue. In this case, Azure Locks saved my life 🙂
Example 2: In the previous example I’ve created a new resource group. We use this resource group again. This time I’ve created a DNS Zone (azurelockdemo.com) with a single A-record pointing to a random IP address. While saving after a modification we see the following error.
And again. If Azure Locks was not configured and this modification was a mistake, i could have a serious issue. In this case, Azure Locks saved my life 🙂
What to do when i need to modify or delete a resource?
Just remove the lock, apply the modifications and don’t forget to configure the lock again.