Academmia

Azure Policy

az-900•mixed•

Management and governance

Azure Policy

Short Summary

In this lesson, you’ll learn what Azure Policy is and why it’s used for governance and compliance in Azure. You’ll see how policy scope and assignments determine where rules apply, and how compliance is evaluated. You’ll also learn how Azure Policy differs from Azure role-based access control (RBAC).

Learning Objectives

By the end of this lesson, you will be able to:

  • Define Azure Policy and describe what it’s used for.
  • Differentiate Azure Policy from Azure role-based access control (RBAC).
  • Describe policy definition, assignment, scope, and compliance in simple terms.
  • Explain how common policy effects (like Audit and Deny) change what happens.
  • Use a policy initiative (policy set) to manage multiple related rules together.

Core Concepts

Azure Policy is a governance service that helps you enforce standards and assess compliance across Azure resources. It’s commonly used for rules such as:

  • Allowed regions (locations)
  • Required tags (for cost and ownership reporting)
  • Approved sizes/tiers (Stock Keeping Unit (SKU) restrictions)
  • Required configurations (for example, diagnostic settings)

A useful mental model:

  • Azure Policy = what is allowed/required for resources
  • Azure role-based access control (RBAC) = who can do what

Even if a person has RBAC permission to create a resource, Azure Policy can still block or flag the deployment if it would be non-compliant.

The main building blocks

Azure Policy works through a few core pieces:

  • Policy definition: the rule written in JSON (JavaScript Object Notation (JSON)) that describes conditions and an effect (what happens when the rule matches).
  • Policy assignment: applying a definition (or initiative) to a scope so Azure evaluates it.
  • Scope: where the assignment applies (management group, subscription, resource group, or an individual resource). Scopes can also exclude sub-scopes when needed.
  • Compliance: the evaluation result showing which resources meet the rule and which do not.

A definition by itself does nothing until you assign it.

Policy effects: audit, deny, and more

A policy’s effect determines the behavior when the rule matches. For AZ-900, you mainly need to recognize that Azure Policy can be used to:

  • Audit: report non-compliance (visibility).
  • Deny: block non-compliant create/update requests (prevention).
  • Remediate: help bring resources into compliance (for example, by modifying or deploying settings/resources when supported).

So, Azure Policy doesn’t always block—the effect controls whether you’re “seeing,” “stopping,” or “fixing” non-compliance.

Initiatives (policy sets)

A policy initiative (also called a policy set) is a collection of policy definitions managed as a single unit. You use initiatives to apply a “bundle” of governance rules (for example, tags + allowed regions + approved SKUs) with one assignment.

Practical Understanding

Practical Situation 1: “We can only deploy in certain regions”

A company has data residency requirements and wants resources deployed only in specific Azure regions (for example, West Europe). They want it enforced consistently across a subscription (or many subscriptions).

How to think about it: This is a “what is allowed” rule, so Azure Policy is the right tool. Assign the policy at the right scope (subscription, or higher) so it covers the intended resources. If the goal is prevention, use a Deny effect.

Common misunderstanding: “RBAC can restrict regions.” RBAC controls permissions for people/services; it doesn’t enforce configuration rules like allowed locations.

Practical Situation 2: “Every resource must have tags for cost reporting”

A company requires tags like CostCenter and Environment on every resource so reporting stays reliable. They want this applied across many subscriptions.

How to think about it: Use Azure Policy to require (or add) tags, and assign it at a scope that matches the organization’s structure (often a management group to cover multiple subscriptions).

Common misunderstanding: “Creating the policy definition is enough.” A definition doesn’t take effect until it’s assigned.

Practical Situation 3: “Only approved Virtual Machine sizes are allowed”

A company wants to prevent teams from deploying non-approved Virtual Machine (VM) sizes (SKUs). They want the platform to stop the deployment before the VM exists.

How to think about it: Use Azure Policy to express the allowed SKUs rule, and use a Deny effect if the goal is to block non-compliant deployments. If you’re unsure about impact, start with Audit first, then tighten to Deny later.

Common misunderstanding: “Azure Policy only reports problems.” Some policies only audit, but others can deny or support remediation—behavior depends on the effect.

Practical Situation 4: “We have many governance rules, but want one ‘bundle’”

A company needs to enforce several related standards at once (tags + allowed regions + approved SKUs) and wants to manage them as one assignment.

How to think about it: Use a policy initiative (policy set) to group multiple policy definitions into one unit. Then assign the initiative at the right scope.

Common misunderstanding: “Policies must always be assigned one by one.” Initiatives exist specifically to reduce the number of separate assignments you manage.

Common Pitfalls

  • Mistake: Treating Azure Policy like an access-control tool. Correction: Use RBAC for “who can do what”; use Azure Policy for “what is allowed/required for resources.”

  • Mistake: Assuming a policy definition enforces anything by itself. Correction: A definition must be assigned to a scope before it can evaluate or enforce compliance.

  • Mistake: Assuming policies apply everywhere automatically. Correction: Azure Policy only evaluates resources within the scope of the assignment (and any included sub-scopes).

  • Mistake: Believing Azure Policy always blocks non-compliant deployments. Correction: The effect decides the behavior—Audit reports, Deny blocks, and some effects support remediation.

  • Mistake: Managing every governance rule as a separate assignment. Correction: Use initiatives (policy sets) to bundle related policies and assign them together.

  • Mistake: Expecting Azure Policy to replace all security/compliance tools. Correction: Azure Policy is one governance layer; combine it with RBAC and other security services as needed.

Check Your Understanding

  1. In one sentence, explain the difference between Azure Policy and Azure role-based access control (RBAC).
  2. Pick one governance rule (tags, regions, VM sizes). Which scope would you assign it to, and why?
  3. Describe a situation where you would start with an Audit effect before moving to a Deny effect.
  4. Explain what changes when you create a policy definition vs when you assign a policy.
  5. List three rules you’d bundle into one initiative, and explain why bundling helps.

Further Reading