Azure Policy

Azure Policy is a governance service that allows you to define, assign, and manage rules — called policy definitions — that control or audit the configuration of Azure resources. Unlike RBAC, which controls who can take actions, Azure Policy controls what the resulting resource configuration is allowed to be. You use it to enforce organisational standards like naming conventions, approved resource types, and required security configurations.

A policy definition is a JSON document that defines a condition to evaluate against a resource and an effect to apply when the condition is met. Azure provides hundreds of built-in policy definitions covering common scenarios. You can also create custom policy definitions when built-in policies do not match your requirement. Policy definitions are reusable objects that must be assigned to a scope before they take effect.

The effect in a policy definition determines what happens when the policy condition is triggered. Key effects include: Deny — blocks the resource creation or update that violates the policy; Audit — allows the action but logs a warning in the compliance report; Append — adds required fields (like tags) to a resource before creation; Modify — changes a property on existing or new resources; DeployIfNotExists — deploys a related resource if a condition is not met (e.g., deploying a diagnostics extension to every VM).

A policy assignment applies a policy definition to a specific scope: management group, subscription, or resource group. All resources within that scope (and child scopes) are evaluated against the assigned policy. Assignments can include parameters — for example, a policy that restricts allowed Azure regions can be parameterised so the same definition is assigned with different region lists in different management groups.

An initiative definition (also called a policy set) groups multiple related policy definitions into a single assignable package. Instead of assigning 20 individual policies, you assign one initiative. Azure provides built-in initiatives for compliance frameworks like ISO 27001, NIST SP 800-53, Azure Security Benchmark, and PCI DSS. Assigning the CIS Microsoft Azure Foundations Benchmark initiative, for example, evaluates your subscription against over 180 security controls simultaneously.

After assigning a policy, Azure evaluates all existing resources in the scope and generates a compliance report. The report shows the overall compliance percentage (compliant resources / total resources), the compliance state of each resource, and which specific policy conditions failed. You can filter by policy initiative, scope, or resource type. Non-compliant resources are listed with the exact policy rule they violated, guiding remediation.

For policies with the DeployIfNotExists or Modify effect, Azure can create remediation tasks to bring existing non-compliant resources into compliance. For example, a DeployIfNotExists policy that deploys a Log Analytics agent to every VM can have a remediation task triggered to install the agent on all existing VMs that currently lack it. New resources are automatically remediated at creation; existing resources need an explicit remediation task.

Sometimes specific resources legitimately need to be excluded from a policy — a legacy resource that cannot be modified, or an approved exception documented in a change request. Policy exemptions allow you to exclude a specific resource or resource group from a policy assignment without removing the policy globally. Exemptions have an optional expiry date and a category (Waiver or Mitigated) to document the reason for the exception.

DeployIfNotExists is one of the most powerful policy effects. When a resource is created without a required related resource (e.g., a VM without a diagnostic extension), the policy automatically triggers an ARM template deployment to add the missing component. This enables Azure Policy to become an automatic configuration management tool — ensuring every VM always has monitoring agents, every storage account always has advanced threat protection, and every SQL Database always has auditing enabled.

Organisations use Azure Policy for many governance scenarios. Location restrictions — only allow resources in approved Azure regions for data sovereignty. Allowed resource types — prevent deployment of expensive or unapproved services. Tag enforcement — require CostCentre and Environment tags on all resources. SKU restrictions — limit VM sizes to cost-appropriate tiers in non-production subscriptions. Security baselines — enforce TLS 1.2 minimum, disable public network access on storage accounts, and require private endpoints.

It is important to understand the different roles of RBAC and Azure Policy. RBAC controls who can perform operations — it grants or denies actions based on identity. Azure Policy controls what the resource configuration must be — it evaluates and enforces properties regardless of who performs the action. Both are needed in a well-governed environment: RBAC ensures only authorised people deploy resources, and Azure Policy ensures those resources comply with configuration standards.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure Policy defines conditions and effects to control resource configuration at any scope, initiative definitions bundle multiple policies into a single assignable compliance package, and DeployIfNotExists enables automatic configuration enforcement for missing components at scale. Next up we explore resource tags and resource locks for protecting Azure resources.