Azure Policy remediation: fixing the resources you already have

You write a policy that says "every storage account must have secure transfer on." Great — new ones will comply. But what about the four hundred storage accounts already deployed, half of them non-compliant? Policy alone leaves them sitting there, flagged and broken. Remediation is the part that walks the estate and actually fixes them.

Azure Policy is famously good at the door: assign a policy and, going forward, resources that violate it can be denied, audited, or auto-configured at creation. But governance has a second, harder half — the resources that already exist. Remediation is how you close that gap. Microsoft's framing is exact: resources that are non-compliant to policies with deployIfNotExists or modify effects "can be put into a compliant state through Remediation," accomplished through remediation tasks that run the policy's deploy or modify logic "on your existing resources."

Why existing resources need a separate step

The policy effects that change things — deployIfNotExists (deploy a missing companion resource, like a diagnostic setting) and modify (add or change a property, like a tag) — naturally fire when a resource is created or updated. But they do not retroactively sweep through everything that was deployed before the policy existed. So the moment you assign such a policy, you get a compliance report full of red for the existing estate, and nothing changes on its own. A remediation task is the deliberate action that says "go apply this policy's fix to the resources already out there." New resources self-heal at evaluation; old ones wait for you to remediate.

Policy guards the door for new resources. Remediation walks the building and fixes the ones already inside.

The managed identity is the engine

Here is the mechanism that makes it work — and the part interviewers love. To deploy or modify resources on your behalf, a policy assignment needs permission, so it carries a managed identity. When Azure Policy remediates, it "does so using a managed identity associated with the policy assignment," and that identity must hold the RBAC roles the fix requires (for example, Contributor, or something narrower). Assign the policy in the portal and Azure grants those roles to the identity automatically; assign it via an SDK or pipeline and you must grant them yourself, or remediation fails with a permissions error. So the chain is: policy defines the fix → its managed identity holds the rights → a remediation task runs the fix across existing resources. No identity with the right roles, no remediation.

Running one

A remediation task is straightforward once the identity has permissions. You pick the non-compliant deployIfNotExists or modify assignment, optionally narrow the scope (a subscription, a resource group, or specific resources) and filter by location, and start it. Azure then deploys or modifies across the matching non-compliant resources, and you can watch progress and drill into any failures. You can also tune it — how many resources at once, and a failure threshold so the whole task stops if too many fail. The result: the estate that was red in the compliance report goes green because it was actually changed, not just re-scored.

The takeaway

Azure Policy remediation is how you fix the resources that already exist, not just the ones arriving. Remediation tasks run a policy's deployIfNotExists or modify effect across your current non-compliant resources, powered by the policy assignment's managed identity, which must hold the right RBAC roles (granted automatically in the portal, manually via SDK). New resources are handled at evaluation; existing ones need a remediation task you scope and start. "A deployIfNotExists policy for logging, its managed identity granted the roles, and a remediation task to retrofit the existing estate" is the answer of someone who governs the cloud they inherited, not just the one they are about to build.