This chapter covers Azure Policy, Azure Security Benchmark, and regulatory compliance initiatives — the core tools for enforcing security configurations and standards across Azure resources. For the AZ-500 exam, this topic area appears in roughly 15-20% of questions, primarily in domain 4 (Security Operations) but also in domain 1 (Identity and Access). Understanding how to define, assign, and evaluate policies, as well as how to leverage built-in benchmarks, is critical for passing the exam and for real-world security posture management.
Jump to a section
Imagine you are a city architect responsible for ensuring all buildings meet safety standards. The city council publishes a building code — a set of rules specifying minimum requirements for fire exits, load-bearing walls, electrical wiring, and plumbing. As an architect, you must design each building to comply with this code. However, the code is generic; it doesn't dictate every detail. You have flexibility in materials, layout, and aesthetics as long as the code's requirements are met. Now, think of Azure Policy as the building code enforcement office. You create policy definitions (the rules) and assign them to scopes (like neighborhoods). When a developer tries to construct a new resource (a building), Azure Policy evaluates it against the assigned definitions. If the resource violates a rule — say, it lacks a required tag or uses an unapproved SKU — Azure Policy can deny the deployment (like a permit denial) or audit it (like a citation). Azure Security Benchmark is the best-practice codebook published by the city's safety commission. It contains recommended configurations for common scenarios, like using strong locks on doors (enforcing encryption) or installing sprinklers (enabling threat detection). You can use Azure Policy to enforce these recommendations across your entire city (subscription). Just as a building that passes inspection is safer, a resource that complies with Azure Policy is more secure. The analogy holds mechanistically: policies are rules, assignments are scopes, effects are enforcement actions, and benchmarks are curated rule sets.
What Are Security Policies and Benchmarks?
Security policies in Azure are rules that enforce compliance and security standards across your cloud resources. They are implemented through Azure Policy, a service that allows you to create, assign, and manage policies. These policies evaluate your resources and can prevent non-compliant resources from being created, flag existing non-compliant resources, or even automatically remediate issues. The Azure Security Benchmark (ASB) is a set of curated, best-practice security recommendations based on common compliance frameworks like NIST SP 800-53 and CIS Controls. It provides specific configuration guidance for Azure services. Together, Azure Policy and ASB enable you to enforce security baselines and maintain continuous compliance.
How Azure Policy Works Internally
Azure Policy operates through a policy definition, which is a JSON document that specifies the conditions under which a resource is considered compliant. The definition includes:
Policy rule: Contains if (conditions) and then (effect) clauses.
Parameters: Allow customization of the policy at assignment time.
Metadata: Including category, version, and description.
When a resource is created, updated, or deleted, Azure Resource Manager sends the resource to Azure Policy for evaluation. The evaluation process:
1. Scope: Policy assignments are applied to a scope (management group, subscription, or resource group).
2. Evaluation: For each resource within scope, Azure Policy checks the resource properties against the policy rule.
3. Effect: Based on the rule match, one of several effects is triggered:
- Deny: Prevents the resource creation/update.
- Audit: Creates a warning event in the activity log but allows the operation.
- Append: Adds additional fields to the resource during creation/update.
- AuditIfNotExists: Audits resources that do not have a specified related resource (e.g., a diagnostic setting).
- DeployIfNotExists: Deploys a template to remediate non-compliant resources.
- Modify: Adds, updates, or removes properties on a resource.
- Disabled: Disables the policy evaluation.
Azure Policy uses a compliance state for each resource: Compliant, Non-compliant, Conflict, Error, or Not started. The compliance state is determined by evaluating the policy rule. If the rule condition is true, the resource is non-compliant (unless the effect is Audit, in which case it is still non-compliant but allowed).
Key Components, Values, Defaults, and Timers
Policy definition: JSON-based. Example snippet:
{
"if": {
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
"then": {
"effect": "deny"
}
}Initiative definition: A collection of policy definitions grouped together for a common goal (e.g., "Enable Monitoring in Azure Security Center").
Assignment: Binding a policy or initiative to a scope with optional parameters.
Exemption: Excludes a resource or scope from evaluation (used for specific exceptions).
Remediation task: Automatically fixes non-compliant resources for policies with DeployIfNotExists or Modify effects.
Timers: Policy evaluation is triggered on resource creation/update (real-time) and also during periodic compliance scans (every 24 hours by default). You can trigger an on-demand scan using Azure CLI or PowerShell.
Configuration and Verification Commands
To create and assign a policy using Azure CLI:
# Create a policy definition (built-in examples available)
az policy definition create --name "deny-vm-size" --rules @policy.json
# Assign the policy to a subscription
az policy assignment create --name "deny-vm-size-assignment" --policy "deny-vm-size" --scope /subscriptions/{subscriptionId}
# Trigger a compliance scan
az policy state trigger-scan --subscription {subscriptionId}To view compliance:
az policy state list --resource /subscriptions/{subscriptionId}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vmName}In PowerShell:
New-AzPolicyDefinition -Name "deny-vm-size" -Policy .\policy.json
New-AzPolicyAssignment -Name "deny-vm-size-assignment" -PolicyDefinition "deny-vm-size" -Scope "/subscriptions/{subscriptionId}"
Start-AzPolicyComplianceScan -Scope "/subscriptions/{subscriptionId}"Azure Security Benchmark (ASB)
The Azure Security Benchmark is a set of built-in policy initiatives that map to security controls. The current version is ASB v3 (as of 2024). It includes controls like: - NS-1: Establish network segmentation boundaries. - IM-1: Use Azure Active Directory as the primary authentication method. - LT-1: Enable threat detection for Azure resources.
Each control has one or more Azure Policy definitions that enforce the recommendation. For example, control NS-1 might include a policy that denies creation of subnets without a network security group.
You can assign the ASB initiative directly in the Azure portal under Azure Policy > Assignments > Assign Initiative > Search for "Azure Security Benchmark". This automatically enforces the baseline across your environment.
Regulatory Compliance Initiatives
Azure Policy also provides built-in initiatives for regulatory frameworks like: - CIS Microsoft Azure Foundations Benchmark (v1.3.0, v1.4.0) - NIST SP 800-53 Rev. 5 - ISO 27001:2013 - PCI DSS v3.2.1
These initiatives are pre-configured with policy definitions that map to specific controls. You can assign them to your subscriptions to continuously monitor compliance against the standard.
Interaction with Azure Security Center / Defender for Cloud
Azure Security Center (now part of Microsoft Defender for Cloud) uses Azure Policy to enforce security recommendations. When you enable a security policy in Defender for Cloud, it creates an Azure Policy assignment behind the scenes. The Secure Score is calculated based on compliance with these policies. For example, if you have a policy that requires encryption at rest, resources that do not comply reduce your secure score.
Common Exam Scenarios
Policy effects: Understand when to use Deny vs Audit vs Append. Deny is for blocking non-compliant resources; Audit is for monitoring without blocking; Append is for adding required tags.
Initiative vs policy: An initiative is a group of policies; you assign initiatives to scopes.
Exemptions: Use when a resource must be non-compliant temporarily (e.g., a legacy VM that cannot be updated). Exemptions have an expiration date.
Remediation: For DeployIfNotExists policies, you must create a remediation task to fix existing non-compliant resources.
Cross-subscription policies: Policies can be assigned to management groups to affect multiple subscriptions.
Step-by-Step: Enforcing a Security Baseline
Identify baseline: Select the Azure Security Benchmark initiative.
Assign initiative: Assign it to a management group or subscription. Configure parameters (e.g., allowed locations).
Evaluate compliance: Review the compliance dashboard. Non-compliant resources are listed.
Remediate: For policies with DeployIfNotExists, create remediation tasks to auto-fix.
Exempt if needed: Create exemptions for resources that cannot comply.
Monitor: Set up alerts for compliance state changes using Azure Monitor.
Key Numbers and Defaults
Default compliance scan interval: 24 hours.
Maximum number of policy assignments per scope: 200.
Maximum number of policy definitions per initiative: 400.
Exemption expiration: must be set; maximum duration is 1 year.
Remediation task timeout: 90 minutes per task.
Advanced: Custom Policy Definitions
You can create custom policies using JSON. Common conditions include checking tags, SKU sizes, locations, and properties. Example: Deny all resources in a specific region.
{
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "deny"
}
}Policy Evaluation Order
When multiple policies apply to a resource, Azure Policy evaluates them in order: first at the highest scope (management group) down to the resource group. If any policy denies the resource, the operation is denied. Audit policies still allow the operation but mark non-compliance.
Common Pitfalls
Inheritance: Policies are inherited from parent scopes. A deny policy at management group level applies to all child subscriptions.
Conflicting policies: If two policies have conflicting effects (e.g., one denies a location, another allows it), the deny effect wins.
Parameters: Forgetting to set parameters at assignment can cause unexpected behavior.
Summary
Azure Policy and Azure Security Benchmark are essential for maintaining security and compliance in Azure. The exam tests your ability to choose the correct policy effect, assign initiatives, and interpret compliance results. Practice with the Azure portal and CLI to solidify understanding.
Define a Custom Policy
Start by creating a JSON policy definition file. For example, to deny creation of VMs without a specific tag, define a condition that checks the 'tags' field. Use the 'if' clause to match resources where the tag 'environment' is missing. Set the 'then' effect to 'deny'. Save the file as policy.json. This step is foundational because custom policies allow you to enforce organization-specific rules beyond built-in ones.
Create the Policy Definition
Use Azure CLI or PowerShell to register the policy definition in your Azure environment. For CLI: 'az policy definition create --name "require-tag" --rules @policy.json'. This command uploads the JSON and makes the policy available for assignment. The definition is stored at the subscription level by default, but you can specify a management group scope. Once created, the policy appears in the Azure Policy Definitions blade.
Assign the Policy to a Scope
Assign the policy to a management group, subscription, or resource group using 'az policy assignment create --name "require-tag-assignment" --policy "require-tag" --scope "/subscriptions/{id}"'. The assignment includes optional parameters (e.g., tag name). When assigned, Azure Policy starts evaluating all existing and new resources within that scope. The evaluation is triggered immediately for existing resources and in real-time for new ones.
Check Compliance Status
After assignment, navigate to Azure Policy > Compliance in the portal. You'll see the policy and the number of compliant vs non-compliant resources. For a detailed view, use 'az policy state list --resource-id {id}'. Non-compliant resources are flagged with the effect defined (e.g., 'Deny' for blocking, 'Audit' for warning). This step validates that your policy is working as intended.
Remediate Non-Compliant Resources
For policies with 'DeployIfNotExists' or 'Modify' effects, create a remediation task. In the portal, select the policy, then 'Remediate'. You can choose to remediate all non-compliant resources or specific ones. The task runs a deployment template to fix the issue (e.g., add a diagnostic setting). Remediation tasks are asynchronous and can be monitored in the Activity Log.
Enterprise Scenario 1: Enforcing Resource Tagging Standards
A large enterprise with multiple business units deploys thousands of resources monthly. They need to enforce tagging for cost allocation and ownership. Using Azure Policy, they create a custom policy that denies creation of any resource without the mandatory tags 'CostCenter', 'Owner', and 'Environment'. They assign the policy to the root management group, ensuring all subscriptions inherit it. For existing resources, they use an 'Audit' effect initially to identify non-compliant resources without blocking operations. After a grace period, they switch to 'Deny' to enforce compliance. Remediation tasks are used to automatically add missing tags to existing resources via a 'Modify' effect. Performance is not an issue because policy evaluation is lightweight. Misconfiguration: If the policy is too strict (e.g., requiring tags on every resource type), it might block necessary resources like Azure Front Door profiles that don't support tags. The solution is to use exclusions or exemptions for specific resource types.
Scenario 2: Regulatory Compliance for Financial Services
A bank must comply with PCI DSS. They assign the built-in 'PCI DSS v3.2.1' initiative to their production subscription. This initiative contains dozens of policies covering encryption, network security, and access control. The compliance dashboard shows a score of 72% initially. The security team identifies that several SQL databases lack transparent data encryption (TDE). They create a remediation task to enable TDE on those databases. They also set up alerts to notify the team when compliance drops below 90%. Scale: With hundreds of databases, remediation tasks run sequentially but can be parallelized by splitting into multiple tasks. Common pitfall: The initiative includes policies that conflict with existing configurations (e.g., requiring TLS 1.2 only, but some legacy apps need TLS 1.0). They use exemptions with expiration dates to allow time for migration.
Scenario 3: Geo-Fencing Resource Deployments
A multinational company restricts resource deployment to specific Azure regions due to data residency requirements. They create a custom policy that denies any resource not in the allowed list (e.g., 'eastus', 'westeurope'). They assign the policy to all subscriptions. This prevents accidental deployment in prohibited regions. They also use the 'AuditIfNotExists' effect to ensure that resources have a 'DataResidency' tag. Performance: The policy evaluation adds negligible latency to deployment requests. Misconfiguration: If the policy uses 'field' type incorrectly (e.g., using 'location' on a resource type that doesn't have a location), it may not apply. The fix is to combine with 'type' condition. Also, if allowed regions change, they must update the policy parameters and trigger a compliance scan.
Exactly What AZ-500 Tests
AZ-500 objective 4.3 covers 'Implement security policies and benchmarks'. Specifically:
Create and assign Azure Policy definitions and initiatives.
Manage compliance using Azure Policy.
Implement Azure Security Benchmark and regulatory compliance initiatives.
Configure policy effects (Deny, Audit, Append, DeployIfNotExists, Modify).
Use exemptions and remediation tasks.
Questions often present a scenario requiring you to choose the correct policy effect or initiative. For example: 'You need to ensure that all storage accounts have encryption enabled. What should you do?' The answer is to create an Azure Policy with 'Deny' effect for storage accounts without encryption.
Common Wrong Answers and Why
Choosing 'Audit' instead of 'Deny': Candidates think 'Audit' is enough to enforce compliance, but 'Audit' only logs non-compliance; it does not block creation. If the requirement is to 'prevent' non-compliant resources, use 'Deny'.
Selecting 'Azure Blueprints' instead of 'Azure Policy': Blueprints are for deploying environments; policies are for enforcing rules. The exam tests this distinction.
Confusing 'Initiative' with 'Policy': An initiative is a group of policies. If the question asks for a set of rules, you need an initiative, not a single policy.
Forgetting to assign the policy: Many questions describe creating a policy but not assigning it. The policy only takes effect after assignment.
Using 'Append' when 'Modify' is needed: 'Append' adds fields, but for existing resources, 'Modify' is required to change properties.
Specific Numbers and Terms on the Exam
Default compliance scan interval: 24 hours.
Exemption maximum duration: 1 year.
Maximum policy assignments per scope: 200.
Initiative maximum policies: 400.
Know the difference between 'DeployIfNotExists' and 'Modify': DeployIfNotExists deploys a resource (e.g., a diagnostic setting), while Modify changes properties of the existing resource.
Azure Security Benchmark v3 is the current version (as of 2024).
Edge Cases and Exceptions
Inheritance: Policies assigned to a management group apply to all child subscriptions. A deny policy at a higher scope cannot be overridden at a lower scope.
Resource types: Some resource types (e.g., Azure Policy itself) are not evaluated.
Policy conflicts: If two policies conflict, the most restrictive effect wins. For example, if one policy denies a location and another allows it, the deny prevails.
Exemptions: Exemptions are for specific resources, not scopes. To exclude an entire subscription, assign a policy to a higher scope with an exemption for that subscription.
How to Eliminate Wrong Answers
Read the question carefully: Look for keywords like 'prevent', 'block', 'ensure' (use Deny) vs 'monitor' or 'audit' (use Audit).
Identify scope: If the requirement is organization-wide, assign at management group.
Check for existing resources: If the question involves fixing existing resources, look for 'remediation task' or 'DeployIfNotExists' effect.
Remember that built-in initiatives like ASB are available; you don't need to create custom policies for standard benchmarks.
Azure Policy uses JSON definitions with if/then logic and effects (Deny, Audit, Append, DeployIfNotExists, Modify).
Assign policies to scopes: management groups, subscriptions, or resource groups; inheritance applies from higher scopes.
Azure Security Benchmark v3 is the built-in best-practice initiative; regulatory compliance initiatives map to specific standards.
Exemptions are temporary (max 1 year) and exclude specific resources from policy evaluation.
Remediation tasks are required to fix existing non-compliant resources for DeployIfNotExists and Modify effects.
Default compliance scan runs every 24 hours; on-demand scans can be triggered via CLI/PowerShell.
Maximum 200 policy assignments per scope; maximum 400 policy definitions per initiative.
Policy evaluation is real-time on resource creation/update; deny effect prevents the operation.
Conflicting policies: most restrictive effect wins (deny overrides allow).
Azure Policy cannot enforce on resources not in Azure (except Azure Arc).
These come up on the exam all the time. Here's how to tell them apart.
Azure Policy
Enforces rules on existing and new resources.
Can deny, audit, or modify resources.
Used for ongoing compliance.
Assignable to management groups, subscriptions, resource groups.
No deployment of resources; only evaluation.
Azure Blueprints
Deploys a complete environment (resource groups, policies, RBAC).
Used for initial setup or versioned environments.
Not for ongoing enforcement; used at creation time.
Assignable to subscriptions only.
Includes artifact deployment (ARM templates, policies, RBAC).
Deny Effect
Blocks non-compliant resource creation/update.
Returns error to user.
Use when you must prevent non-compliance.
Resources cannot be created if they violate policy.
Strict enforcement.
Audit Effect
Allows resource creation/update but logs non-compliance.
Returns warning in activity log.
Use for monitoring or gradual enforcement.
Resources can be created even if non-compliant.
Soft enforcement.
Mistake
Azure Policy can enforce compliance on resources outside Azure.
Correct
Azure Policy only evaluates resources within Azure (and Azure Arc-enabled resources). It cannot enforce rules on on-premises resources or other clouds unless they are connected via Azure Arc.
Mistake
Assigning a policy with 'Deny' effect will automatically remediate existing non-compliant resources.
Correct
Deny only blocks new or updated resources that are non-compliant. Existing non-compliant resources remain unchanged. To fix them, you need a separate policy with 'DeployIfNotExists' or 'Modify' effect and a remediation task.
Mistake
You can override a deny policy by assigning a different policy at a lower scope.
Correct
Policy effects are additive and the most restrictive effect wins. If a parent scope has a deny policy, a child scope cannot override it to allow the resource. The only way to bypass is to remove or exempt the resource from the parent policy.
Mistake
Azure Security Benchmark is the same as regulatory compliance initiatives like PCI DSS.
Correct
ASB is a set of best practices from Microsoft, while regulatory compliance initiatives are mappings to specific standards (PCI DSS, NIST, etc.). They are separate built-in initiatives in Azure Policy.
Mistake
Policy exemptions are permanent and do not expire.
Correct
Exemptions must have an expiration date, with a maximum duration of 1 year. They are intended for temporary exceptions. For permanent exceptions, you should redesign the policy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Policy enforces rules on resource properties (e.g., tags, location, SKU) and can deny or audit resource creation. Azure RBAC controls who can perform actions on resources (e.g., who can create VMs). They are complementary: RBAC grants permissions, Policy enforces configurations. For example, RBAC allows a user to create a VM, but Policy can deny creation if the VM is not in the correct region.
Use a policy with the 'DeployIfNotExists' or 'Modify' effect. After assigning the policy, create a remediation task in the Azure portal (or via CLI/PowerShell) that runs the associated deployment template to fix the non-compliant resources. Remediation tasks are asynchronous and can be monitored in the Activity Log.
Yes. In the policy rule, use the 'field' property with 'tags' or 'tags[tagName]'. For example, to ensure a tag 'Environment' has value 'Production', the condition would be: 'field': 'tags.Environment', 'equals': 'Production'. You can also use 'notEquals' or 'exists' operators.
Azure Policy evaluates policies from highest scope to lowest. If two policies have conflicting effects, the most restrictive effect wins. For example, if one policy denies a location and another allows it, the deny effect prevails and resource creation is blocked. The compliance state may show 'Conflict' for resources affected by both.
Create an exemption for that resource. In the Azure portal, go to the policy assignment, select 'Exemptions', and create a new exemption. You must specify an expiration date (max 1 year). The resource will then be excluded from evaluation. Exemptions are for individual resources, not scopes.
The Azure Security Benchmark (ASB) is a set of security best practices from Microsoft, organized into controls. It is provided as a built-in Azure Policy initiative. Assigning the ASB initiative to your subscription will automatically enforce (or audit) the recommended configurations across your Azure resources. ASB v3 is the current version.
Yes. You can create a custom policy that checks the 'name' field using patterns or contains operators. For example, to ensure VM names start with 'prod-', use: 'field': 'name', 'like': 'prod-*'. You can use 'Deny' effect to block non-compliant names.
You've just covered Security Policies and Benchmarks — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?