Azure Policy¶

The landing zone governs itself with Azure Policy. One module, the ALZ pattern module, builds the whole management group hierarchy and assigns the policy that governs every subscription placed into it. The same module runs a second time in the amba unit to assign the Azure Monitor Baseline Alerts policies over the hierarchy. This section explains how that policy is put together and the two layers where you customize it.

This is Azure Policy, the platform's preventive and detective governance. It is a different thing from the policy, security, and cost gates, which run conftest, checkov, and infracost against a Terraform plan in a pull request. The gates check code before it applies. Azure Policy governs resources once they exist.

How policy reaches a management group¶

The hierarchy and its governance flow through one unit in the landing-zone repository, live/_foundation/landing-zones/, which sources Azure/avm-ptn-alz/azurerm (the live/_foundation/amba/ unit instantiates the same module against the amba architecture for the alert policies). The module reads a library through the alz provider, builds the management groups from an architecture, and assigns policy to each group from the archetypes attached to it.

flowchart LR
  L[ALZ library<br/>definitions, sets,<br/>assignments, archetypes,<br/>architecture] -->|alz provider<br/>library_references| P[avm-ptn-alz]
  P --> H[Management group<br/>hierarchy]
  P --> A[Policy assignments<br/>on each MG]
  M[policy_assignments_to_modify<br/>policy_default_values] -.tune.-> A

The library is layered. The provider reads the stock Azure Landing Zones library first, then your own library on top. The reference implementation vendors its library into the landing-zones unit at lib/ and points the provider at it with get_terragrunt_dir(), so there is no external dependency to resolve at plan time:

provider "alz" {
  library_overwrite_enabled = true
  library_references = [
    { path = "platform/alz", ref = "2026.04.2" },
    { custom_url = "${get_terragrunt_dir()}/lib" },
  ]
}

A git reference to a shared repository ({ custom_url = "git::https://github.com/<org>/<repo>.git//library/<path>?ref=<tag>" }) is technically possible when you want one library across many repos, but the platform dropped that model in July 2026: the vendored lib/ is the shipped shape.

References are read in order, so your library comes last and wins. library_overwrite_enabled lets one of your assets replace a stock asset of the same name. Everything in the combined library must be uniquely named otherwise.

What lives where¶

Piece	Location	Owns
Module consumption and live tuning	the landing-zone repo, `live/_foundation/landing-zones/main.tf`	Which assignments to modify, and the default values fed to them.
Provider and library pin	the same unit's `terragrunt.hcl`	The stock library ref and the local `lib/` path.
Your custom library	vendored in the unit at `live/_foundation/landing-zones/lib/`	Your architecture, archetypes, and your own definitions, sets, and assignments.

The two customization layers¶

There are two places to change policy, and the right one depends on what you are changing.

Layer	Where	Use it to
In-repo tuning	`policy_assignments_to_modify` and `policy_default_values` in `landing-zones/main.tf`	Change parameters, effects, enforcement mode, non-compliance messages, scope exclusions, or disable a single assignment. Fast, no library release.
In-library authoring	the vendored `lib/`	Add or replace a policy definition, an initiative, an assignment, an archetype, or reshape the management group hierarchy.

Reach for in-repo tuning first. It needs no library release and it is the module's designed seam for per-tenant differences. Author in the library when the change is structural or you want it to ship to every client that consumes the library.

The recipes for both are in Customizing policies.

The reference baseline¶

Out of the box the stock archetypes assign the Microsoft cloud security benchmark and the ALZ policy set to the intermediate root, and the corp, online, and platform archetypes layer their own assignments below.

The starter library ships one worked example on top of that: a tag-governance archetype attached to the intermediate root, which assigns a baseline tagging strategy (mandatory tags on resource groups, allowed values checked on any resource carrying the tag, and tag inheritance from subscription and resource group). Its tag keys follow the Microsoft Cloud Adoption Framework tag examples (app, env, opsteam, costcenter, businessunit, criticality, confidentiality). Treat it as the template for your own controls: adapt the tags, values, and scope per client.

The example effects start in Audit and move to Deny once the estate is clean. That advisory-first rollout is a deliberate governance pattern, and it maps to the CAF Govern methodology (policy-driven guardrails introduced without blocking existing workloads) and the WAF Operational Excellence pillar (change landed safely). Moving to Deny then serves WAF Security and Cost Optimization, since untagged and misclassified resources are prevented rather than reported.

Next: Customizing policies.