Azure Resource Locks

Azure resource locks will at some point save your bacon, it will trust me.
If you want to stop people being able to delete a development resource when they think it’s no longer being used, or more importantly on production resources so that they cannot be deleted (until the lock is deleted), then Azure locks are your friend

Azure Resource Locks are often over looked, most people know about them but never implement them, its always a good idea to use them, so what are you waiting for?

They can be applied at different levels ranging from the Resource Group (think of a folder where your Azure resources reside), down the individual resources themselves.

If there are a few people in your organisation that have one of the roles where they have access privileges to delete resources then Azure resource locks might be something to look into further.

To add a Resource Lock to any resource, simply locate the resource and then click on Locks as per below

As you can see, there are 2 different types of resource locks: –

• Read-Only – 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.
• Delete – means authorized users can still read and modify a resource, but they can’t delete the resource.

So how do locks actually work?

When you apply a lock at a parent scope, all resources within that scope inherit the same lock. Even resources you add later inherit the lock from the parent. The most restrictive lock in the inheritance takes precedence.
Unlike role-based access control, you use management locks to apply a restriction across all users and roles.

You can read up more on Azure Locks from the documentation. Go add locks to your production resources just in case, better to be safe than sorry.