4.1 Azure Policy for Security Controls

4.1 Azure Policy for Security Controls

Quick Answer: Use Azure Policy to enforce security and regulatory configuration on Azure resources. Assign built-in or custom definitions (or initiatives) at a management group, subscription, or resource group. Choose effects such as Deny, Audit, DeployIfNotExists, Modify, Append, or Disabled. Policy does not replace RBAC—Policy shapes resource configuration; RBAC shapes who may perform actions.

The SC-500 domain Manage identity, access, and governance explicitly measures implementing security controls with Azure Policy (built-in and custom definitions), evaluating regulatory compliance in Defender for Cloud, resource locks, RBAC, backup security, and infrastructure as code. This section is the Policy foundation; later sections cover Defender standards, locks/RBAC, and backup/IaC.

Why Policy Matters for Cloud Security Engineers

In a multi-subscription enterprise, you cannot rely on every engineer to remember that storage accounts must block public blob access, that Key Vaults need soft-delete and purge protection, or that VMs must use managed disks with encryption. Azure Policy continuously evaluates resources and can block noncompliant creates/updates, audit drift, or auto-remediate missing settings via DeployIfNotExists and Modify.

Policy evaluations apply at Azure Resource Manager (control plane) for most definition modes. A Deny policy stops a noncompliant deployment request before the resource provider completes the change. Periodic compliance scans re-evaluate existing resources so the compliance state stays current even if nothing new was deployed.

Policy Building Blocks

Built-in vs custom definitions

Built-in definitions ship with Azure and cover hundreds of security scenarios: allowed locations, require HTTPS on storage, disable public network access on Key Vault, require diagnostic settings, restrict SKUs, enforce tags, and more. Prefer built-ins when they match the control—Microsoft maintains the logic and aliases.

Custom definitions are JSON (or authored via Bicep/portal) when you need organization-specific rules: a required naming prefix, a custom tag schema, a nonstandard encryption property, or a combination of conditions not covered by a built-in. Custom definitions still use the same policy language: an if condition over resource properties/aliases and a then effect.

Scenario: Contoso must allow only eastus and eastus2 for production workloads and must deny public IP on VMs. Assign the built-in Allowed locations policy with a parameter for the two regions, and assign a built-in or custom definition that denies public IP configurations. One initiative can bundle both for a single “Prod security baseline” assignment.

Initiatives

An initiative packages many definitions so operators assign once. Microsoft and third-party compliance packages often appear as initiatives. Changing initiative membership or definition versions can change compliance scores across every assignment of that initiative—plan initiative design carefully in large tenants.

Assignment scopes

Child scopes inherit parent assignments. Use exclusions on an assignment to skip a specific subscription, resource group, or resource without deleting the enterprise assignment. Exclusions are a common interview and exam answer when one legacy app cannot yet meet a Deny rule but the rest of the estate must stay locked down.

You can also set notScopes (exclusions) and use resource selectors or overrides on modern assignments to refine which resources are evaluated and which effect applies. For SC-500 depth, know that assignment scope + effect + parameters determine real-world behavior—not the definition alone.

Effects you must know

Order of evaluation (high level): Disabled first; then Append/Modify (which can change the request); then Deny; then Audit/manual paths; existence-based effects (AuditIfNotExists/DeployIfNotExists) complete after resource provider success for Resource Manager modes. Multiple policies stack; the net result is cumulatively restrictive—two Deny policies with conflicting location rules can block creation entirely.

DeployIfNotExists operational notes

DINE does not silently fix everything the moment you assign it. You need:

1. A managed identity on the assignment.
2. That identity granted enough RBAC to create the missing resource (for example, permissions to write diagnostic settings).
3. Often a remediation task to fix already-existing noncompliant resources.

Exam questions love the distinction: Deny stops the bad config; DINE adds the missing security control after the resource exists (or via remediation).

Compliance evaluation

After assignment, Azure Policy marks each resource Compliant, Non-compliant, Exempt, Conflicting, or other states depending on effect and condition. Non-compliant resources for Audit/DINE appear in the Policy compliance blade and often surface as inputs to Defender for Cloud recommendations and regulatory standards (next section).

New/updated resources are evaluated on the write path. Existing resources are scanned periodically (typically on the order of hours, not seconds). Do not promise “instant” compliance dashboard updates after a portal click—wait for the next evaluation cycle or trigger remediation where supported.

Azure Policy vs Azure RBAC (exam distinction)

Exam trap: A user has Owner on a subscription and still cannot deploy a resource in an unapproved region. That is Policy Deny, not a missing role. Conversely, a user with correct Policy-compliant template but Reader role cannot deploy— that is RBAC.

Practical security patterns

1. Landing-zone Deny baseline at management group: allowed locations, require TLS, block public network access on sensitive PaaS, require Key Vault purge protection for production initiatives.
2. Audit → Deny journey: Start with Audit for 30 days, remediate, then switch effect parameter to Deny.
3. Guest configuration / Machine Configuration policies for in-guest OS settings (covered more with compute security)—still Policy assignments under the hood.
4. Exemptions with expiration for break-glass subscriptions, never permanent silent exclusions.

Exam traps

• Confusing initiative with definition.
• Thinking Policy assignments at resource group stop data-plane blob deletes (they generally do not; Policy is primarily control-plane configuration).
• Forgetting DINE needs identity + role + remediation.
• Believing Disabled deletes the assignment (it only turns evaluation off).
• Using Policy to “grant least privilege” instead of RBAC/PIM.

Master these building blocks and you can map almost any “enforce security configuration at scale” scenario on SC-500 to the correct Policy design.