Reading Time: 7 minutes

In this blog post I will explain how Azure Policy inheritance works using different scenarios/demos. If you are not aware of what Azure Policy is, click the following Microsoft Learn link to learn more, Overview of Azure Policy.

When we assign Azure Policies in our Azure environments we have the option to scope a policy at different levels including Management Groups, Subscriptions and Resource Groups as shown in the image below. The diagram below shows that we can apply Azure Policies at three levels, Management Groups, Subscriptions and Resource Groups.

Like RBAC (Role Based Access Control) permissions, policies also inherit from top down in the Azure Hierarchy. So if I scoped/assigned a policy at the Management Group level, that policy would inherit down to subscription, resource group and the three resources in my diagram, Virtual Machine 1 (VM1), Virtual Machine 2 (VM2) and Virtual Machine 3 (VM3). I have used virtual machines in my example, but this could be any type of Azure resource.

If I was to assign a policy at the Management Group scope allowing engineers in my organisation to deploy Virtual Machines to the Azure UK South region only, that policy would inherit down to the subscription and resource group. Therefore, my engineers would not be able to deploy Virtual Machines to any other region apart from the UK South region in the existing subscription and resources group, and any new subscriptions or resource groups deployed under my Management group in future as the policy would automatically apply.

Let’s go through a few commonly asked questions,

Question 1:
If you apply a policy to the Management group which only allows resources to be deployed in the UK South Region, and that policy is inherited by subscription and resource group, what would we expect to happen if I deployed a new Virtual Machine called VM4 to a different region such as as East US into the resource group?

Result
The deployment would be prevented by the policy and the engineer would not be allowed to deploy to the East US region because the policy scoped to the management group is being enforced. As shown in the image below. I have tried deploying VM4 to the East US region and been denied due to the policy applied at the Management Group level which has inherited all the way down, by design.

Question 2:
In the example above, you tried deploying to resource group named ResourceGroup1 and the policy denied you from trying to build a new VM4 in region East US. What if you create a new resource group name ResourceGroup2 and try deploying VM4 to East US or any other region inside the newly created resource group?

Result:
It will be denied, why? because the policy applied to the Management Group applies to all new resource groups under that Management Group. The new resource group ResourceGroup2 inherits the policy from above. Again, the below image shows the policy preventing VM4 from being deployed in East US in a new resource group named ResourceGroup2.

Question 3:
What about the resources (VM1, VM2 and VM3) which were deployed and already exist in Resource Group1 as shown in the diagram below. What would happen if VM1 was located in UK South and VM2 and VM3 were located outside of the UK South region, before you applied the policy? what would happen to existing resources that are already there?

Answer:
If the three resources, in my case three existing virtual machines VM2 and VM3 were deployed outside of the UK South region and VM1 was deployed in UK South region, then Azure Policy would display VM1 as compliant for being deployed in UK South, and the other two VM2 and VM3 as non-compliant. The Azure policy overview page would report this.

Question 4:
What would happen if you created another policy and assigned at the resource group level, but the new policy assigned to the resource group allowed deployment to East US region only, so denying UK South? You now have one policy applied to the Management Group which allows deployments to UK South region only (inherited down), and a new policy assigned to the resource group which only allows deployments to East US. Which one policy would win? as show in the image below.

Result
I leave the existing policy assigned to the management group, allowing resources to be deployed in UK South only. I have created a new policy and assigned to the resource group which only allows resources to be deployed to East US region. We now have conflicting policies.

The images below show that I have applied a policy to ResourceGroup1, allowing resources to be deployed inside that resource group but to East US region only.

What was the result?

1. Was I able to deploy a new virtual machine called VM4 in ResourceGroup1 in the UK South Region? No, denied as per the image below.

2. Was I able to deploy a new virtual machine called VM4 in ResourceGroup1 in the East US region? No, denied as per the image below.

Are you confused? 🙂

Are you thinking, I thought that adding a policy to ResourceGroup1 directly would override the Policy assigned to the Management Group level and allow me to build resources in East US region?

Or maybe you are thinking the opposite, that the policy assigned at the management group level would still take precedence/priority and allow a resource to be deployed to UK South but not East US.

Or maybe you’re thinking that it would be possible to build resources in ResourceGroup1 in both UK South and East US regions.

Or may be you knew what the result was going to be, in this case, I am not allowed to deploy to any of the regions.

Or you were thinking something else. In that case, please do drop a comment towards the end of this post to let us know.

Why was I not allowed to deploy to any of the regions
This is because both polices are applying together and a deny takes precedence/priority. In this case, both policies are denying. The policy at the management level denies/restricts deployments to East US as it only allows deployments to UK South. The policy at the resource group level denies/restricts deployments to UK South region as it only allows deployments to East US. The most restrictive/deny policy will take effect, in this case both of them are restricting/denying deployments, therefore both policies apply and deny access. As per the diagram below,

Question 5
What would happen if you apply two policies but the same configuration to both Management Group and resource group. So allow deployments to UK South only scoped to the Management Group and allow deployments to UK South region only at the resource group? as per the image below.

Result
You would be allowed to deploy to the UK South region as both policies are allowing at Management Group and Resource Group. In my case I removed the parameter of EAST US region at resource group level and added UK South. You may need to wait up to 30 minutes before new changes take effect.

The result, there was no error/warning when I selected UK South, as shown in the image below.

Question 6
Could you exclude policies from being applied to certain resources? For example, VM1, VM2, VM3 which already exist in a resource group, or if I want to apply a policy but I want to exclude certain resources from the policy. Is this possible?

Answer
Yes, you can exclude a subscription, resource group or specific resources so a Azure policy does not apply. There is an exclusions option.

There are also other options available such as exemptions and overrides. For more information on Azure Policy Exclusions, Exemptions , visit my post Differences between Azure Policy Exclusions, Exemptions and Overrides

Question 7
The built in ‘allowed locations’ policy you used is denying you to deploy resources in the regions not specified in the Policy. Is there a deny setting somewhere that you have to enable?

Answer:
The policy I used already is configured to deny, known as an effect. We can check this by accessing the JSON (Java Script Object Notation) code which is what the policy is using under the hood.

1. Go to Azure Policy
2. Click Assignments from the left pane under the section Authoring
3. Click the three dots … as shown in the image below

4. Click view definition (This will display the JSON code used under the hood, it is how the policy is compiled)
5. Scroll down to “effect”:

You can’t change the effect of a default/built in policy, the option to edit or delete built in policies/initiatives are greyed out. However, you can duplicate an existing definition, give it a new name and amend as required.

A list of effects and explanations which can be used in Azure policies are documented at the following Microsoft Learn page, Understand how effects work – Azure Policy

---

I hope you found the post useful.

See you at the next post.