Azure Policy¶

Azure Policy helps you manage and enforce organizational standards and assess compliance at-scale. It allows you to create, assign, and manage policies that enforce different rules and effects over your resources, ensuring they stay compliant with your corporate standards.

Policy Structure and Assignment¶

Hierarchy and Inheritance¶

Azure Policy assignments follow the management group hierarchy.

A policy assigned at the root management group automatically applies to all child management groups, subscriptions, resource groups, and resources.
This inheritance ensures consistent governance across the entire tenant, much like RBAC permissions.

Example:
If you assign a policy at the root to restrict deployments to West Europe, that rule flows down to every subscription and resource group beneath it. Any new subscriptions added under the root will also inherit the policy automatically.

Blocking or Adjusting Inheritance¶

Sometimes you need exceptions — for example, a Dev management group where engineers can experiment more freely. There are two main ways to handle this:

Exclusions at Assignment Time
- When creating the root assignment, you can specify a notScopes property.
- This excludes a management group, subscription, or resource group from the inherited policy.
- Example: Exclude the Dev-MG management group from the root assignment so policies don’t apply there.
Exemptions
- At a lower scope, you can create an exemption for specific resources or scenarios.
- Exemptions mark resources as out of scope for compliance evaluation, while still keeping visibility in reports.
- Useful for temporary or case‑by‑case exceptions.

Practical Flow¶

Assign at Root → Policy cascades down to all children.
Exclude Dev-MG → Add notScopes for the Dev management group.
Fine‑tune with Exemptions → Allow specific resources or projects to bypass compliance checks while still tracking them.

Policy Definition¶

A policy definition is a rule that enforces or audits a condition in Azure.
- Example: Require all storage accounts to have secure transfer enabled.
- Common effects: Deny, Audit, Append, DeployIfNotExists.

Policy Set (Initiative Definition)¶

An initiative (policy set) groups multiple policy definitions into a single package.
- Simplifies management by applying related policies together.
- Example: A “Security Baseline” initiative might include policies for encryption, networking, and monitoring.

Assignment¶

A policy assignment applies a definition or initiative to a chosen scope.
- Scope can be a management group, subscription, resource group, or individual resource.
- Assignments can include exclusions to carve out exceptions.

Scope and Exclusions¶

Scope defines where a policy applies (management group → subscription → resource group → resource).
Exclusions allow you to exempt specific resources without removing the assignment.

Evaluation and Compliance¶

Azure Policy continuously evaluates resources against assigned policies.
The compliance dashboard shows compliant vs. non‑compliant resources and highlights risks.

Effect¶

The effect defines what happens when a resource does not meet policy conditions.

Effect	What it Does	Typical Use Case
Append	Adds extra fields/settings during resource creation/update.	Enforce allowed IP ranges on a storage account.
Audit	Logs a warning for non‑compliance but allows the request.	Track resources missing encryption without blocking deployment.
AuditIfNotExists	Audits related resources if required settings are missing.	Ensure VMs have monitoring agents installed.
Deny	Blocks the request if it doesn’t meet standards.	Prevent creation of resources in unapproved regions.
DeployIfNotExists	Deploys a required resource/config if missing. Requires a managed identity.	Add diagnostic settings when absent.
Disabled	Turns off the effect for testing or flexible assignments.	Pause enforcement without removing the policy.
Modify	Updates, adds, or removes properties/tags during creation/update. Can remediate existing resources. Requires a managed identity.	Standardize costCenter tags across resources.

Remediation and Exemptions¶

Remediation tasks can automatically fix non‑compliant resources (e.g., apply missing tags, enable monitoring).
Exemptions let you exclude specific resources or scenarios while maintaining overall compliance visibility.

Parameters¶

Parameters make policies flexible and reusable.
- Instead of hardcoding values, you provide them at assignment time.
- Example: “Allowed locations” can be parameterized so the same policy works across different regions.

Policy Definition – In Detail¶

A policy definition describes the rules and effects that Azure Policy enforces.
It defines what to check and what to do when conditions are met.

Structure¶

A policy definition is made up of these elements:

displayName – Friendly name for the policy.
description – Short explanation of purpose.
mode – Determines which resource types are evaluated.
metadata – Optional organizational details (version, category, etc.).
parameters – Values that make the policy reusable and flexible.
policyRule – The logic (if conditions) and the action (then effect).

Display Name & Description¶

Used to identify the policy and provide context.
- displayName: max 128 characters
- description: max 512 characters

"displayName": "Require secure transfer on storage accounts",
"description": "Ensures all storage accounts enforce secure transfer."

Mode¶

Defines the evaluation scope:

All – Evaluates all resource types.
Indexed – Evaluates only indexed resource types (most common).
Resource Provider – Targets specific resource providers.

"mode": "Indexed"

Metadata¶

Optional, but useful for classification and lifecycle management.

version: Track policy version.
category: Organize policies in the portal.
preview: Flag if the policy is in preview.
deprecated: Flag if the policy is deprecated.
portalReview: Force parameter review in the portal.

"metadata": {
  "version": "1.0.0",
  "category": "Security"
}

Parameters¶

Make policies reusable by defining values at assignment time.

Key properties:

type: string, array, object, boolean, integer, float, datetime
metadata: description, displayName, strongType (portal hints)
defaultValue: fallback if no value is provided
allowedValues: restrict inputs to valid options
schema: validate object‑type parameters

"parameters": {
  "allowedLocations": {
    "type": "array",
    "metadata": {
      "description": "List of allowed locations for resources.",
      "displayName": "Allowed locations",
      "strongType": "location"
    },
    "defaultValue": [ "westus2" ],
    "allowedValues": [ "eastus2", "westus2", "westus" ]
  }
}

Policy Rule¶

Defines the logic and effect.

If: condition(s) to evaluate.
Then: effect to apply (e.g., Deny, Audit, Modify).

"policyRule": {
  "if": {
    "field": "location",
    "notIn": "[parameters('allowedLocations')]"
  },
  "then": {
    "effect": "Deny"
  }
}