Azure Policy effects and remediation tasks

Start with four separate Azure Policy objects and actions

A policy assignment establishes the rule at scope; it is not the same thing as a remediation task. Evaluation can report a resource as noncompliant without changing it. A remediation task is the separately tracked operation that attempts corrective work on eligible existing resources.

Compare Azure Policy effects by desired outcome

Choose an effect from the requirement, not from the word “compliance” alone. “Report missing diagnostic settings” points to AuditIfNotExists. “Install diagnostic settings when absent” points to DeployIfNotExists. “Reject a resource outside approved regions” points to Deny.

New and updated resources behave differently from existing resources

Policy participates when applicable resources are created or updated, when assignments change, and during periodic or requested compliance evaluation. This timing matters:

• New or updated request: an applicable deny effect can reject it; modify can alter supported request properties; deployIfNotExists can initiate related deployment after its conditions are evaluated.
• Existing resource: evaluation can mark the resource noncompliant, but evaluation alone is not a bulk correction operation.
• Existing resource under modify or deployIfNotExists: create a remediation task to attempt the defined corrective action.
• Audit or deny finding: there is no generic remediation task that invents a correction. Fix the resource through an approved operational change or use a suitable corrective definition.

Remediation eligibility depends on compliance data. A task can use existing noncompliance results or request re-evaluation, depending on how it is created and configured. Track the task separately from the assignment and review per-resource deployments or failures.

Managed identity and RBAC: who performs the correction?

Azure Policy evaluation does not use the assignment identity simply to decide whether a resource matches a rule. The identity becomes essential when modify or deployIfNotExists must change resources. Each assignment can have one system-assigned or user-assigned managed identity, and that identity can receive multiple role assignments.

1. The policy definition identifies required roles through full resource IDs in roleDefinitionIds.
2. The policy assignment is associated with a managed identity.
3. The identity receives the minimum Azure RBAC roles needed at every target scope used by the correction.
4. The remediation task uses that identity to run modify operations or the embedded deployment.

Portal versus automation: the Azure portal can grant the definition's listed roles when the assignment is created. Assignments created through SDKs or other automation can require those role assignments to be added explicitly. Editing roleDefinitionIds later does not automatically refresh the identity's permissions.

A user may have permission to create a remediation task while the assignment identity lacks permission to change the resource. In that case task creation can succeed but individual remediation deployments fail. Always troubleshoot the executing identity, not only the administrator who started the task.

Worked scenarios: tags and diagnostic settings

A safe Azure Policy rollout workflow

1. Translate the requirement: define the exact noncompliant state, target resource types and desired response.
2. Prefer a built-in definition when suitable: inspect its version, parameters, effect and required roles.
3. Start with visibility: Microsoft recommends beginning with audit or auditIfNotExists to measure impact before enforcement.
4. Set assignment scope carefully: account for inheritance, not-scopes and approved exemptions.
5. Configure identity and least-privilege roles: check every scope touched by modify operations or the deployment template.
6. Evaluate and sample results: investigate false positives, unsupported aliases and automation conflicts.
7. Create a bounded remediation task: filter scope or location where appropriate and control parallelism for large estates.
8. Monitor deployments: review successful, failed and skipped resources instead of relying only on the assignment's aggregate state.
9. Move to enforcement deliberately: document rollback, exemption ownership and change review.

Troubleshoot remediation failures by layer

Open the remediation task, inspect the affected resource, and follow the related deployment or event. Do not “fix” authorization failures by granting Owner unless that breadth is genuinely required; determine the exact write or deployment permissions instead.

AZ-104 practice checks with explanations

Common AZ-104 mistakes

• Confusing policy assignment with remediation execution.
• Expecting audit or deny to repair existing resources automatically.
• Assuming assignment identity is used for ordinary policy evaluation.
• Checking the operator's role instead of the remediation identity's role.
• Using Contributor everywhere instead of granting the smallest required permissions.
• Forgetting that cross-scope destinations can require additional authorization.
• Skipping audit-first validation and applying deny at a broad inherited scope.
• Changing a definition's required roles without updating the identity's role assignments.

Frequently asked questions

Official Microsoft references

• Current AZ-104 study guide
• Azure Policy effect basics
• Remediate noncompliant resources
• Modify effect
• DeployIfNotExists effect

Verify current service behavior, built-in definition versions and assignment scope before changing production governance. ITCertPath uses original learning scenarios and does not reproduce confidential exam questions.