Azure Management Policy Processing Priority and Hierarchy

An interesting question came up this week at the inaugural Microsoft DFW Tech meetup in Dallas: What is the processing priority for Azure management policies?

The short answer: All applicable Azure policies are processed together, with the most pessimistic rule winning any conflicts.

That is, every Azure management policy that can apply to a given action is applied. And if two or more of those policies are in conflict, the most restrictive policy applies.

Let’s run through some examples.

Parent Policy and Child Policy, No Conflicts

We’ll begin with an example of a policy applied at the subscription level which restricts deployments to East US, North Central US or South Central US. That will be paired with a resource group policy that restricts deployments to North Central US or South Central US.

There is a management policy at the subscription scope which allows deployments to East US, North Central US and South Central US; and a policy at the resource group which allows deployments to North Central US and South Central US.

Now let’s try to deploy a new Free tier App Service Plan to South Central US.

Policies are always inherited and resources are always deployed to a resource group. Thus, both the subscription rule and the resource group rule apply to this deployment.

A free App Service Plan and one Web App are successfully deployed to South Central US under these rules.

The subscription policy allows deployments to South Central US. So does the resource group policy. Thus, I am able to deploy the App Service Plan.

Parent Policy and Child Policy, More Restrictive Child

For the next example, let’s try to deploy that same Free tier App Service Plan to East US.

Again, both the subscription policy and resource group policy apply.

As predicted, the deployment of both the App Service Plan and the Web App fail, because both are restricted by the resource group’s policy preventing East US deployments.

The subscription policy allows deployments to East US. The resource group policy does not. Therefore, our deployment fails, because the resource group policy forbids deployments to East US.

Parent Policy and Child Policy, More Restrictive Parent

That deployment would also fail if I switched the scope of the policies.

That is, let’s suppose I change it so that the subscription allows deployments to North Central US and South Central US, and the resource group allows deployments to East US, North Central US and South Central US.

Switching scopes: Now the subscription allows deployments to North Central US and South Central US, while the resource group allows deployments to East US, North Central US and South Central US.

Now my deployment fails because the subscription policy bans East US deployments.

The deployment to East US fails because the subscription has a policy which disallows East US deployments.

It’s not inheritance that matters; it’s permission. All policies that can apply to an action are applied, and in the case of conflicts, the most restrictive policy wins, regardless of its scope.

Multiple Policies, No Conflicts

If several policies apply to a given action, and none of them cause a conflict, then all those policies will be applied to the action.

For example, I may have three different default tagging policies: One that creates a default cost center tag, another that creates a default environment tag, and a third that sets a default customer ID tag.

These three default tagging policies will all execute, because they are not in conflict.

In that case, all three tags will be applied. We can run several versions of the same policy in a given deployment. Since none of the stated policies prevent the other policies from being enforced, all three policies are successfully applied.

Post deployment, you can see this Web App has been tagged with the three tags dictated by our three tagging policies. All three policies are applied because none are in conflict.

Multiple Policies, Each Policy Satisfies Another

Finally, I can have policies that satisfy other policies, and they will all be enforced successfully.

For example, I can have a policy that applies a default tag named “costCenter” with the value “abc123”. I can also have a policy that requires a tag named “costCenter” with a value of “abc123”.

These two policies are circular: One applies a tag named costCenter with a value of abc123, and the other requires the presence of a tag named costCenter with a value of abc123.

When I execute a deployment, both those policies will be applied. Because I have a policy that sets the correct default value for the cost center tag, the policy that requires the cost center tag to be “abc123” is also satisfied, and thus the deployment succeeds.

In this Storage account deployment, the policy that created a costCenter tag with a default value was applied. That satisfied the other policy, which required a tag called costCenter with the appropriate default value.

Recap

So, to recap how Azure Policy applies policies to a deployment or action:

  • All management policies that are in scope (i.e., can be applied) are applied to every deployment or action.
  • If none of the applicable policies are in conflict, then all take effect.
  • If two or more policies are in conflict, the most restrictive policy is applied.
  • Policies are inherited, but policy scope does not affect policy application. A more restrictive parent policy is applied over a more permissive child policy, and a more restrictive child policy takes precedence over a less restrictive parent policy.
  • I can use one policy to satisfy the terms of another. It doesn’t matter what order I create those policies in or their scope; so long as one policy satisfies another, both will be applied.
Feature photo by geralt via Pixabay, in the public domain.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!