This chapter covers Azure Policy, a core compliance service in Azure that enforces organizational standards and assesses compliance at scale. For the SC-900 exam, understanding Azure Policy is critical as it appears in roughly 15-20% of questions in the 'Describe the capabilities of Microsoft compliance solutions' domain (objective 4.1). You will need to differentiate Azure Policy from Azure RBAC and Azure Blueprints, and understand policy effects, initiative definitions, and assignment scope. This chapter provides the depth needed to confidently answer exam questions on policy definitions, initiatives, and compliance evaluation.
Jump to a section
Azure Policy is like a city's building code enforcement department. A city council (Azure) publishes a building code (policy definitions) with rules like 'all new buildings must have fire sprinklers' or 'maximum height is 10 stories.' These rules are stored in a registry (policy definitions). When a developer (Azure resource creator) submits a building plan (resource deployment request), the enforcement department (Azure Policy engine) checks the plan against the code before issuing a permit. If the plan violates a rule—say, the building is 12 stories—the permit is denied (deny effect). For existing buildings, the enforcement officer (evaluation engine) inspects them regularly (compliance scan) and issues a violation notice (non-compliant status). If the city decides to automatically fix violations—like requiring all buildings to have a fire extinguisher—they can send a crew to install one (deployIfNotExists effect). The building code can be applied to specific neighborhoods (scope: management group, subscription, resource group) or building types (resource type). Just as a building code ensures safety and consistency, Azure Policy ensures resources comply with organizational standards and cost controls. The key is that the code is enforced proactively at creation and reactively on existing resources, just like a building inspector who reviews plans and inspects completed work.
What is Azure Policy and Why Does It Exist?
Azure Policy is a service in Azure that allows you to create, assign, and manage policies that enforce rules over your Azure resources. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy evaluates your resources for non-compliance with assigned policies. It is a central component of the Microsoft Compliance solutions and is essential for governance and compliance.
How Azure Policy Works Internally
Azure Policy works by evaluating resource properties against policy rules. The process involves several key components:
- Policy Definition: A JSON-formatted rule that describes a condition and an effect. The condition uses comparison operators (equals, like, contains, exists, in, etc.) to check resource properties (tags, SKU, location, etc.). The effect is what happens when the condition is met. Common effects include: - Deny: Prevents the creation or modification of a non-compliant resource. - Audit: Creates a warning event in the activity log but does not block the request. - Append: Adds additional fields to the resource during creation or update. - AuditIfNotExists: Audits resources that do not have a specified extension or setting. - DeployIfNotExists: Deploys a template to correct non-compliant resources. - Disabled: The policy rule is ignored. - Modify: Adds, updates, or removes properties on a resource during creation or update.
Initiative Definition (Policy Set): A collection of policy definitions grouped together for a specific compliance goal, such as 'Enable Monitoring for Azure Security Center.' Initiatives simplify management by assigning a single set of policies instead of multiple individual policies.
Assignment: The process of applying a policy or initiative to a specific scope. Scopes are hierarchical: Management Group > Subscription > Resource Group > Resource. A policy assigned at a higher scope automatically applies to all child scopes, unless explicitly excluded.
Compliance Evaluation: Azure Policy evaluates resources at the following times:
When a resource is created, updated, or deleted (triggered by resource provider events).
During a full compliance scan (every 24 hours by default for each policy assignment).
On-demand via Azure CLI, PowerShell, or REST API.
The evaluation engine checks each resource against all applicable policy assignments. It determines compliance status: Compliant, Non-compliant, or Conflicting (for policies with multiple effects). Non-compliant resources are listed in the Azure Portal under Policy > Compliance.
Key Components, Values, Defaults, and Timers
Default Compliance Scan Interval: Every 24 hours. You can trigger an on-demand scan using Start-AzPolicyComplianceScan PowerShell cmdlet or az policy state trigger-scan CLI command.
Policy Definition Structure: Must include if (condition) and then (effect) blocks. Example:
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
"equals": "false"
}
]
},
"then": {
"effect": "deny"
}
}Built-in Policies: Azure provides over 500 built-in policy definitions covering security, cost, management, and compliance (e.g., 'Allowed locations', 'Allowed resource types', 'Require SQL Server version 12.0').
Exemptions: You can create exemptions to exclude specific resources or scopes from policy evaluation. Exemptions have an expiration date (default none, but can be set).
Policy Parameters: Allow you to customize policies at assignment time (e.g., list of allowed locations).
Remediation: For DeployIfNotExists and Modify effects, you can trigger remediation tasks to fix non-compliant resources. The remediation task runs a deployment template to correct the resource.
Configuration and Verification Commands
Azure Policy can be managed via Azure Portal, Azure CLI, Azure PowerShell, REST API, and SDKs. Key commands:
Create policy definition:
az policy definition create --name "deny-storage-https" --rules policy.json --display-name "Deny storage accounts without HTTPS"Create initiative definition:
az policy set-definition create --name "my-initiative" --definitions "[{\"policyDefinitionId\":\"/providers/Microsoft.Authorization/policyDefinitions/...\"}]"Assign policy:
az policy assignment create --name "deny-https-assignment" --policy "deny-storage-https" --scope "/subscriptions/12345/resourceGroups/myRG"Trigger compliance scan:
az policy state trigger-scan --resource-group myRGView compliance state:
az policy state list --resource "/subscriptions/12345/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorage"Interaction with Related Technologies
Azure RBAC: Azure Policy does not control access (who can create resources); RBAC does. Policy controls what resources can be created (e.g., deny creation of certain SKUs). They are complementary: RBAC controls actions, Policy controls resource properties.
Azure Blueprints: Blueprints package policies, role assignments, ARM templates, and resource groups into a single deployable artifact. Policies within a blueprint are assigned as part of the blueprint deployment.
Management Groups: Policies assigned at a management group scope apply to all subscriptions under that management group. This allows hierarchical compliance enforcement.
Azure Security Center: Security Center uses Azure Policy to enforce security recommendations. For example, the 'ASC Default' initiative includes policies for enabling encryption, updating OS versions, etc.
Azure Resource Graph: You can query compliance data using Resource Graph Explorer (e.g., policyResources table).
Exam-Relevant Details
The exam tests that you know the difference between deny, audit, append, deployIfNotExists, and modify effects.
You must understand that policy definitions are individual rules, while initiatives are collections of policies.
Assignment scope is critical: a policy assigned at subscription level applies to all resource groups and resources within that subscription, unless excluded.
Exemptions are different from exclusions: exclusions are defined in the assignment's excluded scopes, while exemptions are separate objects that can expire.
Compliance evaluation occurs at resource creation/update and every 24 hours. On-demand scans can be triggered.
Remediation is only possible for DeployIfNotExists and Modify effects. Deny and Audit cannot remediate.
Policy parameters allow customization without changing the definition.
Common Trap Patterns
Confusing Azure Policy with Azure RBAC: Exam questions may describe a scenario where you need to restrict what resources can be created (e.g., only allow specific VM sizes). The answer is Azure Policy, not RBAC. RBAC controls who can create resources, not what properties they can have.
Thinking policies are applied retroactively: Some candidates believe policies only affect new resources. In reality, policies evaluate existing resources during compliance scans and can trigger remediation.
Assuming all effects block creation: Only Deny and Modify (during creation) block resource creation. Audit and Append do not block; they log or modify after creation.
Mixing up initiatives and policy definitions: An initiative is a set of policies; a definition is a single policy. The exam may ask which to use for multiple related rules.
Edge Cases and Exceptions
Conflicting policies: If two policies with different effects apply to the same resource (e.g., one denies, one audits), the deny effect takes precedence and the resource is blocked. The audit effect is not triggered.
Policy evaluation for subscription-level resources: Some resource types are subscription-scoped (e.g., resource groups themselves). Policies can target these using the type field with value Microsoft.Resources/subscriptions/resourceGroups.
Policy effects for existing resources: Deny only blocks new/modify operations. To remediate existing non-compliant resources, you must use DeployIfNotExists or Modify and trigger remediation.
Policy parameters with allowed values: You can restrict parameter values at assignment time to prevent misconfiguration.
How to Eliminate Wrong Answers
If the question mentions 'prevent creation of resources that don't have specific tags,' the effect must be Deny (or Modify with deny enforcement). Audit only logs.
If the question says 'automatically deploy a Log Analytics agent on VMs that don't have it,' the effect is DeployIfNotExists.
If the question asks about grouping multiple policies for a single assignment, the answer is Initiative.
If the question involves controlling who can assign policies, that's RBAC (e.g., 'Policy Contributor' role).
Summary of Exam Focus
The SC-900 exam focuses on foundational understanding: what Azure Policy does, its effects, how it differs from RBAC, and how it fits into compliance solutions. Memorize the effects and their behaviors. Know that policies are evaluated at creation and periodically. Understand the hierarchy of scope. Be able to identify when to use a policy vs. an initiative. This chapter has covered all these aspects in depth.
Define Policy Rule in JSON
Write a JSON policy definition that includes a condition (if) and an effect (then). For example, to deny storage accounts that do not require HTTPS, you check the field `Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly` equals false. The effect is 'deny'. The JSON must be valid and reference the correct resource property aliases. Use Azure Policy aliases list to find the exact property path. The definition is stored in Azure as a resource of type `Microsoft.Authorization/policyDefinitions`.
Create Policy Definition in Azure
Use Azure Portal, CLI, or PowerShell to create the policy definition. For example, `az policy definition create --name deny-http-storage --rules policy.json`. The definition is registered at a scope (management group or subscription). It becomes available for assignment. The definition ID is assigned, e.g., `/subscriptions/{subId}/providers/Microsoft.Authorization/policyDefinitions/deny-http-storage`. This ID is used when creating initiatives or assignments.
Create Initiative Definition (Optional)
If you have multiple policies, group them into an initiative. Create a JSON array of policy definition IDs and parameters. For example, an initiative for 'Secure Storage' might include the HTTPS policy, an allowed SKU policy, and an encryption policy. Use `az policy set-definition create`. The initiative is also stored as a resource. Assigning the initiative applies all its policies to the scope.
Assign Policy to a Scope
Assign the policy or initiative to a management group, subscription, or resource group. Specify exclusions (child scopes to exclude) and parameters (e.g., list of allowed locations). The assignment triggers immediate evaluation of existing resources? No, evaluation happens asynchronously. The assignment creates a compliance scan schedule (every 24 hours). Use `az policy assignment create --policy {definitionId} --scope /subscriptions/{subId}`.
Evaluate Compliance and View Results
Azure Policy evaluates resources continuously. You can view compliance state in the Azure Portal under Policy > Compliance. Non-compliant resources are listed with the policy that violated. You can trigger an on-demand scan using `az policy state trigger-scan`. The results are stored in the `policyStates` table and can be queried via Azure Resource Graph. If a resource is non-compliant due to a DeployIfNotExists policy, you can create a remediation task to fix it.
Azure Policy is widely used in enterprise environments to enforce governance and compliance. Here are two common scenarios:
Scenario 1: Enforcing Resource Location for Data Sovereignty A multinational company must ensure that all Azure resources are deployed only in approved regions to comply with data residency laws. The compliance team creates a built-in policy definition 'Allowed locations' and assigns it at the root management group scope, specifying only 'East US' and 'West Europe' as allowed. Exclusions are added for a specific subscription used for testing (e.g., 'Test Sub' allowed to use 'East US 2'). When a developer tries to deploy a VM in 'South Central US', the policy denies the creation with an error message. The audit team can monitor compliance via the Policy dashboard. If a resource was created before the policy was assigned, it appears as non-compliant. The team can choose to either migrate it or create an exemption with a justification and expiration date. This policy is critical for avoiding regulatory fines.
Scenario 2: Automatically Deploying Antimalware Extension A healthcare organization requires all Windows VMs to have the Microsoft Antimalware extension installed. They create a custom policy using the DeployIfNotExists effect that checks if the extension exists; if not, it deploys it. The policy is assigned to all subscriptions under a management group. When a new VM is created, the policy evaluates it immediately and, if missing, triggers a deployment. For existing VMs, the 24-hour compliance scan identifies non-compliant VMs and lists them. The operations team then runs a remediation task (via Portal or CLI) that deploys the extension to all non-compliant VMs. This automation ensures consistent security posture without manual intervention.
Common Pitfalls: - Overly broad scoping: Assigning a deny policy at management group level can block critical resources in child subscriptions if not properly excluded. - Parameter misconfiguration: For 'Allowed locations' policy, if the parameter list is empty, no resources can be created anywhere. - Remediation tasks may fail if the service principal used does not have sufficient permissions (requires contributor role on the target scope). - Exemptions without expiration can lead to compliance gaps; best practice is to set expiration dates and review regularly.
Scale Considerations: Azure Policy can handle thousands of assignments and millions of resources. Compliance scans are distributed and throttled to avoid impact on resource providers. The 24-hour scan interval is sufficient for most compliance needs. For real-time enforcement, rely on the evaluation during resource creation/update.
What SC-900 Tests on Azure Policy (Objective 4.1) The exam focuses on the fundamental capabilities of Azure Policy as part of Microsoft's compliance solutions. Specifically, you need to:
Describe the purpose of Azure Policy (enforce organizational standards, assess compliance).
Identify the different policy effects (Deny, Audit, Append, AuditIfNotExists, DeployIfNotExists, Modify, Disabled).
Differentiate Azure Policy from Azure RBAC (Policy controls resource properties; RBAC controls access).
Understand how policy assignments work with scope (management group, subscription, resource group).
Recognize that policies can be grouped into initiatives.
Know that compliance evaluation happens at resource creation/update and periodically (every 24 hours).
Common Wrong Answers and Why Candidates Choose Them 1. Choosing RBAC instead of Policy: When a question asks 'You need to ensure that only specific VM sizes can be created,' candidates often select RBAC because they think of 'who can create VMs.' But the constraint is on the resource property (size), not on who can perform the action. The correct answer is Azure Policy with a Deny effect. 2. Selecting 'Audit' when 'Deny' is needed: Candidates may choose Audit because it seems less restrictive. However, if the requirement is to prevent non-compliant resources, Deny must be used. Audit only logs. 3. Confusing Initiatives with Policy Definitions: A question may ask 'You have multiple policies that need to be assigned together.' Candidates may answer 'policy definition' instead of 'initiative.' Remember: a policy definition is a single rule; an initiative is a collection. 4. Thinking policies only apply to new resources: Some candidates believe policies do not affect existing resources. In reality, policies evaluate existing resources during compliance scans and can trigger remediation via DeployIfNotExists.
Specific Numbers and Terms That Appear on the Exam - Default compliance scan interval: 24 hours. - Effects: Deny, Audit, Append, AuditIfNotExists, DeployIfNotExists, Modify, Disabled. - Policy definition structure: if/then blocks. - Scope hierarchy: Management group > Subscription > Resource group > Resource. - Built-in policies: over 500. - Exemptions can have an expiration date.
Edge Cases and Exceptions
- Conflicting policies: If two policies with different effects apply to the same resource, the deny effect takes precedence.
- Resource types that are not evaluated: Some resource types like resource groups themselves can be controlled with policies targeting Microsoft.Resources/subscriptions/resourceGroups.
- Policy effects for existing resources: Deny does not block existing resources; only new or updated ones. To fix existing, use DeployIfNotExists or Modify with remediation.
How to Eliminate Wrong Answers - If the scenario says 'prevent creation,' the effect must be Deny (or Modify with deny enforcement). Not Audit. - If the scenario says 'automatically deploy,' the effect is DeployIfNotExists. - If the scenario says 'group multiple policies,' the answer is Initiative. - If the scenario involves 'who can assign policies,' that's RBAC (Policy Contributor role). - If the scenario involves 'compliance reporting,' it's Azure Policy compliance dashboard.
Azure Policy enforces organizational standards and assesses compliance across Azure resources.
Policy effects include Deny, Audit, Append, AuditIfNotExists, DeployIfNotExists, Modify, and Disabled.
An initiative is a collection of policy definitions; assign initiatives to apply multiple policies together.
Policies are assigned to a scope: Management Group > Subscription > Resource Group > Resource.
Compliance evaluation occurs at resource creation/update and every 24 hours (default scan interval).
Remediation is only possible for DeployIfNotExists and Modify effects.
Azure Policy does not control access; use Azure RBAC for access control.
Exemptions can exclude specific resources from policy evaluation and can have an expiration date.
Built-in policies cover security, cost, management, and compliance (over 500 definitions).
Conflicting policies: Deny effect takes precedence over other effects.
These come up on the exam all the time. Here's how to tell them apart.
Azure Policy
Controls resource properties (e.g., allowed SKUs, locations, tags).
Enforces rules via effects (deny, audit, deploy).
Assigned to scopes (management group, subscription, resource group).
Evaluates compliance continuously and periodically.
Uses policy definitions and initiatives.
Azure RBAC
Controls access (who can perform actions on resources).
Enforces permissions via role assignments (allow/deny actions).
Assigned to scopes (management group, subscription, resource group, resource).
Evaluated at runtime when an action is attempted.
Uses role definitions and role assignments.
Mistake
Azure Policy controls who can create resources.
Correct
Azure Policy does not control access; it controls resource properties. Access control is done via Azure RBAC (Role-Based Access Control).
Mistake
Policies only apply to new resources, not existing ones.
Correct
Policies evaluate existing resources during compliance scans (every 24 hours) and can trigger remediation for DeployIfNotExists or Modify effects.
Mistake
All policy effects block resource creation.
Correct
Only Deny and Modify (with deny enforcement) block creation. Audit, Append, AuditIfNotExists, and DeployIfNotExists do not block; they log or modify after creation.
Mistake
An initiative is the same as a policy definition.
Correct
A policy definition is a single rule. An initiative (policy set) is a collection of policy definitions grouped together for a common goal.
Mistake
Compliance evaluation only happens during resource creation.
Correct
Evaluation occurs at resource creation/update and also during periodic scans (every 24 hours). On-demand scans can be triggered.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Policy controls resource properties (e.g., allowed locations, SKUs) and enforces compliance rules. Azure RBAC controls who has access to resources and what actions they can perform. They are complementary: RBAC manages permissions, Policy manages resource configurations. For example, RBAC can allow a user to create VMs, but Policy can restrict which VM sizes they can create.
Yes, if the policy effect is Deny or Modify with deny enforcement. When a resource creation request violates a Deny policy, Azure denies the request and returns an error. The resource is not created. Audit and Append effects do not block creation.
Resources are evaluated when they are created, updated, or deleted. Additionally, a full compliance scan runs every 24 hours for each policy assignment. You can trigger an on-demand scan using Azure CLI, PowerShell, or REST API.
A policy definition is a single rule with a condition and effect. An initiative (policy set) is a collection of policy definitions that are grouped together for a specific compliance goal, such as 'Enable Monitoring for Security Center.' Initiatives simplify management by allowing you to assign multiple policies as a single entity.
Yes, if the policy uses the DeployIfNotExists or Modify effect. For DeployIfNotExists, you can trigger a remediation task that deploys a template to correct the resource. For Modify, changes can be applied during resource creation or via remediation. Deny and Audit effects do not provide automatic remediation.
The default compliance scan interval is 24 hours. This means every policy assignment triggers a full scan of all resources in its scope once per day. You can also trigger an on-demand scan using `az policy state trigger-scan` or the equivalent PowerShell cmdlet.
Yes, you can define exclusions when assigning a policy. Exclusions are child scopes (e.g., a specific resource group within a subscription) that are not evaluated by the policy. Additionally, you can create exemptions for individual resources with optional expiration dates.
You've just covered Azure Policy for Compliance — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?