Azure Policy Governance: Initiatives and Remediation · CloudEngineerHub
Azure9 min read1 views
Azure Policy Governance: Initiatives, Deny Effects and Remediation Tasks in Practice
Run Azure Policy like a platform team: initiatives, deny and DINE effects, remediation with managed identities, staged audit-then-deny rollouts, and exemptions.
C
CloudEngineerHub Team
Published: August 30, 2026· Last Updated: September 28, 2026·9 min read
Azure Policy Governance in Practice
Every Azure estate drifts unless something structural holds the line: the storage account without private endpoints, the VM someone deployed without backup, the resource missing the tag that your cost report depends on. Azure Policy is that structure — but deployed naively, deny-on-day-one stops deployments across the organization and the platform team gets uninvited from meetings. The difference between governance that sticks and governance that gets disabled is sequencing, effect selection, and remediation that actually works. This guide is the operating manual.
Visual Walkthrough
How a policy definition becomes a deny, an audit trail, and a fix task.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Related definitions group into an initiative for assignment.
assign
3
Assignment at scope
Assigned at MG or subscription; exemptions documented.
evaluate
4
Compliance evaluated
Resources scanned; state lands in compliance dashboard.
remediate
5
Remediation task
deployIfNotExists/modify fixes existing resources at scale.
6
Re-evaluation cycle
Continuous loop keeps new and existing resources aligned.
Continuous cycle
Azure Policy — Definition to Remediation Loop. 1. Definition authored: Effect set: deny, audit, append, deployIfNotExists, modify. — 2. Initiative bundles: Related definitions group into an initiative for assignment. — 3. Assignment at scope: Assigned at MG or subscription; exemptions documented. — 4. Compliance evaluated: Resources scanned; state lands in compliance dashboard. — 5. Remediation task: deployIfNotExists/modify fixes existing resources at scale. — 6. Re-evaluation cycle: Continuous loop keeps new and existing resources aligned.
Prerequisites
Resource Policy Contributor (or Owner) at the scope you govern — management group, subscription, or resource group
A management group hierarchy aligned to your org (landing zone pattern: platform MGs above workload MGs) so assignments inherit cleanly
For remediation: permission to create managed identities and grant them roles on the target scope (User Access Administrator or Owner, typically)
az CLI 2.x (az policy, az graph command groups) or equivalent portal access
A defined exception path — who can request an exemption, who approves, and where it is recorded — before the first deny goes live
Definitions, initiatives, and the mental model
A policy definition is one rule: one condition, one effect. An initiative (policy set) bundles definitions so you assign and report on them as a unit — for example the built-in Microsoft cloud security benchmark initiative. Definitions use aliases (normalized property paths like Microsoft.Storage/storageAccounts/networkAcls.defaultAction) so one rule works across API versions.
Assignments attach definitions or initiatives to a scope, and scope is inherited downward — an assignment on the platform management group governs every subscription under it. Parameters make one definition reusable across environments: the same "required tag" policy enforces environment=production in one subscription and environment=dev in another.
Blocks destructive actions (e.g., deleting NSG rules in production)
Protecting live platform components
Two failure modes account for most governance pain: deny deployed before a baseline exists (blockage everywhere, policy gets exempted into meaninglessness), and DINE deployed without understanding the managed identity's permissions (remediation fails forever with silent 403s in activity logs).
The safe rollout: audit, collect, exempt, deny
The pattern that survives contact with a real organization:
Audit everywhere first. Assign at audit for 30–60 days. Nothing breaks; you learn the true blast radius.
Quantify with Resource Graph. Query noncompliance counts, break them down by subscription and team, and publish the numbers.
Exempt the legitimate exceptions through the formal policy exemptions process — with expiry dates.
Flip to deny (or enforce with modify/DINE) in waves: platform subscriptions first, then pilot workloads, then the estate.
Re-audit continuously and feed new noncompliance back into the exception review instead of ad-hoc anger.
Assigning the built-in "Require a tag and its value" policy at audit for the rollout phase:
Bash
1
2
3
4
5
6
az policy assignment create \
--name audit-env-tag \
--display-name"Audit missing environment tag (phase 1)" \
--policy"/providers/Microsoft.Authorization/policyDefinitions/871b6d14-10aa-478d-b590-94f262ecfa99" \
--scope"/subscriptions/<sub-id>" \
--params'{"tagName":{"value":"environment"},"tagValue":{"value":"production"}}'
Scanning and reporting happen automatically on assignment and on resource changes, but you can trigger an evaluation scan on demand:
Bash
1
az policy state trigger-scan --no-wait
Field note: The audit phase is a political instrument as much as a technical one. Publishing "1,284 noncompliant resources, and here are the ten subscriptions causing 80% of it" converts governance from a mandate into a shared scoreboard — and flipping to deny becomes unsurprising rather than hostile.
Remediation tasks with managed identity
audit/deny need nothing extra, but modify and deployIfNotExists act on resources — so the assignment gets a managed identity, and that identity needs RBAC on the target scope. Get this wrong and every remediation task fails with authorization errors.
Create an assignment with a system-assigned identity
The --mi-system-assigned, --role, and --scope-role flags create the identity and grant the least role it needs (Contributor or more specific roles depending on the definition — the definition's documentation lists the required role). After changing identity roles, expect a propagation delay before remediation succeeds.
Run the remediation
Remediation applies DINE/modify to existing noncompliant resources (new deployments are handled by the effect itself). In the portal: Policy > Compliance, drill into the assignment's noncompliant resources, and select Create remediation task — it can also be driven from the resource or assignment page. Via CLI:
ReEvaluateCompliance re-scopes compliance before remediating (useful after broad changes); the default ExistingNonCompliant remediates the current snapshot. Remediations run in batches — watch the task's deployed-resources count, and check the managed identity's activity logs when counts stall.
Field note: A DINE assignment with an under-privileged managed identity produces the worst kind of failure: everything looks deployed, compliance stays red, and the actual error lives in the identity's deployment history. Check there before you blame the policy definition.
Visual Walkthrough
Policy, RBAC and cost roll downward — design the stack before workloads.
Layered StackAzure Scope Hierarchy — Inheritance Down the Stack5/5
PerimeterCore asset
1
Management groups
Enterprise agreement topology: platform vs landing zones.
layer 1
2
Subscriptions
Billing + policy boundary; one workload per subscription pattern.
layer 2
3
Resource groups
Lifecycle boundary — deploy, tag, and delete as a unit.
layer 3
4
Resources
VMs, storage, networking — the only layer that serves traffic.
Each layer assumes the previous one failed — depth is the strategy.
Azure Scope Hierarchy — Inheritance Down the Stack. 1. Management groups: Enterprise agreement topology: platform vs landing zones. — 2. Subscriptions: Billing + policy boundary; one workload per subscription pattern. — 3. Resource groups: Lifecycle boundary — deploy, tag, and delete as a unit. — 4. Resources: VMs, storage, networking — the only layer that serves traffic. — 5. Inheritance rule: Everything above flows down; nothing below flows up — design accordingly.
Exemptions without erosion
Policy exemptions are first-class Azure resources: they attach to a resource, resource group, or subscription, carry a category (Waiver, Mitigated, and others) and — critically — an expiry date. That expiry is the entire governance model: a mitigation without an end date is a permanent hole, so make expiresOn mandatory in your exception process and review the exemption list in your governance cadence.
Use assignment exclusions (resource selectors/notScopes on the assignment) for structural, permanent cases like excluding the platform itself from a workload rule, and exemptions for time-boxed, resource-specific cases like a migration window. Audit both monthly:
Bash
1
az policy assignment list --disable-scope-strict-match -o table
And treat an exemption request that repeats three times as a signal the policy is wrong, not the team.
Compliance dashboards and reporting
Policy > Compliance in the portal gives per-assignment compliance percentages and noncompliant-resource lists; that is the audit surface. The engineering surface is Azure Resource Graph, which lets you build the views your teams actually use:
Bash
1
2
3
4
5
# Top noncompliant resources by assignment
az graph query -q "PolicyResources \
| where complianceState == 'NonCompliant' \
| summarize count() by policyAssignmentName, subscriptionId \
| order by count_ desc" --first20 -o table
For continuous visibility, ship policy compliance data to Log Analytics (built-in integration under Policy > Settings) and build workbooks per management group — one for the platform team, one per workload, each showing trend lines rather than point-in-time shame. The metric that matters month-over-month is the noncompliance velocity: new noncompliant resources minus remediated ones. Negative velocity is the only number that proves governance is working.
Landing-zone governance tips that age well
Assign initiatives at management groups, not per subscription — per-subscription assignments die with subscription sprawl and re-creation.
Start from built-ins (Microsoft cloud security benchmark, network, tagging initiatives) before authoring custom definitions; every custom definition is a maintenance contract.
Pair every DINE with its audit twin during rollout: audit tells you the blast radius, DINE fixes it, then the audit version retires.
Version and stage custom definitions with your infrastructure repo — policy-as-code with CI validating definitions against a test subscription beats console edits every time.
Deny only what is truly irreversible: tags and diagnostics can be DINE'd; a wrong region or unapproved SKU is often better caught by deny at deployment than fixed after.
Keep the exception path fast. A two-week approval loop for a 30-minute exemption guarantees shadow exemptions via subscription moves.
Key takeaways
Definitions are single rules, initiatives bundle them, assignments apply them by scope with downward inheritance — design for management groups, not subscriptions.
Choose effects by job: audit for discovery, deny for irreversible mistakes, modify/append for property enforcement, DINE to wire missing related resources.
The audit → quantify → exempt → deny sequence is what separates governance that sticks from governance that gets bypassed.
DINE and modify assignments carry a managed identity that needs explicit RBAC; most "remediation is broken" incidents are identity permission failures, not bad definitions.
Remediation tasks bring existing resources to compliance — use them in batches after enabling enforcement, and watch the identity's deployment history for silent failures.
Exemptions expire or they become holes; enforce expiresOn and review assignment exclusions monthly.
Report velocity, not snapshots: Resource Graph queries and Log Analytics-backed workbooks turn compliance into a trending metric teams respond to.
Frequently asked questions
What is the difference between an initiative and just assigning multiple policies?
Technically overlapping — you could assign each definition separately. Practically, an initiative gives you one assignment, one parameter set, one compliance report, and one exemption surface for a group of related rules. When the security benchmark updates, a built-in initiative updates as a unit; a hand-built list of individual assignments becomes an inventory you now maintain forever.
Why do my deployIfNotExists remediations keep failing with authorization errors?
Because the assignment's managed identity lacks RBAC on the target resources. The definition documentation states the required role; grant it to the identity at the assignment scope (or a scope that covers the resources), then recreate the remediation task. Also remember role assignments propagate — a freshly granted identity can fail for several minutes before anything succeeds.
Should I use deny or deployIfNotExists for tagging?
Tags are the classic modify effect case: modify adds the tag at creation with no user friction and no broken deployments. deny on tags works but generates helpdesk tickets for a problem that is trivially fixable automatically. Reserve deny for cases where wrongness is expensive to unwind — unapproved regions, missing encryption settings, SKUs with no backup capability — and let append/modify quietly enforce everything that is just metadata.
Comments
0No comments yet — be the first to share your thoughts.