MonthJuly 2019

Azure Resource Locks – The What & Why

Today I want to give you all an overview of Azure Resource Locks. Firstly about what they are and can do, then secondly how you can use them and some best practices around them. And finally a few things to watch out for so you don’t get caught out when using them; believe me it’s easily done!

What are Azure Resource Locks?

Resource Locking within Azure provides a method to lock subscriptions, resource groups or individual resources to protect them from accidental deletion and changes; even for administrators (depending on their RBAC role).

Resource Locks come in 2 levels; CanNotDelete (displayed as ‘Delete’ in the portal) or ReadOnly (displayed as ‘Read-only’ in the portal).

As the names suggest, CanNotDelete means the resources with the lock applied can be read and modified, but they cannot be deleted. The ReadOnly lock means that the resources with the lock applied can only be read but not modified or deleted.

Both types of lock can actually cause some resources to stop functioning as you’d expect so be aware. More on this later!

Resource locks can also only be created by users assigned the ‘Owner’ or ‘User Access Administrator’ RBAC roles. More specifically any users with roles that grant the following RBAC permissions: ‘Microsoft.Authorization/*’ or ‘Microsoft.Authorization/locks/*’. So you don’t need to worry about anyone with write permissions on Resource Groups or VMs etc… creating locks on everything and potentially breaking other services without knowing about it etc…

How should I use Azure Resource Locks?

Now you may think that once deployed putting ReadOnly locks on everything is probably the best thing to go and do. And in some select scenarios I may even agree with you, however this is not best practice; so only do this if you absolutely have too!

Resource Locks can be applied at the following Azure governance scoping levels:

  • Subscription
  • Resource Group
  • Resource

In my opinion, applying locks at the Subscription level is way to high in the governance hierarchy structure and makes using Azure clunky; as everything you deploy within that subscription will inherit the lock from the subscription level.

Taking it to the other end of the governance hierarchy at placing locks at the Resource level can again be very tedious and difficult to manage and keep on top of. However in some cases it can actually be very useful.

Think of a scenario where you have applied a CanNotDelete lock at the resource group level but on the VPN gateway you have deployed within the resource group you want to restrict anyone from changing anything about its configuration. Applying a ReadOnly lock on the VPN gateway resource as well will mean that the rest of the resource group’s resources can be modified as they need to be but the VPN gateway is completely locked and cannot be modified at all without the lock being removed first. Removing the lock itself requires specific permissions, as explained in the above section, so this become a very handy way of locking things down further.

It should also be stated that if 2 locks, 1 in CanNotDelete mode & 1 in ReadOnly mode, the most restrictive lock (ReadOnly) takes precedence.

So the only scope we haven’t mentioned yet is the Resource Group level. This is where I suggest the majority of your locks are applied. However this does rely on you having split resources in some fashion between multiple resource groups. Whether that’s by application, business unit or service; as long as they are split and not all in a single resource group this approach will work nicely!

Applying locks at the Resource Group level is also the advised best practice from Microsoft under the Enterprise Scaffold framework (no part of the Cloud Adoption Framework). And as explained in the above scenario its give you the best flexibility for control without the locks becoming a restricting factor in using Azure on a daily basis.

When governance controls become a blocker for using and consuming Azure you’ll find people will try as many ways as possible to avoid following the controls you have put in place. So my advice is to use them as guard rails and not super secure enforcement rules to stop this from happening.

How do I create and apply Azure Resource Locks?

This is actually quite easy and I find doing it via the Azure Portal is the best way as you can check what resources will be impacted very easily & quickly due to the visual nature of the portal. However locks can be applied via PowerShell, AZ CLI, ARM Templates & Terraform etc…

In the below example I will place a ReadOnly lock on my test resource group which contains a single storage account.

  1. Log into the portal and select the Resource Group you wish to apply a lock to
  2. Select the ‘Locks’ blade from the navigation bar on the right
  3. Click ‘Add’
  4. Fill out the details as required and select the ‘Lock Type’ then click ‘OK’
  5. The lock will now be applied – Note the ‘Scope’ is shown in the lock overview blade as well as ‘Notes’. Make sure you use notes as it helps the next person when they come across your locks.
  6. That is it. You can follow the same instructions and a Subscription or Resource level and the steps are the same.

If we now lock at the Storage Account in this resource group we will see it has inherited the lock.

If I now try to amend the storage account you will see that even though I’m an owner on the Subscription the lock still applies to me and I must manually remove it in order to amend the storage account or delete it.

Things to watch out for with Azure Resource Locks

As mentioned at the beginning of this blog post, using resource locks can actually break some functionality with resources.

The ones I know of to date are as follows:

  1.  Listing Storage Account Access Keys This happens whether using the Portal, PowerShell, AZ CLI etc… as they all utilise the Azure Resource Manager (ARM).
  2. Azure Backup of VM’s Managed Disks(Thanks to Adin Ernie for the screenshot of this as I didn’t have one to hand at time of writing.)
    This occurs because the ‘RestorePointCollection’ object is treated as a separate Resource object by ARM. So you cannot place any locks on Resource Groups that contain these objects. The resource group name will look like this: AzureBackupRG_ukwest_1 However the region name will change depending on where you are deploying resources and backing up etc….


Hopefully this article has given you an in depth overview of Azure Resource Locks and how they can be and should be used.

Further reading can be found on the Microsoft Docs pages as always.

Like, Share, Follow!

Volunteering @ CDW Stemettes Hackathon July 2019

Earlier this month I volunteered at an amazing event ran by CDW, who I work for, and the Stemettes.

The first CDW Stemettes Hackathon!

CDW UK hosted the event at our Head Office in central London on the 6th & 7th of July 2019.

The event was attended by around 50+ girls from the ages of 5-21 years old on both the Saturday & Sunday.

All the girls who attended were set the challenge to design, build & test their own well-being themed mobile/web applications using different tools dependent on their skills/experience with coding.

The tools they used included: AppShed, AppInventor & Glitch.

Why did I choose to volunteer?

This was a no-brainer for me really if I’m honest! One of the things I love about the world of IT at the moment is the realisation  that one day everything will interact with technology in some way, shape or form. So if I can play a part in helping the next generations of IT industry workers, then I’m there and this event ticks that box perfectly.

I also get a real life-affirming uplifting kick out of helping anyone at all helping to understand a technical challenge they are facing. Especially when I can help them overcome the issue and enhance their technical skills & knowledge!

As well as this, my wife, Kate, is a secondary school teacher here in the UK and is a strong advocate of STEM & even more so of the Stemettes. The school she teaches at have a dedicated STEM/Stemettes coordinator as well so she is always coming home talking about the great events they are taking part in.

So when it came to asking if I could spend a weekend away at “work”, which as we all know in the world of IT can be quite a common request of our partners, volunteering at this awesome Stemettes event. Kate didn’t even hesitate to say yes before even checking if we had any existing plans with friends etc…

What did I actually do whilst volunteering?

Until the weekend arrived I only had very little information around the low level technical things we would be helping with.

Before all of the girls arrived on the Saturday morning, myself and the rest of the volunteers, were all briefed by the Stemettes team on the running of the day and what they needed from us.

The girls would be able to work in 1 of 3 groups over the weekend. Each of these groups would use a different tool to create their mobile/web app.

The 3 groups were (all named after inspirational women):

  • Bouman – used AppShed to create their apps –  for those who were new to coding and IT in general – very much design and look over functionality and code syntax
  • Sharman – used MIT AppInventor to create their apps – for those who had some coding and IT experience – a good balance between design and functionality – pre-packaged logic blocks to make things happen within the apps.
  • Johnson – used Glitch & Ratchet to create their apps – for those comfortable with code and IT – raw HTML & CSS in use in this group – This is the group I helped out in!

As you can see above the group I helped in, Johnson, used Glitch & Ratchet. Glitch is effectively an IDE that is very user friendly for those who aren’t full time web developers. It handily has a built in web server that previews your code live as you make changes, which is great for new web developers and even more so for the girls attending.

Ratchet on the other hand is front-end framework to build mobile apps with HTML, CSS & JavaScript. This was the first time I had come across this framework, but I’ve got to say it was very good at making things look very good with very minimal effort. This made the girls apps really come to life as quick as possible, which was great to see as it got them hooked on making them better and better once they learnt how important HTML syntax is.

The combination of Glitch & Ratchet was a great choice by the Stemettes team, although as always we had a few random bugs that occurred that got all of us volunteers scratching our heads; we got there eventually each time though!

The most complex request I had was to help a group get a live webcam stream embedded onto one of their web pages as part of their app. Now I’m no web developer, it’s certainly more of a hobby for me, but I couldn’t let the girls down; so I got it working with 15 minutes to spare before they had to submit their app for judging.


I absolutely loved helping out over the course of the weekend that this event ran. Seeing the girls getting to grips with Ratchet, HTML, CSS & development methodologies over the duration of the event was fascinating to see. The speed at which they all picked up effectively new languages to them all was mind blowing!

Everyone who attended received development themed prize bags from CDW, a great touch; I certainly would have been thrilled to receive some of the goodies that were in the bags. The portable logitech speaker was amazing and who doesn’t love a Rubix’s cube?


I look forward to volunteering on a lot more of these events in the future and already helping CDW plan what we can do in the future to inspire the next generations to get into IT.

All of the volunteers from CDW!

Like, Share, Follow!

© 2019 Jack Tracey

Theme by Anders NorénUp ↑