3.3 Azure Policy
Key Takeaways
- Azure Policy creates, assigns, and manages rules that keep resource configurations compliant with corporate standards.
- Policy can audit existing resources OR block (Deny) non-compliant ones at creation time — a user with Owner can still be blocked.
- A Policy Initiative (formerly Policy Set) bundles many related definitions into one assignable unit with a single compliance roll-up.
- Azure Policy controls WHAT a resource can do; RBAC controls WHO can access it — they are complementary, not interchangeable.
- Built-in definitions cover allowed locations, allowed VM SKUs, required tags, and encryption; remediation tasks fix existing resources.
Quick Answer: Azure Policy enforces rules on resource configuration. It can audit existing resources for compliance and use the Deny effect to block non-compliant resources at creation. Policy controls WHAT resources can do; RBAC controls WHO can access them.
What Is Azure Policy?
Azure Policy is a governance service that creates, assigns, and manages policies that enforce rules on the configuration of your Azure resources. It evaluates resources against business rules so they stay aligned with corporate standards and service-level agreements. Policy is free of charge and is enforced through Azure Resource Manager (ARM), the deployment and management layer every request passes through.
A critical AZ-900 distinction: Policy evaluates the properties of resources (region, SKU, tags, encryption setting), not the identity of the caller. That is RBAC's job. Because both run inside ARM, an action must satisfy RBAC and Policy to succeed.
The Policy Lifecycle
- Define — author a policy definition in JSON, or pick one of the 1,000+ built-ins.
- Assign — attach the definition to a scope: management group, subscription, or resource group.
- Evaluate — Policy scans resources in scope; full scans run roughly every 24 hours and on demand.
- Report — results appear in the compliance dashboard as Compliant or Non-compliant.
- Enforce / Remediate — new violations are blocked (Deny) and existing ones can be fixed by a remediation task.
Policy Effects
Each definition declares an effect that decides what happens when a resource matches the rule. Memorize the difference between Audit (report only) and Deny (block).
| Effect | What it does |
|---|---|
| Deny | Blocks creation or update of a non-compliant resource. The most common enforcement effect. |
| Audit | Flags the resource as non-compliant in the dashboard but does NOT block it. |
| Append | Adds extra fields to the request (e.g., a default tag) during creation. |
| Modify | Adds, updates, or removes properties/tags on existing and new resources. |
| DeployIfNotExists (DINE) | Deploys a related resource if missing (e.g., a diagnostic setting). Needs a managed identity. |
| AuditIfNotExists | Audits when a related resource is missing. |
| Disabled | Turns off evaluation — useful for testing an assignment. |
Built-in Definitions and Initiatives
| Built-in definition | Effect example |
|---|---|
| Allowed locations | Deny resources outside approved regions (e.g., only East US, West Europe). |
| Allowed virtual machine size SKUs | Deny VM sizes outside an approved list. |
| Require a tag on resources | Deny resources missing a required tag such as CostCenter. |
| Storage accounts should restrict network access | Audit or Deny insecure storage. |
A Policy Initiative (previously Policy Set) groups many definitions so they are assigned and reported as one unit — for example the Azure Security Benchmark initiative bundles dozens of controls. When a scenario describes enforcing several related rules at once, the answer is an initiative, not many separate assignments.
Remediation and Compliance Dashboard
Audit only reports drift; to fix existing resources you create a remediation task, available for the Modify and DeployIfNotExists effects (these use a managed identity granted the needed role). The compliance dashboard in the portal shows the overall compliance percentage, per-policy status, and the specific non-compliant resources with guidance.
Policy vs. RBAC
| Azure Policy | Azure RBAC | |
|---|---|---|
| Question | WHAT can a resource be/do? | WHO can perform an action? |
| Example | "VMs must be in East US" | "Jane is Contributor on Sub-1" |
| Default | Allowed unless a policy denies | Denied unless a role grants |
On the Exam: A user with the Owner role can still be blocked by a Deny policy from creating a VM in a forbidden region. Policy and RBAC are independent gates — both must pass.
A Worked Governance Scenario
Imagine Contoso runs forty subscriptions and finance keeps discovering untagged resources and storage accounts deployed in unapproved regions. Three policies solve this without touching a single resource by hand. First, assign Allowed locations with the Deny effect at the management group so any deployment outside East US or West Europe is rejected the moment it is submitted. Second, assign Require a tag on resources with Deny so a resource cannot be created unless it carries a CostCenter tag.
Third, group both with a third Audit policy that checks for HTTPS-only storage into a single initiative named "Contoso Baseline" and assign that initiative once at the top management group.
After the next evaluation cycle the compliance dashboard reports, for example, ninety-two percent compliant, listing the eight percent of legacy resources that pre-date the rules. Those existing resources were grandfathered in because Deny only blocks new or changed resources — it never retroactively deletes anything. To fix the legacy estate you add a Modify policy to append the missing tag and create a remediation task, which uses a managed identity to write the tag across the non-compliant resources in bulk.
Common Traps
- Audit does not block. If a question says resources "must be prevented" from being created, Audit is wrong — choose Deny.
- Policy is not security. It governs configuration, not identity; RBAC handles who.
- Deny is not retroactive. Existing non-compliant resources stay until remediated; only new or updated ones are blocked.
- DeployIfNotExists and Modify need a managed identity with the right role, or remediation fails.
A company must guarantee that no new resource is ever created outside the East US or West Europe regions. Which configuration enforces this?
Which Azure Policy effect flags a non-compliant resource in the dashboard but still allows it to be created?
An administrator needs to enforce a dozen related security rules as a single assignable, single-reported unit. What should they use?
A user with the Owner role tries to create a VM in a region blocked by a Deny policy. What is the result?