Azure Policy Explained: Governance Without the Guesswork

I’ve lost count of the number of Azure environments I’ve seen where governance was treated as something to worry about later.

Everything starts well enough. A few subscriptions, a handful of resource groups, and everyone promises they’ll follow the agreed standards. Six months later you’ve got storage accounts with no encryption settings reviewed, resources spread across regions nobody approved, and tags that look like they were generated by a random word generator.

The problem isn’t usually a lack of standards. Most organisations have standards written down somewhere. The problem is enforcing them consistently.

That’s where Azure Policy comes in.

Azure Policy allows you to define rules for your Azure environment and have Azure enforce them automatically. Whether you want to restrict deployments to specific regions, ensure resources are tagged correctly, or automatically remediate missing configurations, Azure Policy provides the governance layer that sits between your standards and your actual infrastructure.

In this article I’ll explain how Azure Policy works, how definitions, initiatives and assignments fit together, when to use built-in versus custom policies, and some lessons I’ve learned deploying policy at enterprise scale.

Where Azure Policy Fits in Governance

Azure Policy is part of Azure’s governance toolkit.

Whilst tools like Azure RBAC control who can do something, Azure Policy controls what can be deployed and how it must be configured.

Think of it like this:

Service	Purpose
Azure RBAC	Controls access
Azure Policy	Controls compliance
Management Groups	Organises governance scope
Azure Cost Management	Controls spend visibility
Microsoft Defender for Cloud	Identifies security issues

Azure Policy evaluates resources against defined rules.

These evaluations happen during deployment and continuously afterwards. That means Azure can stop non-compliant resources being created, flag existing resources that drift away from standards, or even fix certain issues automatically.

In most enterprise environments, Azure Policy becomes one of the core governance controls within a Landing Zone architecture.

Without it, you’re relying on people remembering standards.

That rarely scales particularly well.

Understanding Definitions, Initiatives and Assignments

The three concepts that confuse people most are policy definitions, initiatives and assignments.

Once you understand the relationship between them, everything else starts to make sense.

Policy Definitions

A policy definition contains the actual rule.

For example:

Storage accounts must have encryption enabled
Resources must contain specific tags
Deployments must use approved SKUs
Virtual machines must use managed disks

A definition describes what Azure should evaluate.

Initiatives

An initiative is simply a collection of policy definitions.

Rather than assigning twenty individual policies, you can group them into a single initiative.

For example:

Corporate Governance Initiative

Required resource tags
Approved deployment regions
Storage encryption requirements
Diagnostic settings requirements
Key Vault configuration standards

This makes governance significantly easier to manage at scale.

Assignments

An assignment applies a definition or initiative to a scope.

That scope can be:

Management Group
Subscription
Resource Group
Individual Resource

The hierarchy looks like this:

Policy Definition
        ↓
    Initiative
        ↓
    Assignment
        ↓
      Scope

In practice, most organisations assign initiatives at Management Group level and inherit them downwards.

That keeps governance consistent across subscriptions.

Built-in vs Custom Policies

Azure provides hundreds of built-in policies.

Before writing your own, check whether Microsoft has already done the work for you.

When Built-in Policies Make Sense

Built-in policies cover common governance requirements:

Encryption enforcement
Allowed regions
Approved VM SKUs
Network security requirements
Diagnostic settings

For most organisations, built-in policies should form the foundation of their governance model.

They’re maintained by Microsoft and updated as Azure evolves.

When You Need Custom Policies

Custom policies become useful when governance requirements are organisation-specific.

Examples include:

Custom tagging structures
Internal naming standards
Business-specific compliance controls
Proprietary configuration requirements

Here’s a simplified example of a custom tagging policy definition:

{
  "if": {
    "field": "tags['CostCentre']",
    "exists": "false"
  },
  "then": {
    "effect": "deny"
  }
}

Simple policies like this can save a surprising amount of administrative effort later.

Particularly when finance starts asking where all the cloud spend went.

Understanding Policy Effects

The policy effect determines what Azure does when a resource doesn’t comply.

Choosing the wrong effect is one of the quickest ways to upset platform users.

Audit

Audit records non-compliance but allows deployment.

This is usually where I recommend starting.

You get visibility without breaking anything.

Deny

Deny blocks deployment completely.

If a resource violates policy, Azure rejects the deployment.

Useful once you’ve proven compliance requirements won’t cause operational issues.

Modify

Modify updates resource properties during deployment.

A common example is automatically adding tags.

Instead of rejecting deployments, Azure fixes them.

DeployIfNotExists

DeployIfNotExists is one of the most powerful effects available.

If Azure detects a missing configuration, it automatically deploys the required resource.

Examples include:

Diagnostic settings
Monitoring agents
Security configurations
Backup settings

We’ll come back to this one shortly.

Disabled

Disabled turns the policy off without deleting it.

Useful for testing or temporary exemptions.

DeployIfNotExists: Powerful but Often Misunderstood

DeployIfNotExists sounds simple.

In reality, it’s where many policy rollouts become unexpectedly complicated.

When Azure identifies a non-compliant resource, the policy deploys additional resources or configurations to bring it into compliance.

For example:

Create diagnostic settings
Enable monitoring
Configure backup policies
Install extensions

Here’s the catch.

Existing resources are not automatically remediated just because you’ve assigned the policy.

You must run remediation tasks.

Additionally, the policy assignment requires a managed identity with sufficient permissions to perform the remediation.

I’ve seen organisations underestimate this effort repeatedly.

They assign a DeployIfNotExists policy expecting thousands of existing resources to magically fix themselves overnight.

Instead they discover permissions issues, remediation failures and resource-specific exceptions.

The policy itself is often the easy part.

Cleaning up years of inconsistent deployments is where the real work starts.

Real-World Governance Examples

Let’s look at a few practical scenarios.

Enforcing Resource Tags

Tags are one of the simplest governance controls and one of the most commonly ignored.

A policy can require tags such as:

Environment
Application
CostCentre
Owner

This improves reporting, chargeback and operational ownership.

Restricting Azure Regions

Many organisations only allow deployments in approved regions.

For example:

UK South
UK West
North Europe
West Europe

A policy can block resources from being deployed elsewhere.

This helps with compliance, data residency and operational support.

Requiring Storage Encryption

Storage encryption should not be optional.

A policy can audit or deny storage accounts that don’t meet encryption requirements.

This is particularly useful in environments subject to regulatory controls.

Managing Azure Policy with Terraform

If you’re already using Infrastructure as Code, managing policy manually through the portal makes very little sense.

Terraform provides resources for:

Policy definitions
Initiatives
Assignments
Exemptions

A simple policy assignment looks like this:

resource "azurerm_management_group_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations"
  policy_definition_id = data.azurerm_policy_definition.allowed_locations.id
  management_group_id  = data.azurerm_management_group.platform.id

  parameters = jsonencode({
    listOfAllowedLocations = {
      value = ["uksouth", "ukwest"]
    }
  })
}

Managing policy as code gives you:

Source control
Peer review
Change history
Repeatable deployments

More importantly, it prevents someone making governance changes at 4pm on a Friday directly in the portal.

History suggests that’s rarely a good idea.

Azure Policy, Landing Zones and Azure Blueprints

Microsoft has largely shifted focus from Azure Blueprints towards Landing Zone architectures.

Azure Policy remains a key component of those Landing Zones.

In a typical enterprise Landing Zone:

Management Groups provide hierarchy
RBAC controls access
Azure Policy enforces standards
Terraform deploys everything consistently

Policies are often assigned at the platform Management Group level and inherited throughout the environment.

This ensures governance remains consistent regardless of how many subscriptions get created later.

If you’re implementing Azure Landing Zones, Azure Policy isn’t an optional extra.

It’s one of the foundational controls that makes the whole model work.

Common Mistakes

The most common Azure Policy mistakes are surprisingly consistent.

Starting with Deny policies immediately

Begin with Audit mode. Understand the impact before you start blocking deployments.

Ignoring existing resources

Policies don’t magically fix historical issues. Plan remediation work before rollout.

Creating custom policies unnecessarily

Always check built-in policies first. Microsoft already covers many common requirements.

Assigning policies too low in the hierarchy

Governance becomes difficult to maintain when assignments are scattered across subscriptions and resource groups.

Forgetting managed identity permissions

DeployIfNotExists and Modify policies often fail because the assignment identity lacks the required roles.

Summary

Azure Policy is one of the most important governance services in Azure because it turns standards into enforceable controls.

The key concepts are straightforward: policy definitions contain rules, initiatives group those rules together, and assignments apply them to a scope. Once you understand that relationship, the rest of the service becomes much easier to work with.

For most organisations, built-in policies provide a strong starting point. DeployIfNotExists can automate compliance significantly, but don’t underestimate the remediation effort required for existing resources.

Most importantly, treat policy as code. Managing governance through Terraform gives you consistency, visibility and a deployment process that scales far better than clicking around the Azure portal.

What to Explore Next

Azure Landing Zones and enterprise-scale architecture
Terraform management of Azure governance controls
Azure Management Groups and subscription hierarchy design
Microsoft Learn documentation for Azure Policy and policy initiatives
Azure Policy exemptions and governance exception management