Azure Policy Basics

 

What are Azure policies?

Azure Policy is a cloud governance tool that helps you enforce rules and ensure compliance across your Azure environment. With policies you define desired configurations such as allowed locations, required tags, approved VM sizes, or security settings and Azure automatically evaluates resources against those rules. Policies can block non‑compliant changes, flag them for review, or even remediate issues automatically, and you organize multiple policies into initiatives for easier management. Applied at a scope from management groups down to individual resources, Azure Policy gives visibility through compliance reports and helps teams maintain secure, consistent, and cost‑aware cloud deployments.

Why cloud governance matters

Cloud governance is the set of rules, processes, and controls that ensure cloud use aligns with an organization’s security, compliance, and cost objectives. As teams move faster and infrastructure grows, governance stops being an afterthought and becomes a fundamental enabler. It lets organizations scale cloud adoption safely while still delivering the agility developers and product teams expect.

Left unmanaged, cloud environments quickly fragment. Multiple subscriptions, ad hoc resource deployments, and differing team practices lead to inconsistent configurations, duplicated services, and “cloud sprawl”. Those inconsistencies create real risks:

• Security gaps (misconfigured networking or missing encryption)
• Compliance violations (data residency or audit requirements)
• Unexpected costs from oversized or forgotten resources

Governance as guardrails

Governance provides the guardrails that reduce these risks without turning every deployment into a manual gatekeeping process.

Good governance balances control and velocity. Rather than blocking every action, modern cloud governance focuses on automated enforcement of critical rules and visibility into everything else. That means:

• Preventing high‑risk actions (for example, blocking public access to storage accounts)
• Detecting and flagging non‑compliant resources so teams can remediate or justify exceptions
• Automating fixes where possible (deploying diagnostics agents, enforcing tagging standards)
• Providing auditable records for regulators and auditors

Beyond security and compliance, governance drives cost discipline and operational consistency. Enforcing allowed regions and VM SKUs, requiring tags for chargeback, or ensuring monitoring is enabled all contribute to predictable spending and faster incident response. Governance also clarifies ownership and responsibilities, who can deploy what, and where, to reduce shadow IT and improve accountability.

Practical governance is iterative. Start by discovering current state and running non‑blocking audits to understand impact. Define a small set of high‑value controls (location, identity, logging, costs), enforce those with policy, and grow the program over time. Treat policies as code, version them, test in a sandbox, and integrate them into CI/CD so governance becomes part of the development lifecycle, not a separate step.

Azure Policy is a tooling layer that implements this approach by letting you codify rules, apply them at scale, and monitor compliance centrally. In short: cloud governance matters because it transforms cloud from a risky, chaotic environment into a controlled, auditable, and cost‑effective platform that teams can rely on.

Core concepts and terminology

Before you start writing or assigning policies, it helps to be clear on the building blocks Azure Policy uses. At a high level, policies are declarative rules expressed in JSON, grouped into initiatives for easier management, and applied to a specific scope (management group, subscription, resource group or resource). Parameters make policies reusable, effects control what happens when a rule matches, and modes determine which resource types a policy evaluates. Below are concise explanations and practical notes for each core concept.

Policy definition

A policy definition is the fundamental unit: a JSON object that describes a condition (the “if” block) and an outcome (the “then” block). The condition inspects resource properties (fields) and parameters, and the outcome uses an effect to decide what happens when the condition is true.

Practical notes:

• Keep definitions focused and single-purpose where possible, smaller policies are easier to test and reuse
• Use descriptive displayName and metadata so others know intent and impact
• Example (simplified): a rule that denies deployments outside allowed locations

Initiative (policy set)

An initiative (formerly “policy set”) is a collection of policy definitions combined into one higher-level object. Initiatives let you assign a group of related controls together (for example, a “security baseline” or “cost control” initiative), and provide a single compliance view for that group.

Practical notes:

• Initiatives can accept parameters and pass them to child policies, enabling consistent configuration across multiple controls
• Use initiatives to package standards for environments (dev, prod) and to simplify assignments
• Version and document initiatives like you would a product

Assignment and scope

Assignment is how you apply a policy definition or initiative to your Azure estate. You choose a scope, a management group, subscription, resource group, or individual resource and bind the policy/initiative to it. Scope determines which resources are evaluated. Assignments may also include exclusions (NotScopes) to carve out exceptions.

Practical notes:

• Inheritance: Assignments at higher scopes (management group) automatically apply to lower scopes (subscriptions, resource groups) unless explicitly excluded
• Use management groups for org-wide controls, subscriptions for billing/ownership boundaries, and resource groups for environment-level exceptions
• Limit who can create/assign policies via RBAC to avoid accidental broad enforcement

Parameters

Parameters are variables defined in a policy definition or initiative so the same definition can be recycled with different values. Common parameters include allowedLocations, allowedSkus, or tagName/tagValue.

Practical notes:

• Parameterize values that vary between scopes (regions, teams) and keep logic generic
• Provide default values and allowedValues where possible to reduce assignment mistakes
• When assigning an initiative, you can override child policy parameters to tailor behavior per scope

Effects

Effects determine the action taken when a condition matches:

• Append
  Add or set properties on the resource request (for example add tags) but only for new/updated resources where the property can be set
• Audit
  Mark the resource as non‑compliant and record it in the compliance dashboard
  Use to assess impact before enforcement
• AuditIfNotExists
  Like Audit but specifically checks for a related resource (e.g., a monitoring diagnostic setting) and audits if it’s missing
• Deny
  Block the resource operation (create or update) that violates the rule
  Use for high‑risk or non negotiable controls
• DenyAction
  Is a deny‑style effect that blocks specific operations (currently only DELETE) rather than just evaluating resource properties
  
• DeployIfNotExists
  Trigger a deployment (ARM template) to create or configure dependent resources when the condition finds a missing artifact (for example deploy diagnostic settings if absent)
  Note DeployIfNotExists is remediation-style and may require a managed identity and additional permissions
• Disabled
  The policy definition exists but its effect is turned off, useful when you want to keep a definition but not enforce or evaluate it
• Manual
  Lets owners self‑attest compliance (no automatic evaluation)
  
• Modify
  Change resource properties during evaluation to bring them into compliance (for example enforce a secure setting)
  Modify can be more flexible than Append but needs careful testing.
• Mutate
  Is an Azure Policy effect for Kubernetes (Microsoft.Kubernetes.Data mode) that modifies/remediates AKS cluster resources (e.g., pods)
  

Practical notes:

• Start with Audit/AuditIfNotExists to measure impact. Move to Modify, DeployIfNotExists, Deny or DenyAction only after testing
• Use DenyAction when you need to provide clearer feedback or structured details for blocked operations
• DeployIfNotExists and Modify can have side effects, ensure the service principal/managed identity used by policy has least‑privilege permissions needed

Modes

Mode determines which resource types a policy evaluates. Key options:

• All
  Evaluates resource groups, subscriptions, and all resource types
• Indexed
  Evaluates only resource types that support tags and location (avoids flagging resources that can’t be tagged)

How policy evaluation works and compliance states

Azure Policy evaluates assigned rules to determine whether resources meet your declared standards. Evaluation happens in two main ways:

• Request‑time evaluation
  Effects like Deny, DenyAction, Append and Modify are evaluated during the resource operation (create/update/delete). These effects can block or alter the incoming request immediately.
• Background evaluation
  Azure Policy also performs periodic scans of resources already in scope to detect existing non‑compliance and update the compliance state. Assignments, scope changes or policy definition updates also trigger evaluation. For remediation‑style effects (DeployIfNotExists, Modify for existing resources) you can create remediation tasks that apply fixes to existing non‑compliant resources.

Key steps in the evaluation flow:

1. Policy assignment and scope define which resources are in scope for evaluation.
2. For each resource, the policy engine checks whether the policy mode and type make the policy applicable.
3. The “if” condition is evaluated against the resource (and any parameters).
4. If the condition matches, the policy effect determines the outcome (audit, deny, modify, remediation, etc.).
5. Results are recorded and surfaced in compliance reports and dashboards.

Compliance states you will see

• Compliant
  The resource complies with the policy rule.
• Non‑compliant
  The resource violates the policy rule and is reported for remediation.
• Not applicable
  The policy does not apply to that resource type or the resource is outside the targeted conditions.
• Not evaluated / Unknown
  The resource has not yet been evaluated (for example immediately after assignment) or the evaluation result is pending.
• Exempted
  If an exemption exists for the resource or assignment, the resource is excluded from compliance evaluation and reported accordingly.

Looking Ahead

In the next post we will move from concepts to practical guidance and cover how to choose between built in and custom policies, common real world use cases, and the typical structure of policy and initiative implementations. You will also learn how to monitor compliance and create actionable reports, plus basic best practices to get started safely including testing, parameterization and remediation patterns. Expect concrete examples and step by step tips you can try in a sandbox or apply directly in your subscriptions.

Sources

• • Azure Policy documentation
  • What is Azure Policy?
  • Effects