Azure Policy – How Precedence Works

Azure Policy is an awesome service for several things in Azure like…

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy meets this need by evaluating your resources for non-compliance with assigned policies. All data stored by Azure Policy is encrypted at rest.

For example, you can have a policy to allow only a certain SKU size of virtual machines in your environment. Once this policy is implemented, new and existing resources are evaluated for compliance. With the right type of policy, existing resources can be brought into compliance. Later in this documentation, we’ll go over more details on how to create and implement policies with Azure Policy. [Microsoft]

As I used to do lot’s of on-prem Active Directory stuff in the past, Azure Policy reminds me of the GPOs (Group Policy Objects) in Active Directory and therefore similiar questions / principals come up to my mind when implementing a more complex structure. One common question was back in those days, which policy has precedence over another and what setting will finally applied to the object if there are multiple GPOs in different hierarchical orders impacting the user or computer. The same challenge is popping up in Azure. Let’s assume we have a management group, subscription and a resource groups where we can apply Azure policies. So said the management group is the parent which has a subscription as a child and a resource group is deployed to that subscription. It looks like this…

Then we are going to apply conflicting policies to each of the structural components. Which setting or policy will win in the end? Exactly this is the purpose of this blog post.

To get immediate result when trying to deploy a resource, I have chosen two different, conflicting policies.

•  Allowed resource types: Defines the resource types that you can deploy. Its effect is to deny all resources that aren’t part of this defined list.
•  Not allowed resource types: Prevents a list of resource types from being deployed.

In the “Allowed resource types” policy I configured to allow storage account, key vault and public IP resources. The “Not allowed resource types” policy is configured to deny storage account and key vault creation. Then I deployed (not assigned yet) the policies to Management Group M…

Test 1 (Management Group & Subscription)

Next, I assigned the “Not allowed resource types” to the management group and the “Allowed resource types” policy to the subscription…

 Result: The result was that deploying storage account and key vault was denied and I could only deploy a public IP address.

Test 2 (Management Group & Subscription)

The second test I used the same policies but switched the assignment. I assigned the “Allowed resource types” policy to the management group and the “Not allowed resource types” policy to the subscription…

Result: The result was, that I was only allowed to deploy the public IP address. Storage account and key vault creation were denied.

Test 3 (Management Group & Subscription & Resource Group)

In Test 3 I used the same setup as in Test 2 but I additionally I assigned the “Allowed resource types” policy to the resource group.

Result: The result was the same as in Test 2, I was only allowed to deploy the public IP address. Storage account and key vault were denied.

Test 4 (Management Group & Subscription & Resource Group)

Test 4 is the same setup as Test 3 but I assigned an additional policy to the resource group which denies the creation of public IP addresses…

Result: The test result was that I was not able to deploy storage account, key vault nor public IP address.

Conclusion: Test 1 and Test 2 show that the order of the policy does not matter, the more restrictive policy wins. Test 3 shows, that not the last policy wins, instead the more restrictive. Test 4 shows, that the policies are cumulative in its restrictive effect.

If you apply a policy it gets inherited to the child elements like management group, subscription and resource group. If there is a more restrictive policy it will always win independently of the level it has been applied. Meaning, it does not matter if the policy is applied on management group or resource group level. If policies are not conflicting, they will be complementary, which means they will sum up in its effect.

I hope this helps implementing a successful Azure Policy strategy!