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.
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.
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.
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.
Now my deployment fails because the subscription policy bans 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.
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.
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”.
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.
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.
