Azure Policy and Initiatives

Azure Policy is a service in Azure that allows you to create, assign, and manage policies that enforce rules over your cloud resources. It evaluates resources for compliance with those rules, providing a dashboard for compliance state. Unlike Azure RBAC, which focuses on who can do what (permissions), Azure Policy focuses on what resources are allowed or denied (configuration). For example, RBAC can allow a user to create virtual machines, but Azure Policy can ensure those VMs are only created in a specific region or of a specific SKU.

Azure Policy works through a combination of policy definitions, assignments, and effects. When you create a policy definition, you specify a condition using JSON format. The condition evaluates resource properties during creation, update, or periodic compliance scans. The policy is then assigned to a scope (management group, subscription, or resource group). The Azure Policy engine runs continuously in the background, evaluating all existing resources against assigned policies. When a new resource is created or an existing resource is updated, the engine checks the condition. Based on the effect specified in the policy, the engine either denies the operation, audits it, appends tags, or takes other actions.

{
  "if": {
    "field": "location",
    "notIn": ["eastus", "westus"]
  },
  "then": {
    "effect": "deny"
  }
}

- Initiative Definition: Also called a policy set, it is a collection of policy definitions grouped together to achieve a common goal. For example, the 'ISO 27001' initiative includes many policies for security compliance. - Assignment: The application of a policy or initiative to a specific scope. You can also exclude sub-scopes from the assignment. - Effect: The action taken when the condition is met. Common effects: - Deny: Prevents the resource creation or update. - Audit: Creates a warning event in the activity log but does not block the operation. - Append: Adds additional fields to the resource during creation or update (e.g., tags). - AuditIfNotExists: Enables auditing of resources that do not have specified extensions or configurations. - DeployIfNotExists: Deploys a template to remediate non-compliant resources. - Disabled: Effectively turns off the policy.

Azure Policy evaluates resources periodically. The default compliance scan interval is every 24 hours for existing resources. However, policy evaluation for new or updated resources happens in near real-time (within minutes). There is no configurable timer for the scan; it is fixed by the platform.

You can create policies using the Azure portal, Azure CLI, PowerShell, or ARM templates. For example, to create a policy that denies resources not in East US:

Azure CLI:

az policy definition create --name "deny-location" --display-name "Deny any location other than East US" --description "This policy denies creation of resources not in East US" --rules '{"if":{"field":"location","notIn":["eastus"]},"then":{"effect":"deny"}}'

To assign the policy:

az policy assignment create --name "deny-location-assignment" --policy "deny-location" --scope "/subscriptions/{subscriptionId}"

To check compliance:

az policy state list --resource "/subscriptions/{subscriptionId}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vmName}"

Azure Policy works alongside Azure RBAC, Azure Blueprints, and Azure Management Groups. RBAC controls who can create resources; Policy controls what resources can be created. Azure Blueprints can include policy assignments as part of a blueprint definition. Management groups provide hierarchical scopes for policy assignment, allowing inheritance to all child subscriptions.

The SC-900 exam will test your ability to distinguish Azure Policy from RBAC, understand policy effects (especially deny vs. audit), and know that initiatives group policies. You may see scenarios where you need to select the correct effect for a given requirement. Remember: Azure Policy is about resource configuration, not user permissions.

A global company must ensure that all resources are deployed only in approved Azure regions due to data sovereignty laws. They create a custom policy definition that denies any resource not in the allowed list of regions (e.g., East US, West Europe). The policy is assigned at the root management group, covering all subscriptions. Exclusions are made for a test subscription that uses a non-approved region. The compliance dashboard shows 100% compliance after remediation. Misconfiguration: if the policy is assigned at the subscription level instead of the management group, new subscriptions might be missed. Also, if the policy uses 'audit' instead of 'deny', non-compliant resources are created but flagged, leading to potential legal issues.

A company wants to enforce cost center tags on all resources. They use a policy with effect 'Append' to automatically add the 'CostCenter' tag if missing. The policy is assigned to all resource groups. When a user creates a VM without the tag, Azure Policy appends a default value (e.g., 'Unknown'). This ensures all resources are tagged for cost tracking. The challenge is that 'Append' only works during creation; existing resources remain untagged. A separate 'DeployIfNotExists' policy with remediation is used to tag existing resources. Common pitfall: if two policies try to append different values for the same tag, the assignment order determines which one wins, potentially causing inconsistent tagging.

A financial institution uses the built-in 'PCI-DSS v3.2.1' initiative to enforce security controls. This initiative includes dozens of policies covering encryption, network security, and logging. The initiative is assigned to production subscriptions. Non-compliant resources trigger alerts to the security team. The initiative's compliance score helps during audits. Performance consideration: evaluating many policies across thousands of resources can delay compliance scans, but Azure Policy scales automatically. A common misconfiguration is excluding critical resources from the initiative, creating security gaps.