Azure Policy Remediation Tasks: Fix Drift Safely

Azure Policy remediation tasks are the difference between “we found cloud drift” and “we fixed it without breaking production.” Azure Policy is excellent at showing non-compliance, but the real value comes when modify and deployIfNotExists policies bring existing resources back into line.

This runbook covers how remediation tasks work, when to use them, which permissions they need, and how to roll them out safely.

What Azure Policy remediation tasks do

Some policy effects only report or block. Two can repair existing resources:

• modify adds or updates supported properties, such as required tags, during requests and through remediation.
• deployIfNotExists deploys related resources or configuration when a required companion doesn’t exist.
• Remediation tasks apply those operations or templates to resources that are already non-compliant.

When remediation is the right tool

Use remediation when the desired state is clear, repeatable and safe at scale: required tags, diagnostic settings, security monitoring, allowed identity settings and companion resources that should sit beside workloads.

Be more cautious when remediation could change application behavior, networking, encryption, identity or data paths. Use staged scopes, test subscriptions and explicit exclusions. If a policy could break a deployment pipeline, treat it like code: review, test, version and roll it out in rings.

Preflight checklist

• Confirm the effect: only modify and deployIfNotExists repair existing drift.
• Check the identity: the assignment has a system- or user-assigned managed identity.
• Review RBAC: the identity has the minimum roles the definition requires.
• Scope carefully: start with one resource group or pilot subscription.
• Inspect compliance in the portal, CLI, Azure Monitor logs or Resource Graph.
• Prepare rollback: know what will change and how to revert it.

How permissions work

Remediation uses the managed identity attached to the policy assignment. Microsoft is clear that evaluation and remediation are separate: the identity deploys or modifies resources during remediation, but doesn’t perform evaluation.

Built-in definitions prepopulate the required roles. Custom definitions should list them in roleDefinitionIds under details. If you later add roles to a definition, you may need to grant them to the assignment’s identity manually.

"details": {
  "roleDefinitionIds": [
    "/providers/Microsoft.Authorization/roleDefinitions/<built-in-role-guid>"
  ]
}

Keep the identity least-privileged. If the task only configures diagnostic settings, don’t give it subscription Contributor just because that makes the error disappear.

A safe rollout model

1. Lab: validate policy logic, parameters and expected changes.
2. Pilot resource group: remediate a narrow, low-risk scope.
3. Non-production subscriptions: watch failures, timing and operational noise.
4. Production waves: by business unit, region or workload group.
5. Continuous governance: leave the assignment in place so new and updated resources are handled automatically where supported.

Compliance data isn’t instant. Microsoft documents that a new assignment starts applying after a few minutes, create and update events can take around 15 minutes to appear, subscription moves take longer, and the standard evaluation cycle runs daily. Build that latency into expectations before declaring a policy broken.

Runbook: create and monitor a remediation task

1. Identify the assignment: scope, effect, parameters, exclusions and enforcement mode.
2. Review non-compliant resources, for example with Azure Resource Graph queries.
3. Confirm identity permissions against the definition’s required roles.
4. Create the task. For an initiative, select the specific policy definition reference; a task handles one definition or reference at a time.
5. Throttle deliberately with resource count, parallel deployments and failure threshold.
6. Monitor results: provisioning state, deployment summary, failed resources, and compliance after evaluation catches up.
7. Document exceptions with policy exemptions or excluded scopes that have an owner and expiry.

Settings to understand first

Troubleshooting failed remediation tasks

Resist the urge to broaden permissions straight away. Inspect the error, confirm the role requirements, verify the identity and test against one known resource first.

Guardrails for production remediation

• Group related controls in initiatives, but remediate one reference at a time.
• Version custom definitions in source control and review changes like code.
• Prefer user-assigned identities for repeatable governance patterns.
• Keep exclusions temporary, each with an owner, reason and review date.
• Measure before and after remediation.
• Maintain a catalog of policies approved for automatic production remediation.

Use cases that usually work well

Azure Policy remediation tasks turn policy from a report card into an operations tool: audit first, scope tightly, grant least privilege, remediate in rings and validate once compliance catches up. For broad delete protection, pair them with Azure Resource Locks.

Last reviewed: October 2026

Sources

• Remediate non-compliant resources with Azure Policy (Microsoft Learn)
• Azure Policy remediation task structure (Microsoft Learn)
• Azure Policy assignment structure (Microsoft Learn)
• Azure Policy effect basics (Microsoft Learn)
• Get Azure Policy compliance data (Microsoft Learn)