Which Azure Policy effect supports remediation, and what performs it?
Short answer
Choose the DeployIfNotExists effect, and select a managed identity (the system-assigned managed identity of the policy assignment) as the resource that performs remediation.
Question
You need to use Azure Policy definitions and automatic remediation to manage compliance for new resources deployed to the subscriptions. The solution must minimize administrative effort.
Which Azure Policy effect supports remediation, and which Azure resource should be used to perform the remediation? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.

Key Takeaways
The exam tests whether you know remediation-capable effects (DeployIfNotExists/Modify) versus audit-only effects, and that the remediation engine runs as the policy assignment's managed identity — not as a Logic App, runbook, or the deploying user.
Azure Policy remediates non-compliant resources through the DeployIfNotExists and Modify effects, both of which run under a managed identity attached to the policy assignment. This page confirms DeployIfNotExists as the effect and the system-assigned managed identity as the resource that executes the automatic remediation across subscriptions.
Common mistake: Choosing Modify or Audit simply because 'remediation' sounds like a change operation, or picking an Automation account/Logic App as the remediation resource — remediation is performed by the managed identity associated with the policy assignment, not by an orchestration service.
Expert Analysis
Why the Answer Is Correct
Of the built-in Azure Policy effects, only DeployIfNotExists and Modify support remediation tasks; Audit, Deny, Append, and Disabled do not have a remediation path. Because the scenario asks specifically for remediation of new deployments while minimizing administrative effort, DeployIfNotExists is the canonical effect — it evaluates the resource and, when the related resource or configuration is missing, triggers a deployment that creates it. That deployment runs under a managed identity (system-assigned by default, or user-assigned) that Azure Policy attaches to the assignment and grants the required role, so no credentials, connection strings, or pipelines need to be maintained. This identity model is what allows a single assignment at a management group or subscription to enforce and repair configuration across many subscriptions with minimal ongoing effort.
Why Other Candidate Answers Are Wrong
Audit is the tempting distractor: it flags non-compliance but never changes anything, so it fails the 'automatic remediation' requirement. Deny blocks the deployment outright instead of remediating it after the fact. Modify comes closest conceptually and does support remediation, but the wording about deploying a companion resource points to DeployIfNotExists; Modify mutates properties of the resource already being deployed rather than deploying an additional resource. As for the remediation executor, an Automation account, Logic App, or Azure Function is not the native mechanism — the managed identity of the policy assignment is what the remediation task authenticates with, which is why the identity is the correct selection for the second dropdown.
Community Comment Notes
AllanHouston summarized the reasoning the community converges on: "Effect: DeployIfNotExists" and "Resource: A managed identity", noting that policy uses a managed identity "tied directly to the policy assignment" granted the permissions needed to fix non-compliant infrastructure. The practical takeaway from that thread is that remediation is an identity-bound operation, so role assignments at the assignment scope must be in place before remediation tasks can succeed. That also explains why grants can take time to propagate after a new assignment is created.
Official Reference
- https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effects
- https://learn.microsoft.com/en-us/azure/governance/policy/concepts/remediation-structure
These links open the official vendor documentation in a new tab.
Exam Strategy
Memorize the remediation-capable effects as a short list — DeployIfNotExists and Modify — and pair each question about 'automatic remediation' with 'managed identity' as the executor. If the scenario mentions deploying a missing related resource or configuration, DeployIfNotExists is the intended answer over Modify.
Frequently Asked Questions
Does the Modify effect also remediate non-compliant resources in Azure Policy?
Can a user-assigned managed identity be used instead of a system-assigned one for policy remediation?
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
AllanHouston 👍 1Effect: DeployIfNotExists. In Azure Policy, only specific policy effects natively support remediation tasks to fix existing or newly deployed non-compliant infrastructure. These effects are DeployIfNotExists and Modify. Resource: A managed identity. Azure Policy uses a managed identity (either system-assigned or user-assigned) tied directly to the policy assignment. This identity is granted specific Azure RBAC roles (like Contributor) so the policy platform can securely deploy the missing configurations without needing hardcoded credentials, complex runbooks, or external apps.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All AZ-305 Questions
Access 95 questions with complete answers and detailed explanations.
View Full AZ-305 Practice Test →