This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
--> Implement governance to enforce security and regulatory compliance
--> Implement and configure security controls by using Azure Policy, including built-in and custom policy definitions
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Azure Policy is a governance service that helps organizations define, enforce, and assess rules for Azure resources. It can be used to ensure that resources comply with organizational security requirements, regulatory standards, naming conventions, tagging requirements, and configuration standards.
For the SC-500 exam, it is important to understand that Azure Policy is primarily about resource governance and compliance, whereas Microsoft Entra ID and Azure RBAC are primarily concerned with identity and authorization.
Azure Policy evaluates resources against policy definitions and determines whether those resources comply with the organization’s requirements. Depending on the policy effect, Azure Policy can:
- Block a resource deployment.
- Audit a resource without blocking it.
- Modify resource properties.
- Automatically deploy required configuration.
- Prevent specific resource actions.
- Identify resources that should have related resources or configurations.
- Report compliance status.
Policies can be assigned at different scopes, including management groups, subscriptions, resource groups, and individual resources.
1. Understanding Azure Policy
Azure Policy follows a relatively simple conceptual model:
Policy definition → Assignment → Evaluation → Compliance result / Enforcement
For example, an organization might have a security requirement:
All Azure Storage accounts must disable public network access.
A policy definition can describe that requirement. The policy can then be assigned to a subscription or management group.
Azure Policy evaluates resources within the assignment scope and determines whether each resource complies.
Example
Suppose a subscription contains:
- Storage account A — public network access disabled
- Storage account B — public network access enabled
- Storage account C — public network access disabled
A policy requiring public network access to be disabled would report:
| Resource | Compliance |
|---|---|
| Storage A | Compliant |
| Storage B | Non-compliant |
| Storage C | Compliant |
If the policy uses the Deny effect, a future attempt to create or update a non-compliant resource can be blocked.
2. Azure Policy vs. Azure RBAC
This is an important distinction for the SC-500 exam.
Azure RBAC
Azure RBAC answers:
Who is allowed to do something?
For example:
Allow the Storage Administrator role to manage storage accounts.
Azure Policy
Azure Policy answers:
What configurations or actions are allowed or required?
For example:
Storage accounts must use private endpoints.
These services complement each other.
An administrator could have permission to create a storage account through RBAC but still be prevented from creating it in a prohibited region because Azure Policy applies a Deny policy.
3. Policy Definitions
A policy definition describes the rule that Azure Policy evaluates.
Policy definitions are expressed in JSON and contain information such as:
- Display name
- Description
- Mode
- Parameters
- Metadata
- Policy rule
- Effect
The policy rule contains an if portion and a then portion. The if portion identifies the resources or conditions that should trigger the policy. The then portion specifies what Azure Policy should do when the condition is met.
Conceptually:
IF resource meets conditionTHEN apply effect
For example:
IF location is not one of the approved locationsTHEN deny deployment
4. Built-in Policy Definitions
Azure provides a large collection of built-in policy definitions.
Built-in policies are created and maintained by Microsoft.
Examples include policies that:
- Restrict allowed Azure regions.
- Require specific tags.
- Audit unencrypted resources.
- Require secure configurations.
- Restrict resource types.
- Require diagnostic settings.
- Enforce network security configurations.
- Require Microsoft Defender protections.
Built-in policies can significantly reduce development and maintenance effort because you don’t need to create a custom policy for requirements that Azure Policy already supports.
Exam tip
When a question asks you to implement a standard Azure security requirement and a suitable built-in policy already exists, the built-in policy is frequently the preferred answer.
5. Custom Policy Definitions
A custom policy definition is created by an organization when its requirements aren’t adequately addressed by an existing built-in policy.
Custom policies are useful when an organization has requirements such as:
Every production resource must have a
BusinessOwnertag.
Or:
Storage accounts used by the Finance workload must use a specific configuration.
Or:
Only approved VM SKUs may be deployed in a particular environment.
Custom policies are also useful when an organization wants to encode its own internal security standards.
The basic process is:
- Identify the organizational requirement.
- Determine which resource types and properties must be evaluated.
- Identify the appropriate policy aliases.
- Define the policy parameters.
- Define the
ifconditions. - Define the appropriate effect.
- Create the policy definition.
- Assign the policy.
- Monitor compliance.
- Remediate non-compliant resources when applicable.
6. Policy Definition Structure
A simplified Azure Policy definition looks like this:
{ "properties": { "displayName": "Require approved locations", "description": "Restricts resources to approved Azure regions.", "mode": "Indexed", "parameters": { "allowedLocations": { "type": "array" } }, "policyRule": { "if": { "not": { "field": "location", "in": "[parameters('allowedLocations')]" } }, "then": { "effect": "deny" } } }}
The important components are:
displayName
Human-readable name for the policy.
description
Explains the purpose of the policy.
mode
Determines which resource types and properties are evaluated.
parameters
Makes a policy reusable by allowing values to be supplied when the policy is assigned.
policyRule
Contains the actual evaluation logic.
if
Defines the condition that causes the policy to apply.
then
Defines the resulting effect.
7. Policy Parameters
Parameters make policies more reusable.
Instead of creating separate policies such as:
- Allow East US
- Allow West US
- Allow Central US
you can create one policy with an allowedLocations parameter.
Different assignments can then provide different values.
For example:
Policy: Allowed locations = parameterProduction assignment: East US West USDevelopment assignment: East US West US Central US
This reduces the number of policy definitions that an organization must maintain.
Azure Policy parameters can have types such as:
- String
- Array
- Boolean
- Integer
- Float
- Object
- DateTime
Parameters are defined in the policy definition and supplied when the policy is assigned.
8. Policy Aliases
Policy aliases allow Azure Policy to reference specific properties of Azure resources.
For example, a policy might need to evaluate a property belonging to:
Microsoft.Storage/storageAccounts
Rather than relying on arbitrary JSON paths, Azure Policy uses aliases to reference resource properties.
Aliases are especially important when creating custom policies.
Why aliases matter
Suppose you want to determine whether a storage account has public network access enabled.
The policy needs to evaluate the corresponding resource property.
An appropriate alias allows the policy to reference that property.
Azure provides aliases for many Azure resource properties, and the list evolves as Azure resource providers evolve. Microsoft recommends tools such as the Azure Policy extension for Visual Studio Code or Azure PowerShell for discovering available aliases.
Array aliases
Azure Policy also supports array aliases using [*].
These allow policy rules to evaluate individual elements of an array property.
For example, a network ACL might contain multiple IP rules. An array alias can allow the policy to evaluate the individual rules rather than treating the entire array as a single value.
Exam tip
If a question asks how to create a custom policy that evaluates a particular Azure resource property, think:
Find the appropriate policy alias.
9. Policy Effects
The effect determines what happens when the policy rule applies.
The effects most important to understand for the SC-500 exam include:
AuditDenyModifyDeployIfNotExistsAuditIfNotExistsAppendDenyActionDisabled
Audit
The Audit effect identifies resources that don’t comply without preventing their creation or modification.
Use Audit when you want to:
- Assess an existing environment.
- Understand the current compliance state.
- Introduce a new security requirement gradually.
- Monitor compliance without breaking deployments.
Example
Requirement:
All storage accounts should use private endpoints.
Using Audit initially allows the organization to discover which resources don’t comply.
10. Deny
The Deny effect prevents resource operations that would violate the policy.
For example:
Prevent users from deploying resources outside approved Azure regions.
A Deny policy can prevent the deployment from occurring.
When to use Deny
Use Deny when the requirement is mandatory and the organization is prepared to enforce it.
Exam distinction
Audit:
“Tell me what’s wrong.”
Deny:
“Don’t allow it.”
11. Modify
The Modify effect can add, update, or remove supported resource properties during resource creation or update.
A common example is automatically adding or updating resource tags.
For example:
If a resource doesn't contain the Environment tagthen add Environment = Production
Modify can also be used with remediation tasks to address existing non-compliant resources.
Policies using Modify require an appropriate managed identity and permissions when remediation requires Azure Policy to make changes.
12. DeployIfNotExists
DeployIfNotExists is used when Azure Policy should deploy a related resource or configuration if it isn’t already present.
For example:
Every Azure VM must have a specific monitoring configuration.
If the configuration doesn’t exist, the policy can trigger a deployment to create it.
This is different from Modify.
Modify
Changes supported properties of the existing resource.
DeployIfNotExists
Deploys a related resource or configuration when a required item doesn’t exist.
13. AuditIfNotExists
AuditIfNotExists identifies resources that don’t have a related resource or configuration.
For example:
Every virtual machine should have a specific monitoring resource associated with it.
If the related resource isn’t present, Azure Policy reports the resource as non-compliant.
It doesn’t automatically deploy the missing configuration.
Easy way to remember
AuditIfNotExists
“Tell me if it doesn’t exist.”
DeployIfNotExists
“If it doesn’t exist, deploy it.”
14. Append
The Append effect can add fields to a resource during creation or update.
It is particularly useful for adding properties to resource requests when the property isn’t already specified.
For many modern scenarios, however, you should understand whether Modify is the more appropriate effect because Modify provides broader property modification capabilities.
15. DenyAction
The DenyAction effect blocks specific actions rather than simply blocking resource creation.
A classic example is preventing deletion of particular resources or preventing certain operations based on policy conditions.
This can provide an additional governance layer for critical resources.
16. Disabled
The Disabled effect effectively turns off enforcement for the policy definition.
This can be useful when:
- Testing.
- Temporarily disabling a policy.
- Retaining the policy definition while disabling its effect.
17. Policy Assignments
Creating a policy definition doesn’t cause Azure resources to be evaluated.
The policy must be assigned.
A policy assignment associates a policy definition with a scope.
Possible scopes include:
- Management group
- Subscription
- Resource group
- Individual resource
An assignment applies to resources within its scope and can include exclusions.
Example
An organization has:
Management Group│├── Production Subscription│├── Development Subscription│└── Test Subscription
A policy can be assigned at the management-group level.
That allows the organization to establish a common security baseline across the subscriptions beneath it.
18. Management Groups and Azure Policy
Management groups are particularly valuable when an organization needs centralized governance across multiple subscriptions.
For example:
Enterprise Management Group│├── Production│ ├── Subscription A│ └── Subscription B│└── Non-Production ├── Subscription C └── Subscription D
A security policy could be assigned at the management-group level.
This provides centralized governance while allowing individual subscriptions to remain independently managed.
SC-500 exam consideration
If a question says:
Apply the same security requirement to multiple subscriptions
consider whether the policy should be assigned at a management group rather than individually to every subscription.
19. Policy Initiatives
A policy initiative, also called a policy set, is a collection of related policy definitions.
Instead of assigning 20 individual policies separately, you can group them into a single initiative.
For example:
Secure Storage Initiative
Could contain policies requiring:
- Secure transfer.
- Encryption.
- Private networking.
- Diagnostic logging.
- Approved regions.
- Defender protection.
The initiative can then be assigned as a single governance package.
Azure documentation describes an initiative as a collection of policy definitions designed around a common overarching goal.
20. Built-in vs. Custom Policies
A common exam scenario is deciding whether to use a built-in or custom policy.
| Requirement | Recommended approach |
|---|---|
| Microsoft already provides an appropriate policy | Built-in policy |
| Organization has unique requirement | Custom policy |
| Need different values for different environments | Parameterized policy |
| Need many related policies managed together | Initiative |
| Need to prevent non-compliant deployments | Deny |
| Need visibility without blocking deployment | Audit |
| Need to automatically change supported properties | Modify |
| Need to deploy a missing configuration | DeployIfNotExists |
| Need to identify missing related resources | AuditIfNotExists |
21. Policy Compliance
Azure Policy continuously evaluates the compliance state of resources.
A resource can be:
- Compliant
- Non-compliant
- Not registered
- Conflicting
- Exempt
- Unknown, depending on the evaluation circumstances
The important concept for the exam is that Azure Policy isn’t merely a deployment-time mechanism.
It can also evaluate existing resources and report their compliance status.
This makes Azure Policy useful for identifying configuration drift.
22. Remediating Non-Compliant Resources
Some policies don’t simply identify non-compliant resources; they can help remediate them.
The Modify and DeployIfNotExists effects are especially important here.
A remediation workflow generally involves:
- Identify non-compliant resources.
- Configure the policy appropriately.
- Provide an appropriate managed identity.
- Grant the identity the required permissions.
- Create a remediation task.
- Azure Policy performs the required operation.
For custom policies using Modify or DeployIfNotExists, the policy definition can specify the required role definitions through roleDefinitionIds. Permissions should follow least privilege.
Important exam distinction
A policy showing a resource as non-compliant does not automatically mean the resource will be fixed.
The effect and remediation configuration determine whether Azure Policy can take corrective action.
23. Testing Policies Before Enforcement
A good governance strategy is to avoid immediately deploying a new security policy with a disruptive effect such as Deny.
A common approach is:
Phase 1 — Evaluate
Use:
Audit
Determine how many resources would violate the proposed requirement.
Phase 2 — Remediate
Correct existing violations.
Phase 3 — Enforce
Change the policy to an enforcement-oriented effect such as:
Deny
This reduces the likelihood that a new policy unexpectedly breaks production deployments.
24. Policy Enforcement Mode
Azure Policy assignments can also use enforcement behavior that allows organizations to test policy behavior without actually enforcing the effect on new or updated resources.
This is particularly useful during policy development and rollout.
For example, an organization might want to determine whether a Deny policy would interfere with existing deployment processes before fully enforcing it.
25. Azure Policy and Security Governance
Azure Policy is particularly useful for establishing preventive and detective security controls.
Preventive controls
Examples:
- Deny resources in prohibited regions.
- Deny insecure resource configurations.
- Require specific security settings.
- Prevent certain actions.
Detective controls
Examples:
- Audit insecure configurations.
- Identify missing security controls.
- Report non-compliant resources.
- Monitor configuration drift.
Corrective controls
Examples:
- Modify resource properties.
- Add required tags.
- Deploy missing configurations.
- Remediate existing resources.
This makes Azure Policy a useful part of a defense-in-depth security strategy.
26. Azure Policy and Regulatory Compliance
Azure Policy can also support regulatory compliance by enforcing or monitoring required configurations.
For example, an organization might require:
- Encryption.
- Secure network connectivity.
- Diagnostic logging.
- Approved locations.
- Resource tagging.
- Specific security configurations.
Microsoft provides built-in policies and initiatives aligned with various compliance requirements.
However, remember:
Azure Policy helps enforce technical controls; it does not by itself make an organization legally or regulatorily compliant.
Compliance requires the organization to satisfy the complete applicable regulatory framework.
27. Azure Policy Best Practices
1. Prefer built-in policies when appropriate
Don’t create a custom policy when an existing built-in policy already meets the requirement.
2. Use parameters
Parameterized policies are more reusable and reduce policy sprawl.
3. Use initiatives
Group related policies into logical security or governance packages.
4. Start with Audit
For significant new requirements, consider evaluating the impact before enforcing Deny.
5. Use least privilege
Managed identities used for remediation should receive only the permissions they need.
6. Test custom policies
Incorrect policy logic can result in legitimate resources being incorrectly classified or blocked.
7. Understand aliases
When creating custom policies, verify that the property you’re evaluating has the appropriate Azure Policy alias.
8. Monitor compliance
A policy is only useful if you monitor whether resources actually comply.
9. Plan for exceptions
Some workloads legitimately require exceptions. Azure Policy supports policy exemptions for appropriate scenarios.
10. Treat policies as code
For larger organizations, store policy definitions and initiatives in source control and manage them through controlled deployment processes.
28. Important SC-500 Exam Comparisons
These distinctions are worth memorizing.
| Concept | Purpose |
|---|---|
| Azure Policy | Enforce or audit resource configuration and governance |
| Azure RBAC | Control who can perform actions on Azure resources |
| Microsoft Entra ID | Identity and authentication |
| Resource locks | Prevent accidental deletion or modification |
| Policy definition | Defines the rule |
| Policy assignment | Applies the rule to a scope |
| Initiative | Groups multiple policies |
| Built-in policy | Microsoft-provided policy |
| Custom policy | Organization-created policy |
| Audit | Report non-compliance |
| Deny | Prevent non-compliant operation |
| Modify | Modify supported resource properties |
| DeployIfNotExists | Deploy missing configuration/resource |
| AuditIfNotExists | Report missing configuration/resource |
| DenyAction | Block specified actions |
29. Key Takeaways
For the SC-500 exam, remember these core ideas:
- Azure Policy evaluates resource configurations against organizational rules.
- A policy definition describes the rule; an assignment applies it.
- Built-in policies are maintained by Microsoft.
- Custom policies address organization-specific requirements.
- Parameters make policies reusable.
- Aliases allow policy definitions to reference resource properties.
- Audit identifies problems without blocking operations.
- Deny prevents non-compliant operations.
- Modify changes supported resource properties.
- DeployIfNotExists can deploy missing configuration.
- AuditIfNotExists detects missing related resources/configuration.
- Initiatives group multiple policies into a single governance package.
- Policies can be assigned at management group, subscription, resource group, or resource scope.
- Remediation can require a managed identity with appropriate permissions.
- Least privilege should also apply to policy remediation identities.
- Azure Policy can provide preventive, detective, and corrective controls.
- Testing with Audit before enforcing Deny can reduce deployment disruption.
10 Practice Exam Questions
Question 1
An organization wants to prevent users from deploying Azure resources outside a predefined set of approved Azure regions.
The organization wants deployments to prohibited regions to be blocked rather than merely reported.
Which Azure Policy effect should you use?
A. Audit
B. Deny
C. Modify
D. AuditIfNotExists
Answer: B
Explanation
The Deny effect prevents resource operations that violate the policy. In this scenario, resources deployed to unapproved regions should be blocked.
- Audit would report the violation but allow the deployment.
- Modify is intended to change supported resource properties.
- AuditIfNotExists is used to identify missing related resources or configurations.
Question 2
Your organization needs a policy that can be assigned to multiple subscriptions. Each subscription must be able to specify its own list of approved Azure regions.
What should you use to make the policy reusable?
A. Policy parameters
B. Resource locks
C. Azure RBAC
D. Policy exemptions
Answer: A
Explanation
Policy parameters allow the same policy definition to be reused with different values during assignment.
For example, the same policy could be assigned to two subscriptions with different allowedLocations parameter values.
Resource locks don’t parameterize policies, RBAC controls authorization, and exemptions are used to exclude resources or scopes from policy enforcement.
Question 3
You need to create a custom Azure Policy that evaluates a specific property of an Azure resource.
What should you determine before writing the policy condition?
A. The resource’s Microsoft Entra group
B. The resource lock level
C. The subscription’s billing administrator
D. The appropriate Azure Policy alias
Answer: D
Explanation
Azure Policy uses property aliases to reference resource properties during policy evaluation.
When developing custom policies, identifying the correct alias is an important step. Azure provides tools for discovering available aliases.
Question 4
An organization wants to determine which existing resources violate a new security requirement. The organization does not want to prevent deployments while it evaluates the impact of the requirement.
Which effect should be used?
A. Deny
B. DeployIfNotExists
C. Modify
D. Audit
Answer: D
Explanation
Audit identifies non-compliant resources without blocking their deployment or modification.
This is commonly useful when introducing a new policy and determining the current compliance baseline before moving to stronger enforcement.
Question 5
A company requires every Azure resource to contain a CostCenter tag. When the tag is missing, Azure Policy should automatically add the tag.
Which policy effect is most appropriate?
A. AuditIfNotExists
B. Modify
C. DenyAction
D. Audit
Answer: B
Explanation
The Modify effect can add, update, or remove supported resource properties, including tags.
A policy using Modify can therefore add a required tag when appropriate.
Audit would only report the problem, while AuditIfNotExists is designed to evaluate whether a related resource or configuration exists.
Question 6
An organization wants to apply 15 different security policies as a single logical security baseline.
What should the organization create?
A. Resource lock
B. Policy assignment
C. Initiative
D. Custom RBAC role
Answer: C
Explanation
An initiative, also called a policy set, groups multiple policy definitions into a single logical collection.
The initiative can then be assigned as a unit.
Question 7
A company wants to determine whether virtual machines have a required related monitoring configuration. If the configuration is missing, the company only wants Azure Policy to report the VM as non-compliant.
Which effect should be used?
A. AuditIfNotExists
B. Modify
C. DeployIfNotExists
D. Deny
Answer: A
Explanation
AuditIfNotExists checks whether a related resource or configuration exists and reports non-compliance when it doesn’t.
DeployIfNotExists would go further by attempting to deploy the missing configuration.
Question 8
An organization wants Azure Policy to automatically deploy a required configuration when that configuration doesn’t exist on a resource.
Which effect should be used?
A. Audit
B. Deny
C. DeployIfNotExists
D. Disabled
Answer: C
Explanation
DeployIfNotExists can deploy a related resource or configuration when the required item doesn’t exist.
This effect can be used for corrective enforcement rather than simply reporting a compliance problem.
Question 9
A custom policy uses the DeployIfNotExists effect. Azure Policy must deploy resources as part of remediation.
What additional security consideration is required?
A. A resource lock must be applied to every target resource
B. A managed identity must have the required permissions
C. Every user must be assigned Owner
D. Microsoft Entra Password Hash Synchronization must be enabled
Answer: B
Explanation
Policies that perform remediation using DeployIfNotExists require an appropriate managed identity and sufficient permissions.
The permissions should follow the principle of least privilege. The identity should not automatically be granted broad permissions such as Owner unless they are genuinely required.
Question 10
An organization has several subscriptions under a management group. The security team wants one policy to enforce the same security requirement across all applicable subscriptions.
Where is an appropriate place to assign the policy?
A. The management group
B. Each individual VM
C. Each individual resource group only
D. The Microsoft Entra tenant
Answer: A
Explanation
A policy assigned at the management-group scope can apply to resources in child management groups and subscriptions within that hierarchy.
This is an effective approach for centralized governance across multiple subscriptions.
The Microsoft Entra tenant is not an Azure Policy assignment scope.
Final Exam-Focused Summary
If you remember only one conceptual model from this topic, remember:
AZURE POLICY
│
┌────────┴────────┐
│ │
Policy Definition Assignment
│ │
│ Applies to scope
│ │
└────────┬────────┘
│
Evaluation
│
┌───────────┼────────────┐
│ │ │
Audit Deny Remediate
│
┌────────┴────────┐
│ │
Modify DeployIfNotExists
And the most important exam distinctions are:
Definition = what the rule says
Assignment = where the rule applies
Parameter = makes the rule reusable
Alias = identifies the resource property
Audit = identify the problem
Deny = prevent the problem
Modify = change the resource
DeployIfNotExists = deploy what’s missing
Initiative = group policies together
Managed identity = enables policy remediation when permissions are required
These distinctions are particularly useful because SC-500 questions can present very similar scenarios where the key is identifying whether the requirement is to detect, prevent, modify, or deploy a security configuration.
Go to the SC-500 Exam Prep Hub main page
