3.5 Policy, Initiative, Assignment, and Remediation

Policy objects and how they relate

Azure Policy uses a few related objects. A policy definition describes a rule and an effect. An initiative definition groups multiple policy definitions into a set. A policy assignment applies a definition or initiative to a scope. Parameters make definitions reusable. Exemptions and exclusions reduce or waive evaluation for specific needs. Compliance results show whether resources match the assigned rules.

Policy definition: Require a tag named CostCenter
Initiative definition: Corporate baseline with tags, allowed regions, diagnostics, and SKU rules
Assignment: Apply Corporate baseline to the Prod management group
Parameters: Allowed locations = eastus, westus2; required tag = CostCenter
Remediation: Add missing diagnostic settings to existing resources

The hierarchy matters. A definition sitting in the policy library does nothing until assigned. An assignment at a management group can affect all child subscriptions. An assignment at a resource group affects that group and resources below it. A resource can be evaluated by multiple assignments from different scopes, and the most restrictive practical result may control deployment.

Effects administrators must recognize

The policy effect determines behavior. Audit records noncompliance but allows the request. Deny blocks noncompliant create or update operations. Disabled turns off evaluation. Append adds fields to a request in supported scenarios. Modify can add or update properties such as tags. DeployIfNotExists deploys a related resource or configuration when a condition is missing. AuditIfNotExists reports when related configuration is missing.

Effects that change resources need permissions. A modify or deployIfNotExists assignment usually requires a managed identity and role assignment so policy can remediate resources. If the identity lacks rights, compliance may show noncompliance and remediation may fail. This is a common AZ-104 troubleshooting point.

Assignments, parameters, exclusions, and exemptions

When assigning a policy or initiative, choose the scope carefully. If the requirement says all current and future subscriptions under production need the same allowed regions, assign at the production management group. If only one application resource group needs a rule, assign at that resource group. Do not over-scope deny policies because inherited denies can block legitimate platform work.

Parameters make assignments flexible. A single allowed locations definition can be assigned with eastus and westus2 for production, but eastus, westus2, and centralus for development. A required tag definition can require CostCenter in one assignment and DataClass in another.

Exclusions remove specific scopes from an assignment. Exemptions can document a waiver, often with a reason and expiration. For exams, if a workload must be temporarily allowed to violate a policy while the rest of the scope remains governed, use an exemption or exclusion rather than deleting the assignment for everyone.

Remediation workflow

Policy evaluation does not always fix existing resources. If a deny policy is assigned today, it blocks future noncompliant creates or updates but does not delete existing noncompliant resources. If a modify policy is assigned today, existing resources may need a remediation task. If deployIfNotExists is used for diagnostic settings, existing resources typically need remediation so the related settings are deployed.

Remediation workflow
1. Assign policy or initiative at the correct scope.
2. Configure parameters and assignment identity when needed.
3. Wait for or trigger compliance evaluation.
4. Review noncompliant resources and reasons.
5. Create a remediation task for modify or deployIfNotExists effects.
6. Verify the managed identity has required permissions.
7. Recheck compliance and troubleshoot failures.

Portal path: Policy > Assignments, Policy > Compliance, and Policy > Remediation. CLI and PowerShell can also create assignments and remediation tasks, but AZ-104 usually tests the conceptual operation and failure modes.

Scenario workflow

A security team requires all storage accounts to disable public network access and all resources to have a CostCenter tag. Use an initiative containing at least two definitions: one deny or audit policy for storage network configuration and one tag policy. Assign the initiative at the target management group or subscription. Parameterize the tag name and any allowed values. For existing resources, review compliance. If the storage policy is audit-only, it will report existing noncompliance. If tag correction uses modify, create a remediation task and ensure the assignment identity can write tags.

If a deployment fails after the assignment, inspect the deployment error. Azure Policy denial messages usually identify the assignment and definition that blocked the request. The fix is not to grant Owner to the user if the policy denies the request. Owner does not bypass Azure Policy. The fix is to change the deployment to comply, adjust policy parameters, add an exemption, or move the deployment to a scope where the rule does not apply.

Exam traps

Policy is not RBAC. RBAC answers who can perform an action. Policy answers what resource configurations are allowed or reported. A Contributor can still be blocked by a deny policy. A Reader can still see resources but cannot fix noncompliance unless given write permissions.

Policy is also not a lock. A lock prevents delete or write operations at a scope regardless of resource configuration. Policy evaluates rules. If the requirement is prevent deletion of this resource group, use a delete lock. If the requirement is prevent public IP creation, use deny policy. If the requirement is audit all VMs missing diagnostics, use auditIfNotExists or deployIfNotExists depending on whether you only report or also deploy settings.