Azure Policy: Effects, Initiatives, and Compliance Enforcement

Azure Policy is Microsoft’s governance service for defining rules about how Azure resources must be configured, then continuously evaluating every resource against those rules. Depending on the effect you assign, a non-compliant resource can be blocked from ever being created, flagged for later review, or automatically fixed. That’s a fundamentally different job than Azure role-based access control (RBAC): Policy asks whether a resource’s properties meet organizational standards, while RBAC asks whether a specific person is allowed to touch that resource at all. The distinction between those two questions, and the vocabulary Policy uses to enforce its half of it, comes up constantly on the AZ-900 governance domain.

What Azure Policy actually enforces

A policy definition is a JSON document describing a condition to check on a resource — a required tag, an approved list of regions, an allowed set of VM SKUs — paired with an effect that fires when a resource fails that check. Once assigned to a scope, Azure evaluates every resource there against it, both at creation or update and on a recurring cycle afterward, so the rule stays enforced rather than acting as a one-time gate.

That’s what separates Policy from a written standard: it’s active enforcement, not something employees have to remember. A company that needs every resource group tagged with a cost center doesn’t rely on people following convention — a Deny-effect policy definition simply refuses the request until the tag is present, the same tags that power chargeback reporting in Azure Cost Management.

The effects: what happens when a resource doesn’t comply

The effect is the verb in a policy definition — it decides what Azure actually does with a non-compliant resource. The core effects worth knowing:

• Deny blocks the create or update request outright. The resource is never created or changed if it fails the rule. Deny only intercepts new requests — it has no retroactive power over resources that already existed before the assignment was created.
• Audit and AuditIfNotExists log a resource as non-compliant on the compliance dashboard without blocking or changing anything. These are the report-only effects, useful for understanding impact before switching to something stricter.
• Append adds a specified field or value — such as a required tag — to a resource request as it’s being created, without rejecting the request.
• Modify actively changes a resource’s tags or properties during creation or update to bring it into compliance. Because Modify makes a real change on the caller’s behalf, it requires a managed identity with the appropriate role permissions.
• DeployIfNotExists checks whether a related resource or configuration already exists — diagnostic settings on a storage account, for example — and deploys it automatically if it’s missing, without blocking the original request.
• Disabled turns off evaluation entirely, typically used while testing a definition.

One detail the exam likes to test: DeployIfNotExists and Modify only fire automatically going forward, on new creation and update events. Resources that already existed before the assignment and haven’t been touched since won’t retroactively get fixed — someone has to trigger a remediation task to backfill compliance on them.

Initiatives group related policies

An initiative — also called a policy set — bundles multiple related policy definitions so they can be assigned and tracked together toward one broader goal, rather than managing dozens of individual assignments. Microsoft ships built-in initiatives for this purpose, including the Azure Security Benchmark, which groups security-focused definitions that evaluate resources against Microsoft’s recommended controls, and regulatory compliance initiatives mapped to standards like ISO 27001. Assigning one of these gives an organization a single, consolidated compliance score for an entire framework instead of piecing that picture together policy by policy.

Scope, inheritance, and exemptions

Policy assignments can target a management group, a subscription, a resource group, or an individual resource — the same subscription and management group hierarchy used throughout Azure governance. Assignments made at a higher scope are inherited down the hierarchy automatically — assign a policy at a management group and every subscription and resource group beneath it picks it up without further configuration.

That inheritance is cumulative, not a matter of one assignment overriding another. If the same definition is assigned at both a management group and a subscription nested underneath it, with different parameters at each level, a resource in that subscription has to satisfy both simultaneously. Neither assignment cancels the other out.

Sometimes a single resource legitimately needs to be excused from a rule without weakening it everywhere else — a test resource group that needs to deploy outside the approved regions, say. That’s what a policy exemption is for: it excuses one specific scope from an assignment, optionally with an expiration date and a documented reason, while the policy keeps enforcing normally everywhere else.

Cost and the compliance dashboard

Azure Policy itself carries no charge — creating, assigning, and evaluating definitions is free regardless of scale. Costs can still appear indirectly, though, when an effect provisions something billable, like DeployIfNotExists deploying a monitoring agent.

The compliance dashboard reports an aggregate compliance percentage for a scope and drills down to which resources are failing which definitions. Right after an assignment is created or changed, don’t be surprised by a status of “Not started” — Azure Policy needs to complete an initial evaluation cycle before the dashboard reflects real state.

Azure Policy vs Azure RBAC

	Azure Policy	Azure RBAC
Governs	Resource configuration and properties	Who can perform which actions
Answers the question	”Is this resource set up correctly?"	"Is this person allowed to do this?”
Mechanism	Policy definitions and initiatives, JSON-based	Role definitions and role assignments
Typical outcome	Deny, Audit, Modify, DeployIfNotExists	Allow or deny specific operations
Example rule	Block storage accounts outside approved regions	Grant a user permission to create storage accounts

The two are complementary, not competing: an organization commonly uses RBAC to control who can create resources at all, and Azure Policy to constrain what those resources are allowed to look like once created.

How the AZ-900 exam tests this

• A scenario describes something that must be blocked at the moment of creation — a missing tag, a disallowed region, a public storage account. The answer is a policy definition with the Deny effect, not a resource lock (which doesn’t evaluate configuration) and not RBAC (which doesn’t touch resource properties).
• A scenario wants visibility without disruption — identify non-compliant resources without stopping any deployment. That’s Audit or AuditIfNotExists, and the exam uses this to distinguish passive reporting effects from Deny.
• A scenario wants automatic remediation that doesn’t hold up the original request — install a missing extension, deploy missing diagnostic settings. That’s DeployIfNotExists, often paired with a follow-up question about needing a remediation task to catch resources that predate the assignment.
• A scenario directly asks you to distinguish Azure Policy from RBAC or from a resource lock. The exam consistently frames Policy as governing configuration, RBAC as governing actions and identity, and locks as governing deletion and modification regardless of role.
• A scenario needs one resource excused from an otherwise-enforced Deny policy without loosening it elsewhere. That’s a policy exemption, not disabling the assignment and not deleting it.

Once you can sort a scenario into “block,” “report,” “fix automatically,” or “excuse,” picking the right Policy effect becomes mechanical rather than a guess. If you want to test that instinct against real exam-style scenarios, practice with AZ-900 questions that mix Policy effects with the other governance tools it’s most often confused with.

For the deletion-and-modification side of governance that Policy doesn’t cover, see Azure Resource Locks. For a deeper look at how Policy’s “who can act” counterpart works, see Azure RBAC vs. Conditional Access.

Quick reference

• Azure Policy evaluates resource configuration; RBAC controls who can act on resources — they’re complementary, not interchangeable.
• Policy definitions are JSON documents; an initiative groups multiple definitions under one assignment.
• Key effects: Deny (block), Audit/AuditIfNotExists (report only), Append (add a field), Modify (change properties, needs managed identity), DeployIfNotExists (deploy missing config), Disabled (off).
• Assignments can target management groups, subscriptions, resource groups, or individual resources, and inherit downward cumulatively.
• DeployIfNotExists and Modify don’t act retroactively without a remediation task.
• A policy exemption excuses one scope from an assignment without disabling it elsewhere.
• Azure Policy itself is free; only resources an effect deploys are billed normally.