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:

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 condition
THEN apply effect

For example:

IF location is not one of the approved locations
THEN 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 BusinessOwner tag.

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:

1. Identify the organizational requirement.
2. Determine which resource types and properties must be evaluated.
3. Identify the appropriate policy aliases.
4. Define the policy parameters.
5. Define the if conditions.
6. Define the appropriate effect.
7. Create the policy definition.
8. Assign the policy.
9. Monitor compliance.
10. 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 = parameter
Production assignment:
    East US
    West US
Development 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:

• Audit
• Deny
• Modify
• DeployIfNotExists
• AuditIfNotExists
• Append
• DenyAction
• Disabled

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 tag
then 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.

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:

1. Identify non-compliant resources.
2. Configure the policy appropriately.
3. Provide an appropriate managed identity.
4. Grant the identity the required permissions.
5. Create a remediation task.
6. 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.

29. Key Takeaways

For the SC-500 exam, remember these core ideas:

1. Azure Policy evaluates resource configurations against organizational rules.
2. A policy definition describes the rule; an assignment applies it.
3. Built-in policies are maintained by Microsoft.
4. Custom policies address organization-specific requirements.
5. Parameters make policies reusable.
6. Aliases allow policy definitions to reference resource properties.
7. Audit identifies problems without blocking operations.
8. Deny prevents non-compliant operations.
9. Modify changes supported resource properties.
10. DeployIfNotExists can deploy missing configuration.
11. AuditIfNotExists detects missing related resources/configuration.
12. Initiatives group multiple policies into a single governance package.
13. Policies can be assigned at management group, subscription, resource group, or resource scope.
14. Remediation can require a managed identity with appropriate permissions.
15. Least privilege should also apply to policy remediation identities.
16. Azure Policy can provide preventive, detective, and corrective controls.
17. 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