DevOps Peach

Azure Basics · Governance – Regions, Subscriptions, Policy and RBAC · Lesson 3 of 5

Management Groups and Azure Policy

Azure Policy controls how resources are configured (region, SKU, tags); it is assigned at a management group, subscription or resource group and inherited downwards.

Practice interactively →

flowchart TB
  Root["Tenant root group"] --> MG["MG Production"]
  MG --> S1["Subscription sub-prod"]
  Root --> S2["Subscription sub-devops-lab"]
  S2 --> RG["rg-devops-lab"]
  RG --> R["Resources"]
  P["Policy Allowed locations"] -. "assigned at the RG, applies to every resource below" .-> RG

A management group is a scope above subscriptions: it groups subscriptions so policies, RBAC and budgets are assigned once; anything assigned higher up is inherited downwards.

Azure Policy evaluates resources against JSON rules and applies an effect: deny (block creation), audit (record non-compliance), modify/deployIfNotExists (change things, with remediation for existing resources). Built-in examples: Allowed locations, Allowed virtual machine size SKUs, Require a tag and its value, Azure Backup should be enabled for Virtual Machines.

Four steps

  1. Policy definition: pick a built-in one or write your own JSON.
  2. Initiative (policy set): group several policies for one goal (a security baseline, say).
  3. Assignment: assign the definition/initiative to a scope (MG, subscription, RG) with parameters.
  4. Compliance: review non-compliant resources and run remediation.

Traps: Policy controls how resources are configured; RBAC controls who can do what. An initiative is a group of policies, not one policy. Creating a resource in a forbidden region under a deny policy fails with RequestDisallowedByPolicy.

Command Meaning
az policy definition list --query "[?displayName=='Allowed locations'].name" -o tsv Find a built-in policy ID
az policy assignment create --name allowed-locations --policy <id> --scope <rg-id> --params '{...}' Assign a policy
az policy state summarize -g rg-devops-lab Compliance summary

Inside a policy definition

A definition is JSON with a rule in if/then form:

{
  "if": { "field": "location", "notIn": "[parameters('allowedLocations')]" },
  "then": { "effect": "deny" }
}

Parameters make one definition reusable with different values per assignment.

The full list of effects

Effect What happens
deny Request is rejected
audit Resource is created and flagged non-compliant
append Adds fields, such as an IP rule, during create or update
modify Adds, changes, or removes tags and some properties
auditIfNotExists Flags a resource when a related resource is missing
deployIfNotExists Deploys the missing related resource, such as a diagnostic setting
denyAction Blocks a specific action, such as delete
disabled Turns the policy off without removing it

modify and deployIfNotExists need a managed identity on the assignment so Azure can make the change.

When policies are evaluated

Resources are checked when they are created or updated, when an assignment changes, and in a full compliance scan roughly every 24 hours. az policy state trigger-scan -g rg-devops-lab starts an on-demand scan. New results can take several minutes to appear.

Exemptions and hierarchy

An exemption removes one resource or scope from an assignment for a stated reason and optional expiry date, which is cleaner than deleting the assignment. Management groups can nest up to six levels below the tenant root group; design the tree around policy and billing needs, not the org chart. For deploying whole environments with policies included, Microsoft now points to template specs and deployment stacks, while Azure Blueprints is being retired.

Practice interactively →