azureblog.co.uk
← cd ~/posts

Azure Policy guardrails every subscription should have

A handful of built-in Azure Policy assignments stop the most common mistakes before they happen. Start with these at the management group level.

3 min read⚠ checked 4 Feb 2026Azure · Governance
Part 1 of 5 in Azure landing zone guardrails
On this page
  1. Start with these built-in policies
  2. Roll out with the right effect
  3. How evaluation works
  4. Group them into an initiative
  5. Exemptions done properly

evaluates resources against rules and can audit, deny or automatically fix them. You don't need hundreds of policies to get value. A few well-chosen guardrails at the top of your hierarchy prevent most of the mess.

Tenant root groupKeep assignments minimal here
Management group: Landing zonesAllowed locations, required tags, diagnostics
Subscription: app-prodInherits every assignment above
Resource groupExemptions with a reason and expiry

↓ Assignments inherit downwards. Exemptions are the exception, not the rule.

Assign guardrails high up and they flow down to everything beneath.

Start with these built-in policies

PolicyWhy
Allowed locationsKeeps resources in the regions you've approved for data residency and support
Allowed locations for resource groupsStops resource groups (and their metadata) appearing in other regions
Require a tag on resource groupsEnforces ownership and cost-centre tags so every bill has an owner
Inherit a tag from the resource groupCopies tags down automatically, so you don't rely on people tagging every resource
Storage accounts should disable public network accessCloses one of the most common accidental exposures
Configure diagnostic settingsSends platform logs to your by default

Roll out with the right effect

  1. Assign with Audit first and review the compliance results.
  2. Fix existing resources, or create exemptions with a reason and an expiry date.
  3. Switch to Deny for prevention policies, and use Modify or DeployIfNotExists with a remediation task for policies that can fix things.
shell
# Assign Allowed locations at a management group, UK regions only
az policy assignment create \
  --name allowed-locations \
  --display-name "Allowed locations: UK" \
  --scope "/providers/Microsoft.Management/managementGroups/mg-landingzones" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --params '{ "listOfAllowedLocations": { "value": ["uksouth","ukwest"] } }'
Tip: global resources like DNS zones and Front Door use the location "global". Check your allowed list doesn't block them by accident.
What should happen to a resource that doesn't comply?
Just tell meAudit or AuditIfNotExists
Never allow itDeny (after an audit period)
Fix a property, like a tagModify, with a remediation task for existing resources
Add something alongside itDeployIfNotExists, such as diagnostic settings
Choosing an effect for each policy.

How evaluation works

  • New and updated resources are evaluated when they're created or changed. A Deny policy rejects the request there and then.
  • Existing resources are evaluated by a regular compliance scan, roughly once a day. They aren't deleted or blocked, only marked non-compliant.
  • New assignments can take up to about 30 minutes to start applying. Don't test a fresh Deny policy and conclude it doesn't work.
shell
# Run a compliance scan now rather than waiting
az policy state trigger-scan --resource-group rg-app-prod

# What's non-compliant at a management group?
az policy state summarize --management-group mg-landingzones

Group them into an initiative

Once you have more than a handful of assignments, bundle them into an initiative (policy set). One assignment, one compliance score, and parameters such as the list of allowed regions are set in one place.

Exemptions done properly

  • Use the Waiver category for accepted risk and Mitigated when the risk is handled another way
  • Always add a description that names the owner and the reason
  • Set an expiry date so the exemption gets reviewed
  • Scope the exemption as narrowly as possible: a resource, not a subscription
Will Deny break my existing resources?

No. Deny only stops new or updated resources. Existing ones show as non-compliant until you fix or exempt them, but changes to them can be blocked if the change itself doesn't comply.

Why does my deployment fail on a resource group in another region?

The Allowed locations for resource groups policy applies to the group's own location. Create the resource group in an approved region, even if it holds global resources.

This post was last checked against Microsoft's documentation over six months ago. The approach should still hold, but check the linked sources for anything that has changed before you act on it.

Next in Azure landing zone guardrails · part 2 of 5Resource locks: a cheap insurance policy against the wrong click →

Related posts