Implementing resource locks

Often, there is a need to secure your deployed environment so that there is no possibility to easily change them or even remove them by a mistake. As you cannot just rely on given conventions or communication between teams, you have to implement some kind of policy that will make resources read-only. In Azure, the way to achieve that is to leverage resource locks. In this section, we'll learn how to implement resource locks and secure our workloads against accidental changes.

There are two levels of locks in Azure:

• Subscription locks: These are applied to all the resources inside a subscription.
• Resource group locks: These are applied to all the resources inside a resource group (and the resource group itself).

Also, you can choose between two different kinds of those locks:

• Read-only: A lock that prevents you and others from introducing changes to the resources
• Delete: A lock that prevents you and others from deleting resources (but allows you to change them)

In general, using locks on production resources in Azure should be one of your most important habits as an Azure administrator – it is one of the simplest features but gives you complete control over what is and what is not allowed when it comes to modifying environments.

To implement a lock, you have to answer the question of whether it is a subscription lock or if you only need it for a particular resource group. The choice solely depends on the characteristics of the resources:

• If you have a subscription per project, you may need to create a production subscription that holds all the production resources and apply the subscription lock.
• If you have a mix of read-only and delete locks, you will have to implement multiple resource group locks.
• If you cannot have a separate subscription for your production workloads, you may need a resource group lock.

Let's take a look at how to implement each of them.