Azure Policy

What it is

Azure Policy is Azure’s rules engine for resource configuration. It compares resources and management actions with rules your organization assigns, such as “deploy only in approved regions” or “add a cost-center tag.” It can report a mismatch, block a non-compliant change, alter a resource, or deploy related configuration, depending on the policy effect.

Why it exists

People make mistakes. Policy lets an org codify governance so non-compliant resources are automatically flagged (and optionally prevented/denied) at scale across subscriptions — regardless of who creates them.

The pieces

• A definition states one rule. Azure supplies built-ins and organizations can create custom definitions.
• An initiative groups several definitions for one goal, such as a security baseline.
• An assignment applies a definition or initiative at a scope. Child scopes inherit it unless excluded.
• The effect says how Azure responds. Audit reports non-compliance; Deny prevents the non-compliant create or update; Modify or DeployIfNotExists can change or add supported configuration and can require remediation for existing resources.

Northwind example

Maya assigns an “allowed locations” policy to Northwind’s Production management group. When Luis tries to create a production VM in an unapproved region, a Deny effect blocks the request even if his RBAC role lets him create VMs. A different tagging policy first uses Audit, so Northwind can see which resources lack a costCenter tag before deciding whether to use Modify or Deny.

This example shows the division of labor: RBAC asks whether Luis may create a VM; Policy asks whether the requested VM configuration follows Northwind’s rule.

Use it safely

Start an unfamiliar policy in audit mode when practical. Review existing resources, automation, exclusions, and remediation permissions before enforcing with Deny, Modify, or DeployIfNotExists. A policy assignment is powerful at a management-group scope: one mistaken rule can affect many subscriptions.

Common confusion

• Policy does not replace RBAC. It normally does not grant a user permission to act.
• A policy definition alone does nothing until it is assigned to a scope.
• A compliance report does not automatically fix existing resources. Remediation is effect- and resource-specific.
• A more-permissive child assignment does not override an inherited deny. Change or exclude the broader assignment instead.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: azure-policy/overview

Where it appears in the route

Read azure-management-hierarchy and scope before using this entry in AZ-104 foundation.

Related

management-groups · scope · rbac · resource-tags · northwind-traders-case-study

📘 Source: Microsoft Learn — Azure Policy overview, checked 2026-09-16.