Lesson 04 — Azure Policy: Governance at Scale

What Azure Policy Is — and What It Is Not

Azure Policy enforces resource configurations. RBAC controls who can perform actions. These are orthogonal systems that must both be satisfied for an operation to succeed — but they operate independently, and conflating them is a source of real architectural mistakes.

Policy Definitions: Structure

A policy definition is a JSON document that specifies a condition (if) and an effect (then). When a resource matches the if condition, the effect is applied.

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
        { "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
          "notEquals": true }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  },
  "parameters": {
    "allowedEffect": {
      "type": "String",
      "defaultValue": "Deny",
      "allowedValues": ["Audit", "Deny", "Disabled"]
    }
  }
}

The mode field

Policy Effects — Memorise All Seven

The effect determines what Azure does when a resource matches the policy's if condition. This is the most heavily tested aspect of Azure Policy. Know all effects, their purpose, and their sequencing.

Policy Evaluation Logic

Understanding when policies are evaluated is as important as understanding effects.

New and updated resources

When a resource is created or updated (via portal, CLI, ARM template, Terraform, or any other mechanism), Azure evaluates all applicable policies at the ARM layer before writing the resource. Deny effects fire here and return a 403 to the caller. This happens synchronously during the deployment.

Existing resources

Policies do not retroactively block existing non-compliant resources. Existing resources are evaluated during compliance scan cycles. These run:

• Automatically approximately every 24 hours on a schedule Azure controls
• On-demand via az policy state trigger-scan or the portal's "Trigger evaluation" button
• Immediately after a new policy assignment is made (on the resources within that scope)

Policy Initiatives (Policy Sets)

An initiative is a collection of policy definitions grouped together to achieve a common governance goal. Instead of assigning 50 individual policies, you assign one initiative. Compliance is reported at both the initiative level and the individual policy level within it.

Built-in initiatives for compliance frameworks

Policy Assignments

A policy assignment is the binding of a policy (or initiative) definition to a scope. The same definition can be assigned at multiple scopes with different parameters and different enforcement modes.

Assignment components

Policy Exclusions vs. Exemptions — A Critical Distinction

Both mechanisms allow resources to be excluded from a policy assignment, but they behave very differently:

Remediation Tasks

Policies with Modify or DeployIfNotExists effects can automatically fix non-compliant existing resources through remediation tasks. New resources are handled at deployment time; existing resources require an explicit remediation task.

How remediation works

1. A policy with DINE or Modify effect is assigned, or resources already exist that are non-compliant with such a policy.
2. The compliance scan identifies non-compliant resources.
3. An administrator triggers a Remediation Task from the Policy compliance blade (or it can be configured to auto-remediate on assignment).
4. Azure iterates through all non-compliant resources in scope and applies the effect — deploying the missing resource (DINE) or modifying the existing resource (Modify).
5. The remediation task runs using the managed identity attached to the policy assignment. If the managed identity lacks permissions, individual resources will fail to remediate and you'll see per-resource errors in the task log.

Compliance States

The Azure Policy compliance dashboard reports four possible states per resource per assignment:

Common Real-World Policies (Production Reference)

These are the policies you will encounter most frequently in real Azure environments. Know their names, effects, and how they are typically configured:

Azure Blueprints vs. Deployment Stacks

Azure Blueprints was Microsoft's original mechanism for packaging ARM templates, RBAC assignments, and Policy assignments together for repeatable environment deployment. Blueprints are deprecated — Microsoft stopped developing them and recommends migration to the replacement: Azure Deployment Stacks.

Hands-On: Assign and Evaluate a Policy

1. Assign the Azure Security Benchmark initiative: Navigate to Policy → Definitions. Filter by Category = Security Center. Find the Azure Security Benchmark initiative. Click Assign. Set scope to a development subscription. Set enforcement mode to DoNotEnforce (Disabled) — this evaluates for compliance without blocking anything. Submit the assignment.
2. Trigger a compliance scan: Go to Policy → Compliance. Find your initiative assignment. Click the "…" menu → Trigger evaluation. Wait 5–10 minutes for initial results to appear. Examine which policies show Non-compliant resources.
3. Create a custom Deny policy: Go to Policy → Definitions → + Policy definition. Set the scope to your subscription. Create a policy that denies storage account creation when supportsHttpsTrafficOnly is not true. Use the JSON example from earlier in this lesson. Assign it with enforcement mode Enabled.
4. Test the Deny policy: Attempt to create a storage account with Secure transfer required set to Disabled. The deployment should fail with a policy violation message. Examine the error — it will reference the policy definition name and assignment. Then create the same storage account with HTTPS enabled — it should succeed.
5. Create an exemption: For one non-compliant resource in the compliance dashboard, create an Exemption. Set category to Waiver, add a justification note, and set an expiry date 30 days in the future. Observe how the compliance state changes to Exempt and the exemption appears in the compliance report.