This chapter covers Azure Policy, a key governance tool in Microsoft Azure that helps enforce organizational standards and assess compliance at scale. For the AZ-900 exam, Azure Policy falls under Domain 3 (Azure Management and Governance), which carries approximately 15-20% of the total exam weight. Understanding Azure Policy is critical because it is a foundational concept for maintaining control and security in cloud environments, and the exam expects you to differentiate it from similar services like Azure RBAC and Azure Blueprints.
Jump to a section
Imagine you're the CEO of a large company with hundreds of employees. You can't personally watch every decision they make, so you create a rulebook that defines what's allowed and what's not. For example, the rulebook says: 'All purchases over $1,000 must have a second approval' and 'No employee may use unapproved vendors.' When an employee tries to buy something, the system automatically checks the rulebook before the purchase goes through. If it violates a rule, the purchase is blocked or flagged for review. Azure Policy works exactly like this rulebook for your cloud resources. You write policies (rules) that define allowed configurations—like 'Only certain VM sizes are permitted' or 'All storage accounts must use encryption.' When someone tries to create or update a resource, Azure Policy evaluates the request against your rules. If it violates a policy, the action can be denied (enforced) or simply reported as non-compliant. The key mechanism: policies are applied at a scope (management group, subscription, or resource group) and automatically inherited by all child resources. Just like your company rulebook applies to all departments, Azure Policy ensures consistent governance across your entire Azure environment without manual checks.
What is Azure Policy and the Business Problem It Solves
Azure Policy is a service in Azure that allows you to create, assign, and manage policies that enforce rules for your resources. The core business problem it solves is the need for consistent governance across a growing cloud estate. Imagine a company with hundreds of subscriptions and thousands of resources. Without automated enforcement, individual teams might accidentally deploy resources that violate security requirements, cost controls, or naming conventions. For example, a developer might spin up a very expensive VM size that blows the budget, or a storage account might be created without encryption, exposing sensitive data. Azure Policy prevents these issues by acting as a guardrail that runs continuously.
How Azure Policy Works – Step by Step Mechanism
Azure Policy works by evaluating your resources against policy definitions. Here's the mechanism:
Define a Policy: You create a policy definition using JSON. The definition includes conditions (e.g., "if resource type equals 'Microsoft.Storage/storageAccounts' and property 'supportsHttpsTrafficOnly' is false") and an effect (e.g., deny, audit, or append).
Assign the Policy: You assign the policy to a scope – a management group, subscription, or resource group. The policy is inherited by all child scopes and resources within that scope.
Evaluation: When a resource is created, updated, or deleted, Azure Policy evaluates it against all assigned policies. It also runs periodic compliance scans (every hour) to check existing resources.
Action: Based on the effect, Azure Policy can deny the request (prevent creation), audit the request (log it for review), append tags, or deploy a remediation task.
Key Components of Azure Policy
- Policy Definition: The rule itself, written in JSON. It specifies the conditions and the effect. For example, a definition might require that all storage accounts use HTTPS only. - Initiative Definition: A collection of policy definitions grouped together for a common goal, like "Enable Monitoring in Azure Security Center." Initiatives simplify assignment because you assign one initiative instead of many individual policies. - Assignment: The process of applying a policy or initiative to a specific scope. You can also exclude specific resources or sub-scopes from the assignment. - Effect: The action taken when a resource is non-compliant. Common effects include: - Deny: Blocks the resource creation or update. - Audit: Creates a warning event in the activity log but allows the resource to be created. - Append: Adds additional fields to the resource during creation (e.g., automatically add a tag). - AuditIfNotExists: Audits resources that do not have a related resource (e.g., audit VMs without backup). - DeployIfNotExists: Deploys a related resource if it is missing (e.g., automatically deploy a Log Analytics agent to a VM). - Policy Parameters: Allow you to reduce the number of policy definitions by making them reusable. For example, a policy that requires a specific tag can have a parameter for the tag name, so you can assign the same definition with different values. - Compliance: Azure Policy shows a compliance dashboard where you can see how many resources are compliant or non-compliant per policy.
Pricing Model
Azure Policy is a free service. There is no cost for creating, assigning, or evaluating policies. However, if you use advanced features like guest configuration (to audit settings inside VMs), there may be costs associated with the underlying resources (e.g., Log Analytics).
Comparison to On-Premises Equivalent
In on-premises environments, governance is typically enforced through manual processes, group policies (Active Directory), or custom scripts. For example, you might have a checklist for deploying servers, but it's easy to miss steps. Azure Policy automates this enforcement at the cloud infrastructure level. It is more powerful than traditional group policies because it works across resource types and can enforce conditions that are specific to Azure (e.g., allowed regions, SKU sizes).
Azure Portal and CLI Touchpoints
Azure Portal:
Navigate to "Policy" in the Azure portal. You can view the dashboard, create definitions, assign policies, and see compliance.
To create a custom policy, go to Definitions > Policy Definition > New.
To assign, go to Assignments > Assign Policy.
Azure CLI:
- Create a policy definition:
az policy definition create --name "require-sql-encryption" --rules policy.json- Assign a policy:
az policy assignment create --name "encryption-assignment" --policy "require-sql-encryption" --scope /subscriptions/12345/resourceGroups/myRGPowerShell:
- Create a policy definition:
New-AzPolicyDefinition -Name "require-sql-encryption" -Policy .\policy.json- Assign a policy:
New-AzPolicyAssignment -Name "encryption-assignment" -PolicyDefinition "require-sql-encryption" -Scope "/subscriptions/12345/resourceGroups/myRG"Concrete Business Scenarios
Scenario 1: Cost Control A company wants to prevent use of expensive VM sizes (e.g., Standard_DSv5). They create a policy that denies any VM creation where the SKU size is not in an allowed list. This ensures that all teams stay within budget.
Scenario 2: Security Compliance A healthcare organization must ensure all storage accounts use encryption at rest. They create an audit policy that flags any storage account without encryption. The compliance dashboard shows non-compliant resources, and the team can remediate them.
Scenario 3: Tagging Governance To track costs by department, a company requires that all resources have a "CostCenter" tag. They create a policy with effect "deny" that blocks creation of any resource without the required tag. This enforces tagging from the start.
Identify Governance Requirements
Before creating policies, you must identify what rules you need. Common requirements include: allowed regions (e.g., only deploy in East US and West Europe), allowed VM SKUs (e.g., only D-series), required tags (e.g., CostCenter, Environment), and security settings (e.g., encryption enabled). Document these requirements and prioritize them based on business impact. For AZ-900, understand that policies are used for governance, not security (though they have security implications).
Create a Policy Definition
Write a policy definition in JSON format. The definition includes: the policy rule (conditions using operators like 'equals', 'like', 'in'), the effect (deny, audit, etc.), and optional parameters. Azure provides many built-in definitions (e.g., 'Allowed locations', 'Require SQL Server encryption'). You can use these directly or create custom ones. In the portal, you can use the Policy Editor to build definitions without writing JSON manually.
Assign the Policy to a Scope
Assign the policy definition to a management group, subscription, or resource group. The scope determines where the policy is enforced. You can also exclude specific sub-scopes (e.g., exclude a resource group for testing). During assignment, you can set parameters (e.g., allowed locations list) and choose whether to enforce the policy or only audit. For AZ-900, remember that policies can be assigned at multiple levels and are inherited.
Review Compliance Results
After assignment, Azure Policy evaluates all existing and new resources. You can view compliance in the portal under 'Policy > Compliance'. The dashboard shows the number of compliant and non-compliant resources per policy. For non-compliant resources, you can see which specific resources failed and why. This step is crucial for auditing and remediation. Azure Policy runs compliance scans automatically every hour.
Remediate Non-Compliant Resources
If a policy has a 'DeployIfNotExists' or 'Modify' effect, you can trigger remediation to automatically fix non-compliant resources. For example, a policy that deploys the Log Analytics agent to VMs can be remediated to install the agent on existing VMs. You initiate remediation from the compliance dashboard. For policies with 'deny' or 'audit' effects, manual changes are needed. Remediation tasks run asynchronously.
Scenario 1: Global Enterprise Enforcing Data Residency A multinational corporation must ensure that all customer data stays within specific geographic boundaries due to GDPR. They create an Azure Policy that restricts the allowed locations for resource creation to only the EU regions (e.g., West Europe, North Europe). This policy is assigned to all subscriptions under a management group. When a developer in the US tries to create a resource in East US, the request is denied with an error message. The team configures the policy with a deny effect to prevent any accidental deployment outside the EU. The compliance dashboard shows zero non-compliant resources, giving the compliance team confidence. If they had used audit instead, non-compliant resources might exist unnoticed until an audit.
Scenario 2: Startup Managing Cost with Tagging A fast-growing startup uses multiple cloud accounts for different departments. They need to track costs by department and environment (dev, test, prod). They create a policy that requires all resources to have tags 'Department' and 'Environment'. The policy uses the 'deny' effect to block creation of untagged resources. They also create an initiative that includes this tagging policy plus a policy to enforce naming conventions (e.g., all resources start with 'contoso-'). The initiative is assigned to the root management group. When a new employee tries to deploy a VM without tags, the deployment fails, and they receive a clear error message. Over time, the startup saves thousands of dollars by accurately attributing costs.
Scenario 3: Healthcare Provider Enforcing Encryption A hospital uses Azure for patient records and must comply with HIPAA. They create policies that require encryption at rest for all storage accounts and SQL databases. They use the 'audit' effect initially to discover existing non-compliant resources. The compliance report shows 20 storage accounts without encryption. The team then enables encryption on those accounts manually. After remediation, they change the policy effect to 'deny' to prevent future non-compliance. They also use a 'DeployIfNotExists' policy to automatically enable encryption on new storage accounts. This layered approach ensures continuous compliance.
What goes wrong when set up incorrectly: If policies are too restrictive, they can block legitimate deployments, causing developer frustration. If policies are not assigned to the correct scope, some resources might be missed. If the effect is set to 'audit' instead of 'deny', non-compliant resources can be created and forgotten. Also, complex policies with many conditions can slow down deployment evaluation.
AZ-900 Objective 3.2: Describe the benefits and usage of Azure Policy
The exam tests your understanding of what Azure Policy is, its purpose, and how it differs from similar services. Key points:
Primary purpose: Azure Policy is for governance and compliance, not security (though it can improve security). It enforces rules across resources.
Scope: Policies are assigned to management groups, subscriptions, or resource groups. They are inherited by child resources.
Effects: Know the difference between 'deny' (blocks creation), 'audit' (logs but allows), 'append' (adds properties), 'DeployIfNotExists' (deploys missing resources). The exam may ask which effect to use for a given scenario.
Built-in vs custom: Azure provides many built-in policy definitions (e.g., 'Allowed locations', 'Require tags on resources'). You can also create custom definitions.
Initiatives: A group of policies; helps manage multiple policies together.
Common Wrong Answers and Why Candidates Choose Them
Confusing Azure Policy with Azure RBAC: RBAC controls *who* can do what (permissions). Policy controls *what* resources are allowed (configuration). Candidates often choose RBAC when the question is about enforcing resource settings.
Confusing Azure Policy with Azure Blueprints: Blueprints are a packaging tool that includes policies, role assignments, and resource templates. Policy is just one component. Candidates might think Blueprints and Policy are the same.
Thinking policies are applied to individual resources: Policies are assigned to scopes, not individual resources. Candidates might think you assign a policy to a specific VM.
Believing policies automatically fix non-compliant resources: Only policies with 'DeployIfNotExists' or 'Modify' effects can auto-remediate. Most policies only audit or deny.
Specific Terms and Values on Exam
'Allowed locations' built-in policy definition.
'Require specified tag' built-in policy definition.
'Deny' effect for blocking non-compliant resources.
'Audit' effect for logging non-compliance.
'Policy assignment' at management group, subscription, or resource group scope.
'Initiative' (also called policy set).
Edge Cases and Tricky Distinctions
A policy assigned at a management group affects all subscriptions under it. If you assign a policy at a subscription, it does not affect other subscriptions.
You can exclude specific sub-scopes from a policy assignment using the 'Exclusion' option.
Policy evaluation happens during resource creation and periodically (every hour). The exam may ask about evaluation frequency.
Policies can be used with Azure Resource Graph to query compliance data.
Memory Trick: "Policy = Rules for Resources" (like a rulebook). RBAC = "Roles for Users" (like a job description). Blueprints = "Blueprint for Environment" (like a house plan).
Azure Policy is a governance tool that enforces rules on resource configurations, not access control.
Policies are assigned to scopes (management groups, subscriptions, resource groups) and are inherited by child resources.
Common effects: Deny (blocks non-compliant resources), Audit (logs but allows), Append (adds properties), DeployIfNotExists (deploys missing resources).
Azure Policy is free; no additional cost for using the service.
Built-in policy definitions include 'Allowed locations', 'Require tags on resources', and 'Audit VMs without managed disks'.
Initiatives group multiple policies together for easier management (e.g., 'Enable Monitoring in Azure Security Center').
Policy evaluation occurs during resource creation/update and every hour for existing resources.
Azure Policy is different from RBAC: Policy controls what resources are allowed; RBAC controls who can do what.
Remediation tasks can auto-fix non-compliant resources for policies with 'DeployIfNotExists' or 'Modify' effects.
Azure Blueprints can include Azure Policy assignments as part of a packaged environment, but they are separate services.
These come up on the exam all the time. Here's how to tell them apart.
Azure Policy
Enforces rules on resource configuration (e.g., must have encryption).
Uses policy definitions with conditions and effects (deny, audit, etc.).
Assigned to scopes (management groups, subscriptions, resource groups).
Evaluates resources for compliance continuously.
Free service.
Azure RBAC
Controls who can perform actions on resources (e.g., who can create VMs).
Uses role definitions with permissions (e.g., Contributor, Reader).
Assigned to users, groups, or service principals at a scope.
Evaluates authorization at the time of action.
Free service (no additional cost for RBAC).
Azure Policy
Focuses on enforcing rules for existing and new resources.
Can be used independently without Blueprints.
Provides compliance dashboard.
Policies are standalone or grouped into initiatives.
No versioning or artifact management.
Azure Blueprints
Focuses on deploying a complete environment with templates, policies, and roles.
Always includes policy assignments as part of the blueprint.
Blueprints are versioned and can be updated.
Blueprints package multiple artifacts (policies, RBAC, ARM templates).
Used for repeatable, compliant environments.
Mistake
Azure Policy controls who can access resources (permissions).
Correct
Azure Policy does not control access. It controls the configuration and properties of resources. Access control is handled by Azure RBAC (Role-Based Access Control). Policy ensures resources comply with rules, while RBAC ensures only authorized users can perform actions.
Mistake
Azure Policy can automatically fix any non-compliant resource.
Correct
Only policies with the 'DeployIfNotExists' or 'Modify' effect can automatically remediate non-compliant resources. Policies with 'deny' or 'audit' effects require manual action or separate remediation tasks. For example, a policy that denies unencrypted storage accounts does not auto-encrypt existing ones.
Mistake
Azure Policy is the same as Azure Blueprints.
Correct
Azure Blueprints is a higher-level service that packages together Azure Policy, role assignments, and ARM templates to create a repeatable environment. Azure Policy is a component within Blueprints. Blueprints are for deploying complete environments, while Policy is for ongoing governance.
Mistake
Policies are applied to individual resources directly.
Correct
Policies are assigned to scopes (management groups, subscriptions, resource groups) and affect all resources within that scope. You cannot assign a policy to a single resource; instead, you assign at a scope and the policy evaluates all resources in that scope.
Mistake
Azure Policy only works for new resources, not existing ones.
Correct
Azure Policy evaluates both new and existing resources. When you assign a policy, it immediately scans existing resources for compliance. It also continues to evaluate new resources as they are created or updated. Compliance scans run every hour.
Azure Policy enforces rules on resource configuration (e.g., 'all storage accounts must use HTTPS'), while Azure RBAC controls who can perform actions (e.g., who can create or delete resources). Policy is about 'what is allowed' in terms of settings; RBAC is about 'who is allowed' to do operations. They are complementary: you use RBAC to grant permissions and Policy to enforce standards. For AZ-900, remember that Policy deals with resource properties, not user permissions.
Yes, but only for policies with the 'DeployIfNotExists' or 'Modify' effect. For example, a policy that requires the Log Analytics agent on VMs can use 'DeployIfNotExists' to automatically install the agent on VMs that don't have it. For policies with 'deny' or 'audit', you must fix non-compliant resources manually or use a separate remediation task. On the exam, know that not all policies auto-remediate.
Azure Policy can be assigned to management groups, subscriptions, and resource groups. When assigned to a management group, the policy applies to all subscriptions and resource groups under that management group. You can also exclude specific sub-scopes from the assignment. The exam may ask which scope is appropriate for a given scenario (e.g., assign at the management group to enforce across the organization).
Yes, Azure Policy is a free service. There is no charge for creating, assigning, or evaluating policies. However, if you use features like guest configuration (which audits settings inside VMs), you may incur costs for the underlying resources such as Log Analytics data ingestion. For the exam, remember that the policy service itself is free.
An initiative (also called a policy set) is a collection of policy definitions that are grouped together to achieve a specific goal. For example, the 'Enable Monitoring in Azure Security Center' initiative includes policies for enabling diagnostics, agent installation, etc. Initiatives simplify management because you assign one initiative instead of many individual policies. On the exam, know that initiatives are used to group related policies.
Azure Policy evaluates resources during resource creation, update, or delete operations (real-time). It also runs a full compliance scan every hour to check existing resources. The compliance dashboard updates after each scan. The exam may ask about the evaluation frequency, so remember the hourly scan.
Yes, you can create custom policy definitions using JSON. Azure also provides many built-in definitions that cover common scenarios like allowed locations, required tags, and encryption settings. For the exam, know that both built-in and custom policies are available, and you can use the Azure portal, CLI, or PowerShell to create them.
You've just covered Azure Policy — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?