Azure Policy – A basic introduction

Introduction

Many organizations find that their cloud environment becomes increasingly difficult to manage as more teams gain access to create and configure resources.

Without clear guidelines and automated enforcement, this can lead to security risks, unpredictable costs, and operational challenges. In this article, we'll look at Azure Policy – a built-in governance tool that can help you regain control.

The goal is to provide you with a practical introduction to what Azure Policy is, how it works, and most importantly – whether it's the right tool for your organization.

We'll cover the key concepts, advantages and disadvantages, as well as concrete examples of how policies affect both new and existing resources.

After reading this article, you should be able to assess whether Azure Policy can solve your governance challenges and have a good understanding of what implementation entails.

What is Azure Policy?

Azure Policy is a powerful governance tool that is built into all Azure Tenants.

With Azure Policy, you can ensure that all resources in your cloud follow your organization's requirements for configuration, security, and compliance.

Who needs Azure Policy?

Azure Policy is essential if you:

• Have multiple development teams creating resources and need consistent standards - without slowing down innovation.

• Want to ensure proper tagging for all resources so costs can be tracked but can't rely on everyone remembering this manually.

• Must document compliance with regulations (security logging, encryption, data retention) for auditors or regulatory authorities.

• See "creative" exceptions and workarounds that break standards due to lack of enforcement.

• Want to avoid operational surprises, such as accidental deletion of critical resources, public exposure of services, or forgotten backups.

Need real-time oversight of compliance and a way to follow up on deviations across the entire platform.

Examples:

• Centralized logging: Enforce and monitor that all resources forward logs to a central logging solution automatically.

• Tagging and cost control: Prevent creation of resources without proper tags, or alert when tags are missing.

• Protection against accidental changes: Prevent critical components from being deleted or changed by mistake -- even when users have high autonomy.

• Regulatory compliance: Monitor and enforce encryption, backups, regional placement, network configuration, etc.

Azure Policy: Pros and cons

Pros:

• Available out of the box: Built into all Azure tenants -- no additional installation required.

• Scales incredibly well: Enforce requirements across the entire organization, regardless of number of resources or teams.

• Free to use: No additional license cost for the policy engine.

• Works regardless of how you deploy and configure resources: Applies whether resources are deployed and configured with ARM, Bicep, Terraform, Azure Portal, or CLI.

• Provides a bird's eye view: See compliance across all resources in your tenant.

• Detailed insights: Drill down to landing zone, resource group, or individual resource for detailed control.

• Auditing, enforcement, and automation: Use policy to audit, enforce, or even automatically remediate issues.

• Enables massive remediation across entire tenant: Correct large-scale deviations in one step, without changing all pipelines or templates.

Cons:

• Complex to set up and understand: Writing effective policies and understanding their impact can be challenging.

• Risk of disruptions from misconfiguration: Misconfigured policies can block critical deployments or changes, causing downtime, delays, and frustration.

• Can conflict with declarative code (like Terraform): Policy-driven changes can cause state drift.

• Operational cost: Azure Policy requires ongoing maintenance, updates, and development as cloud environments and requirements evolve. There are no direct costs associated with Azure Policy itself, but it's important to allocate time and resources to actively maintain it.

Everything goes through ARM API

Regardless of how you create or modify resources in Azure -- whether through the portal, Azure CLI, PowerShell, Terraform, Bicep, or other tools -- everything ends up as a request to the Azure Resource Manager (ARM) API.

This is the API that "controls" all resources in Azure.

• Azure Policy is an integrated part of the ARM API and evaluates all requests that go through it.

• This ensures that your rules apply regardless of which tool or method you use.

Why is this important to you?

This means you get consistent policy enforcement across all tools and methods. Teams can freely choose their preferred work tools – the portal, CLI, Terraform, or other solutions – without affecting how policies are evaluated. You don't need to worry about standards being accidentally bypassed through different workflows and can trust that the rules apply equally to everyone, regardless of technical approach.

What does Azure Policy cover - and what doesn't it cover?

Azure Policy only applies to Azure resources and resource containers, that means everything managed via the ARM API: virtual machines, storage, networks, subscriptions, resource groups, and even role assignments (RBAC) that are linked to resources.

Azure Policy does not, however, apply to identities, users, and groups in Entra ID (formerly Azure AD).

Everything handled via the Microsoft Graph API -- such as users, groups, roles, and administrative rights in Entra -- is not covered by Azure Policy.

Why is this distinction important to understand?

This affects how you design your overall governance architecture. For resource-related governance (security configuration, tagging, regional placement), Azure Policy is the right tool.

But for user and identity governance (who gets access to what, administrative roles, user lifecycle), you need to use other tools like Conditional Access, Privileged Identity Management, or Identity Governance (identity security). Understanding this distinction helps you choose the right tool for the right purpose.

Example:

• A role assignment on a storage account can be evaluated by Azure Policy

• An administrator role for a user in Entra ID cannot be evaluated by Azure Policy

Policy evaluation and compliance

When you make a change to a resource, the following sequence occurs:

1. Authentication - Validate the user's identity

2. Authorization - Does the user have sufficient rights to perform the change?

3. Policy evaluation - Is the action allowed according to applicable policies?

Policies have different effects, the most commonly used are:

• Deny: Block the action

• Audit: Log deviations

• Append/Modify: Add or change properties

• DeployIfNotExists: Create or configure missing resource

• AuditIfNotExists: Log deviation if a given resource does NOT exist

Why is it important to understand this?

When implementing Azure Policy, you need to understand that policies are evaluated every time someone tries to make changes - not just when you deploy them for the first time.

This affects user experience and can potentially block critical work if you haven't planned well enough. By understanding the different effects, you can choose the right approach: strict enforcement where it's critical or just logging where you need visibility first.

In addition to being evaluated when a request comes to the ARM API, Azure Policy runs compliance scanning daily and can also be triggered manually.

This ensures you always have oversight of whether resources comply with policies:

Policy structure: Policy, Initiative, Assignment, Exemption

Azure Policy consists of four main elements:

1. Policy Definition – A single rule written in JSON (e.g., "All storage accounts must be encrypted")
2. Initiative Definition – A collection of multiple policies, gathered under one purpose (e.g., "Storage Baseline")
3. Assignment – The actual assignment: policy or initiative activated at a chosen scope level
4. Exemption – Exception from policy or initiative for specific resources

This provides flexible and structured governance, from single rules to comprehensive collections covering entire areas (e.g., security requirements for all storage).

Inheritance and management

• Policy assignments are inherited down the hierarchy: If you set a policy at the management group level, it automatically applies to all subscriptions and resource groups below.

• This makes it possible to set broad, business-critical requirements once -- and be sure they apply everywhere, regardless of local permissions.

• Best practice: Use management groups for broad “guardrails," and detailed policies further down only where necessary.

• Teams and owners get flexibility but can never bypass policies assigned at a parent scope.

Why is this structure important?

The division allows you to scale governance in a manageable way. Instead of administering hundreds of individual policy assignments, you can group related rules into initiatives and assign entire packages at once.

Assignments let you control where rules apply (entire organization vs. specific teams), while exemptions give you a controlled way to handle legitimate exceptions without undermining the entire governance model.

Particularly important: When you assign policies at the management group level, even subscription owners cannot override them. This makes it possible to give teams great autonomy within clear, non-negotiable guardrails.

Pricing and cost control

Azure Policy is a built-in and free feature in Azure - it costs nothing to define, assign, or evaluate policies. In other words, you can use Azure Policy across your entire environment without direct costs. However, it's important to be aware that certain policy actions can trigger indirect costs, depending on what the policies do:

• Example without cost:

  A policy that requires all storage accounts to have TLS 1.2 enabled and denies use of SAS keys will not incur additional expenses, regardless of how many resources you have.

• Examples with indirect cost:

  A policy that automatically sets up diagnostic settings on all storage accounts will lead to costs related to log collection and storage, based on the amount of data sent to, for example, Log Analytics or an Event Hub.

• Automatic resource creation:

  Policies that automatically create new resources (for example via DeployIfNotExists) will trigger the usual costs for using the resources that are created. It's therefore wise to consider the consequences of policies, especially in large environments, so you have control over any costs that may arise indirectly through policy actions.

Policy effects: How does this affect new and existing resources?

Why is it important to understand this?

When implementing Azure Policy, you need to know exactly what impact it has on your environment.

Many are surprised that existing "non-compliant" resources still function or confused about why some changes are blocked while others go through. Understanding these mechanisms helps you predict the user experience and plan implementation correctly.

Example: When you use a policy with the Deny effect, Azure Policy will block creation of new resources that don't meet your requirements.

For existing resources that are not compliant ("noncompliant"), the policy will not delete or automatically change them. These will instead appear as noncompliant in compliance reporting.

What happens if someone tries to change an existing resource that is not compliant?

If the change doesn't make the resource meet policy requirements, the action will be blocked.

Example with DENY policy

If you have a policy that says "All storage accounts must have TLS 1.2," you cannot create a new storage account without TLS 1.2.

If an older storage account still uses TLS 1.1, it will appear as noncompliant:

Let's try to make a change to this resource that is unrelated to TLS version:

This will fail because we are effectively sending a request to the API where we still have TLS 1.1 defined:

Let's try to make the same change, but simultaneously update the TLS version to be compliant with policy requirements:

This works because the request to the API now specifies TLS 1.2 and is compliant:

However - there are some nuances here:

In Azure, a "resource" in the portal often consists of multiple interconnected parts. Some of these parts are called extension resources -- for example, role assignments, diagnostic settings, blobs, queues, and tables. These are separate resources that belongs to a main resource, like a storage account.

• Important:
  The policy usually applies to the main resource, not extension resources. This means that even if a storage account is noncompliant, you can often still add or change extension resources (for example, add a role or change diagnostic settings), because this is technically a change to a "sub-part," not the main resource itself.

This can be confusing in the portal because you see everything as "one resource," but in fact there are several different objects behind the scenes that have a relationship with each other.

When working with infrastructure as code (for example, Bicep or Terraform), this distinction is somewhat clearer, but it's still easy to get confused.

In short:

• You cannot create or modify main resources so they violate the policy (Deny).

• Existing resources that don't follow the policy are not deleted but cannot be changed (without becoming compliant).

• Changes to extension resources can often still be performed, even if the main resource is noncompliant.

This is an important point to understand when working with Azure Policy, especially if you get unexpected error messages or see that some changes are still possible on noncompliant resources.

Summary

• Azure Policy gives you full control over how resources are used and configured in Azure.

• Everything goes through the ARM API, and policies are always evaluated -- regardless of tools used to make changes in Azure.

• Policy only applies to Azure resources (not Entra ID) and evaluates both during operations and in daily compliance scans.

• Policy assignments are inherited downward, provide holistic governance, and let you set "rules of the game" for the entire organization.

• The structure with policy, initiative, assignment, and exemption provides flexible, scalable, and practical governance.