This chapter covers Azure Policy and Initiatives, a core governance mechanism in Azure that enforces organizational standards and assesses compliance across resources. For the AZ-104 exam, this topic appears in approximately 15-20% of questions, primarily in the 'Manage Azure identities and governance' domain (objective 1.2). Mastering Azure Policy is essential because it directly impacts how administrators enforce security, cost, and naming conventions at scale. We'll dissect how policies work internally, how to create and assign them, and how to interpret compliance results—all through the lens of what the exam actually tests.
Jump to a section
Imagine a large construction project with hundreds of subcontractors. The city building code inspector doesn't build anything—they don't pour concrete or run wiring. Instead, they inspect each component against the published building code before it's approved. The building code is a set of rules: 'All exterior doors must be fire-rated for 20 minutes,' 'Electrical outlets in bathrooms must be GFCI-protected.' The inspector doesn't fix violations; they reject non-compliant work and require remediation before the project can proceed. Crucially, the inspector can apply different codes to different parts of the building—the commercial kitchen has stricter fire suppression rules than the lobby. The inspector also has an enforcement toolkit: they can issue a stop-work order (deny assignment), flag a violation for later correction (audit), or exempt certain areas (exclusions). Azure Policy works exactly the same way. The 'building code' is the policy definition—a JSON rule that checks resources for compliance. The 'inspector' is the Azure Policy service, which evaluates resources against definitions at specific intervals (every 24 hours by default, or on-demand). When a new resource is deployed, Azure Policy intercepts the request (before provisioning) and checks if it complies. If not, it can deny the deployment (like a stop-work order) or simply mark the resource as non-compliant (like a warning). Policies can be scoped to management groups, subscriptions, or resource groups—just as building codes vary by zone. The 'enforcement toolkit' includes parameters (to customize rules), effects (Deny, Audit, Append, etc.), and exemptions (to carve out exceptions). Just as a building inspector ensures every contractor follows the same code, Azure Policy enforces organizational standards across all Azure resources.
What is Azure Policy and Why It Exists
Azure Policy is a service in Azure that allows you to create, assign, and manage policies that enforce rules over your resources. Unlike role-based access control (RBAC), which focuses on *who* can do what, Azure Policy focuses on *what* resources are allowed or disallowed. It's a governance tool that ensures resources comply with your corporate standards and service-level agreements. For example, you can create a policy that restricts the deployment of virtual machines (VMs) to only certain SKUs (e.g., no Dv5-series because they're too expensive), or enforce that all storage accounts must use HTTPS traffic only.
How Azure Policy Works Internally
Azure Policy operates through a combination of policy definitions, assignments, and evaluation. A policy definition is a JSON document that describes the rules and the effect to take when a resource is non-compliant. When you assign a policy to a scope (management group, subscription, resource group), the Azure Policy service starts evaluating resources within that scope against the definition. Evaluation happens in two ways:
On-demand evaluation: Triggered when a resource is created, updated, or deleted. The policy engine checks the resource properties against the conditions in the policy definition. If the resource violates the policy, the engine applies the configured effect (e.g., Deny, Audit, Append).
Periodic evaluation: Azure Policy automatically scans all existing resources in a scope every 24 hours (the default compliance evaluation cycle) to detect drift. This ensures that even if a resource was compliant at creation, changes made later (e.g., someone disables HTTPS on a storage account) are flagged.
The evaluation process uses the Azure Resource Manager (ARM) API. When a resource is submitted via PUT/PATCH/DELETE, ARM calls the Azure Policy engine before provisioning. The engine checks all applicable policy assignments. If any policy has a Deny effect and the resource is non-compliant, ARM rejects the request with an HTTP 403 (Forbidden) status code and an error message indicating which policy blocked it.
Key Components: Policy Definitions, Assignments, and Effects
Policy Definition: A JSON object that includes:
- mode: All (evaluates resource properties) or Indexed (evaluates only tags and location). Default is All.
- policyRule: Contains if (condition) and then (effect).
- parameters: Allows customization without rewriting the definition.
- displayName, description, metadata.
Policy Assignment: Binds a policy definition to a scope. You can exclude specific child scopes (e.g., a resource group within a subscription) using excludedScopes. You can also set enforcement mode: Default (enforced) or DoNotEnforce (evaluation only, no effect applied).
Effects: The action taken when a resource is non-compliant. Common effects:
- Deny: Blocks the resource creation/update. Returns 403.
- Audit: Creates a warning in the activity log but does not block deployment.
- Append: Adds fields to the resource during creation (e.g., tags). Only works on create/update.
- AuditIfNotExists: Audits resources that do not have a required extension or setting.
- DeployIfNotExists: Deploys a template to remediate non-compliant resources (requires managed identity).
- Disabled: Policy is not evaluated.
Policy Initiatives (Policy Sets)
An initiative is a collection of policy definitions grouped to achieve a specific goal. For example, the 'ISO 27001' initiative includes multiple policies for security controls. Assigning an initiative is like assigning all its policies at once. Initiatives can be custom or built-in (Microsoft provides many). Initiatives also support grouping and evaluation as a single unit.
Parameterization and Aliases
Policy definitions can use parameters to make them reusable. For example, a policy that restricts VM SKUs can have a parameter allowedSKUs that you set per assignment. Aliases are property paths in the ARM resource schema that you can use in conditions. For example, Microsoft.Compute/virtualMachines/sku.name is an alias for the VM SKU. You can discover aliases using Azure PowerShell or CLI:
Get-AzPolicyAlias -NamespaceMatch 'Microsoft.Compute'Compliance and Remediation
Compliance state is calculated per resource per policy assignment. States: Compliant, Non-compliant, Conflict (multiple policies disagree), Error, Not started. You can view compliance in the Azure portal under 'Policy' > 'Compliance'.
For policies with DeployIfNotExists or Modify effects, you can trigger remediation tasks. Remediation uses a managed identity to apply changes to non-compliant resources. For example, a policy that deploys a Log Analytics agent on VMs can remediate existing VMs that lack the agent.
Defaults, Timers, and Limits
Compliance evaluation cycle: Every 24 hours. You can trigger on-demand evaluation via PowerShell (Start-AzPolicyComplianceScan) or CLI (az policy state trigger-scan).
Maximum number of policy definitions: 500 per subscription (soft limit, can be increased via support ticket).
Maximum number of initiatives: 200 per subscription.
Maximum number of assignments per scope: 200.
Maximum number of parameters per policy definition: 20.
Maximum number of aliases per policy rule: 30.
Policy evaluation timeout: 5 minutes per resource during deployment. If evaluation takes longer, the request is allowed (fail-open).
Interaction with Related Technologies
RBAC: Azure Policy does not replace RBAC. RBAC controls access; Policy controls resource properties. You need both: RBAC to allow a user to create VMs, Policy to ensure those VMs are only Standard_DS2_v2.
Azure Blueprints: Blueprints can include policy assignments as artifacts. When you assign a blueprint, it creates the policy assignments automatically.
Management Groups: Policies assigned at a management group scope apply to all child subscriptions. This is the most efficient way to enforce organization-wide rules.
Azure Resource Graph: You can use Resource Graph to query compliance data across subscriptions.
Azure DevOps / CI/CD: Policies can be integrated into pipelines to validate infrastructure-as-code templates before deployment using Azure Policy as Code.
Configuration and Verification Commands
Create a policy definition (CLI):
az policy definition create --name 'deny-vm-sku' --rules '{"if":{"allOf":[{"field":"type","equals":"Microsoft.Compute/virtualMachines"},{"field":"Microsoft.Compute/virtualMachines/sku.name","in":["Standard_D5_v2","Standard_D5_v3"]}]},"then":{"effect":"deny"}}' --display-name 'Deny certain VM SKUs' --description 'This policy denies the creation of D5 v2 and D5 v3 VMs'Assign a policy (CLI):
az policy assignment create --name 'deny-vm-sku-assignment' --policy 'deny-vm-sku' --scope '/subscriptions/12345-...'View compliance (PowerShell):
Get-AzPolicyState -PolicyAssignmentName 'deny-vm-sku-assignment'Trigger on-demand scan (CLI):
az policy state trigger-scan --no-waitSummary of Internal Mechanism
User submits a resource creation/update via ARM.
ARM intercepts the request and evaluates RBAC (is user allowed?).
ARM calls Azure Policy engine with the resource properties.
Policy engine identifies all assignments applicable to the resource (based on scope).
For each assignment, the engine evaluates the policy rule condition against the resource properties.
If the condition is true (non-compliant), the engine applies the effect (Deny, Audit, Append, etc.).
For Deny, ARM returns 403. For Audit, ARM allows the request but logs a compliance event.
After deployment, the periodic scan (every 24h) re-evaluates all resources to detect drift.
Define the Policy Rule
Create a JSON policy definition that specifies the condition and effect. Use the Azure portal, CLI, PowerShell, or ARM template. The policy rule includes an 'if' block with logical operators (allOf, anyOf, not) and field conditions (field, equals, like, in, exists). The 'then' block specifies the effect. Example: to deny VMs of SKU Standard_D5_v2, the condition checks 'Microsoft.Compute/virtualMachines/sku.name' equals 'Standard_D5_v2'. Use aliases for resource properties. Test the rule using the 'Policy simulator' in the portal.
Assign the Policy to a Scope
Choose a scope: management group, subscription, or resource group. The policy will evaluate all resources within that scope, including child scopes unless excluded. You can also specify exclusions (e.g., exclude a specific resource group). Set enforcement mode: 'Enabled' (default) applies the effect; 'Disabled' only evaluates without enforcement (useful for testing). You can also set parameters at assignment time to customize the policy without changing the definition.
Evaluate Resources at Deployment
When a resource is created or updated, ARM calls the Azure Policy engine. The engine retrieves all policy assignments applicable to the resource's scope and evaluates the resource properties against each policy rule. If a Deny effect matches, ARM rejects the request with HTTP 403. The error message includes the policy name and reason. For Audit, the resource is created but marked non-compliant in the compliance dashboard.
Periodic Compliance Scan
Every 24 hours, Azure Policy automatically scans all resources in assigned scopes to detect configuration drift. This ensures that changes made outside the deployment pipeline (e.g., via portal or API) are caught. The scan updates the compliance state. Resources that were previously compliant may become non-compliant if their properties change. You can trigger an on-demand scan using PowerShell or CLI.
Remediate Non-Compliant Resources
For policies with DeployIfNotExists or Modify effects, you can create a remediation task. Remediation uses a system-assigned managed identity (created automatically) to apply the required changes. For example, a policy that deploys an extension on VMs can remediate existing VMs that lack it. You can initiate remediation from the portal under 'Policy' > 'Remediation'. Tasks run asynchronously and can take time depending on the number of resources.
Enterprise Scenario 1: Enforcing Tagging Standards
A large enterprise with multiple business units uses Azure for cloud workloads. The finance department needs to track costs by cost center. The solution: an Azure Policy initiative that requires specific tags (CostCenter, Environment, Owner) on all resources. The policy uses the 'Deny' effect for new resources and 'Append' for existing ones (to add missing tags without blocking updates). The policy is assigned at the management group level, ensuring all subscriptions inherit it. Exclusions are created for a sandbox subscription where developers can experiment without tags. Compliance is monitored monthly via the Azure Policy dashboard. When a team deploys a resource without tags, the deployment is denied, and the error message tells them which tags are missing. This enforces discipline without manual review.
Enterprise Scenario 2: Restricting VM SKUs to Control Costs
A company wants to prevent users from deploying expensive GPU VMs (e.g., NC-series) to avoid unexpected bills. They create a policy that denies VMs with SKUs in a defined list. The policy is assigned to all production subscriptions. However, the data science team needs NC-series for training models. The solution: an exemption is created for a specific resource group used by data science, with an expiration date. The policy also includes an 'Audit' effect for non-production subscriptions to alert but not block. This allows flexibility while maintaining governance. The cloud center of excellence reviews exemption requests monthly.
Enterprise Scenario 3: Ensuring Encryption on Storage Accounts
A regulated industry requires all storage accounts to have encryption at rest enabled (which is default) and HTTPS traffic only. They create a policy that audits storage accounts where 'supportsHttpsTrafficOnly' is false. They also use the 'DeployIfNotExists' effect to automatically enable HTTPS on non-compliant accounts via a remediation task. The policy is assigned at the subscription level. When a storage account is created with HTTPS disabled, the deployment is denied (if Deny effect is used) or flagged (if Audit). The remediation task runs weekly to fix any accounts that were altered. This ensures continuous compliance with regulatory requirements.
Common Pitfalls
Scope errors: Assigning a policy at the wrong scope leads to either too broad or too narrow enforcement.
Effect misunderstanding: Using 'Audit' when 'Deny' is needed results in non-compliant resources being created.
Alias misuse: Using incorrect aliases causes the policy to never match. Always verify aliases with Get-AzPolicyAlias.
Performance: Too many policies (approaching limits) can slow down deployments. Use initiatives to combine related policies.
Exemption mismanagement: Overusing exemptions weakens governance. Always set expiration dates.
What AZ-104 Specifically Tests (Objective 1.2)
Manage Azure Policy: Create and assign policies, configure policy parameters, manage policy compliance, and use policy initiatives.
Key actions: Create policy definitions (built-in and custom), assign policies at different scopes, review compliance reports, trigger remediation tasks.
Most Common Wrong Answers and Why Candidates Choose Them
Confusing Azure Policy with RBAC: Many candidates think Azure Policy controls who can create resources. In reality, Policy controls what resources are allowed (properties), not who. The exam will present scenarios where a user is denied access vs. a resource is denied because of properties. Wrong answer: 'Assign the contributor role.' Correct: 'Create a policy that denies the VM SKU.'
Choosing 'Audit' when the scenario requires 'Deny': The exam often asks: 'You need to prevent users from deploying VMs without tags.' The wrong answer is 'Create a policy with Audit effect' because candidates think Audit blocks. Audit only logs; Deny blocks. Correct answer: 'Use Deny effect.'
Misunderstanding scope inheritance: Candidates may think a policy assigned to a resource group applies to the entire subscription. Actually, it only applies to that resource group. Conversely, a policy assigned to a management group applies to all subscriptions under it. The exam loves to test this with hierarchical scenarios.
Ignoring built-in definitions: The exam expects you to know that many common policies already exist (e.g., 'Allowed locations', 'Allowed resource types'). Candidates often create custom policies when a built-in would suffice.
Specific Numbers, Values, and Terms That Appear Verbatim
Effects: Deny, Audit, Append, AuditIfNotExists, DeployIfNotExists, Disabled.
Compliance states: Compliant, Non-compliant, Conflict, Error, Not started.
Evaluation cycle: Every 24 hours.
Limits: 500 policy definitions per subscription, 200 initiatives, 200 assignments per scope.
Aliases: Property paths like Microsoft.Compute/virtualMachines/sku.name.
Parameters: Use to customize policies without rewriting.
Exemptions: Can be used to exclude resources from evaluation.
Edge Cases and Exceptions
Policy with Append effect on existing resources: Append only works on create/update, not on existing resources. To fix existing resources, use DeployIfNotExists with remediation.
Conflicting policies: If two policies have opposite effects (e.g., one Denies, one Allows), the Deny effect takes precedence (most restrictive wins).
Policy evaluation timeout: If evaluation takes >5 minutes, the request is allowed (fail-open). This is rare but tested.
Initiative evaluation: When an initiative is assigned, all included policies are evaluated. Compliance is per policy, not per initiative (unless you use grouping).
How to Eliminate Wrong Answers
If the question says 'prevent' or 'block', the effect must be 'Deny', not 'Audit'.
If the question says 'ensure existing resources are compliant', look for 'DeployIfNotExists' with remediation.
If the question involves 'tags', think 'Append' effect for missing tags.
If the question mentions 'multiple subscriptions', assign the policy to the management group.
If the question says 'without modifying the policy definition', use parameters.
Azure Policy enforces rules on resource properties, not user permissions.
Policy definitions are JSON documents with an if-then structure (condition + effect).
Common effects: Deny (blocks), Audit (logs), Append (adds fields), DeployIfNotExists (remediates).
Assign policies to scopes: management group, subscription, or resource group. Assignments propagate to child scopes.
Compliance evaluation occurs at deployment and every 24 hours for existing resources.
Use parameters to make policies reusable without changing the definition.
Built-in policy definitions exist for common scenarios (e.g., allowed locations, allowed SKUs).
Exemptions can exclude specific resources from policy evaluation, but should be used sparingly.
Remediation tasks fix non-compliant resources for DeployIfNotExists and Modify effects.
Maximum limits: 500 policy definitions, 200 initiatives, 200 assignments per scope.
These come up on the exam all the time. Here's how to tell them apart.
Azure Policy
Controls resource properties (e.g., SKU, location, tags).
Uses policy definitions and assignments.
Effects: Deny, Audit, Append, etc.
Scoped to management groups, subscriptions, resource groups.
Evaluates at deployment and periodically (every 24 hours).
RBAC
Controls who can perform actions (read, write, delete).
Uses role definitions and assignments.
Permissions: allow/deny actions.
Scoped to management groups, subscriptions, resource groups, or individual resources.
Evaluated at request time via Azure AD tokens.
Deny Effect
Blocks the deployment of non-compliant resources.
Returns HTTP 403 Forbidden.
Used when you want to enforce compliance strictly.
Cannot be overridden without removing the policy.
Best for security-critical rules (e.g., require HTTPS).
Audit Effect
Allows deployment but logs non-compliance.
Creates a compliance event in the activity log.
Used for monitoring or soft enforcement.
Useful for testing policies before enforcing.
Best for rules that are advisory or need review.
Mistake
Azure Policy replaces RBAC for access control.
Correct
Azure Policy does not control who can perform actions; it controls what resource properties are allowed. RBAC and Policy are complementary. RBAC grants permissions to users; Policy enforces rules on resources.
Mistake
A policy with Audit effect blocks non-compliant deployments.
Correct
Audit effect only logs non-compliance events in the activity log; it does not block the deployment. To block, use Deny effect.
Mistake
Policy assignments at a resource group scope apply to all subscriptions.
Correct
Policy assignments are scoped to the specific resource group only. They do not inherit to other resource groups or subscriptions. Only management group assignments propagate to child subscriptions.
Mistake
Once a policy is assigned, it only evaluates new resources.
Correct
Azure Policy evaluates both new and existing resources. Existing resources are evaluated during the periodic compliance scan (every 24 hours) and can be flagged as non-compliant.
Mistake
Custom policy definitions are always required; built-in ones are rarely used.
Correct
Azure provides many built-in policy definitions (e.g., 'Allowed locations', 'Allowed resource types', 'Audit VMs without managed disks'). The AZ-104 exam expects you to know when to use built-in vs. custom definitions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Policy controls resource properties (e.g., 'VMs must be Standard_DS2_v2'), while RBAC controls user permissions (e.g., 'User A can create VMs'). They are complementary. A user with Contributor role can still be blocked by a Deny policy if the resource doesn't meet the policy conditions.
Yes, if the policy has a Deny effect and the resource properties violate the condition. The deployment will fail with HTTP 403 and an error message. For example, a policy that denies VMs without a specific tag will block the creation.
New resources are evaluated at deployment. Existing resources are evaluated every 24 hours via a periodic compliance scan. You can also trigger an on-demand scan using PowerShell or CLI.
An initiative is a collection of policy definitions grouped to achieve a specific compliance goal, such as 'ISO 27001' or 'CIS Benchmark'. Assigning an initiative applies all its policies at once. Initiatives can be built-in or custom.
For policies with DeployIfNotExists or Modify effects, you can create a remediation task that uses a managed identity to apply the required changes. For other effects (Deny, Audit), you must manually update the resources or use automation.
An exemption allows you to exclude a resource or scope from policy evaluation. You can specify an expiration date and a reason. Exemptions are useful for temporary exceptions, but overuse can weaken governance.
Yes. You can create a policy that requires specific tags using the 'Append' effect (to add missing tags) or 'Deny' effect (to block untagged resources). Built-in policies like 'Require a tag and its value' are available.
You've just covered Azure Policy and Initiatives — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?