Azure Policy is the core governance engine of Microsoft Azure.While Azure Role-Based Access Control (RBAC) controls who can perform actions, Azure Policy controls what properties resources can (or must) have during creation and configuration.

Architecture: How Azure Policy Works

Azure Policy sits directly inside the Azure Resource Manager (ARM) request pipeline.Every ARM request (Portal, CLI, Terraform, ARM/Bicep templates) passes through the Policy evaluation engine before hitting the underlying Resource Provider.

The request passes through ARM to the Policy Engine, which evaluates the JSON rules and branches into allowed/modified or denied.

For interview answers on this topic, these details are worth adding:

• Where policy sits: Policy evaluation happens at the ARM layer, before the request reaches the resource provider. That is why a Deny effect blocks a create or update before anything is deployed.
• Effects map to the branches: Deny produces the blocked outcome. Modify and Append alter the request and let it through, which is the “Modified” part of your diagram. Audit allows the request but records non-compliance.
• What the diagram leaves out: DeployIfNotExists and AuditIfNotExists run after the resource is created, as a separate evaluation. They don’t block the original request, which is why remediation of existing resources needs a separate remediation task, as we covered in the storage account scenario.

post deployment path,

Here’s the post-deployment path. It runs after the request-time flow from the first diagram, once the resource exists.I took your “yes” as the diagram extension. Together the two diagrams show the full picture: the first is the request-time gate, and this one is the after-the-fact check.

Three points to make in an interview:

• Remediation is not automatic for existing resources. DeployIfNotExists and Modify act on new or updated resources. Resources that already existed need a remediation task, and that task uses the managed identity with the roles declared in the policy’s roleDefinitionIds.
• Compliance evaluation is not instant. After a policy assignment, the engine runs a compliance scan on a schedule and can take a while to flag existing resources. An on-demand scan (az policy state trigger-scan) is available when you need results sooner.
• Request-time and post-deployment effects fail differently. Deny stops a bad resource from existing at all. DeployIfNotExists lets it exist briefly and then fixes it, which is why Deny is the safer choice for a control like disabling public network access on storage accounts.

Evaluation Triggers

Evaluation occurs in three scenarios:

1. Real-time (CRUD Operations): Triggered instantly during resource creation, modification, or deletion.
2. Periodic Scan:Automatically runs every 24 hours across all assigned scopes.
3. On-Demand / Assignment Change:Triggered when a policy or initiative assignment is created, updated, or manually kicked off via Azure CLI/PowerShell.

Core Components

1. Definition (The Rule)

A JSON structure that specifies the target conditions and what effect to trigger when conditions are met.

JSON

{
  "properties": {
    "displayName": "Require HTTPS on Storage Accounts",
    "policyRule": {
      "if": {
        "allOf": [
          { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
          { "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly", "notEquals": "true" }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

2. Initiative (Policy Set)

A group of policy definitions tailored toward a single overarching goal (e.g., PCI-DSS Compliance, Cost Control, or ISO 27001). Using initiatives reduces administrative overhead by allowing you to assign 50+ individual rules in a single assignment.

3. Scope & Assignments

Assignments apply a definition or initiative to a target boundary. Scopes inherit policies hierarchically:

The diagram shows the five scopes from the tenant root group down to individual resources, with the dashed arrow marking inheritance. Policy assignments and RBAC role assignments made at a higher scope apply to everything below it.

4. Exclusions vs. Exemptions

• Exclusions:Defined during initial policy assignment to permanently exclude a scope (e.g., a test Resource Group) from evaluation.
• Exemptions:Time-bound or context-bound waivers applied to specific existing resources (e.g., waiving a legacy server for 90 days during a migration window).

Policy Effects & Execution Order

Effects determine what action Azure Policy takes when a condition evaluates to true. ARM processes effects in a strict order to prevent conflicts.

Advanced Techniques & Design Patterns

Remediation via Managed Identities

Effects like Modify and DeployIfNotExists require write permissions on existing non-compliant resources.During assignment, Azure Policy creates a System-Assigned or User-Assigned Managed Identity and grants it specific RBAC roles (e.g., Contributor) to execute remediation tasks.

Policy-as-Code (EPAC Framework)

Enterprise governance manages policy JSON files via Git version control and deployment pipelines (Azure DevOps / GitHub Actions) using the Enterprise Azure Policy-as-Code (EPAC) framework:

1. Authoring: Custom JSON / Bicep definition files stored in git.
2. Testing: Deploy policies with Audit effect to CI/CD staging subscriptions.
3. Validation:Run automated check gates (AzurePolicyCheckGate@0).
4. Production: Promote and switch effect parameter to Deny.

Azure Arc & Kubernetes Integration

Azure Policy extends beyond native ARM resources:

• Guest Configuration: Extends policy inside OS virtual machines (Linux/Windows) to audit/modify registry settings, password policies, and installed software.
• Azure Arc / Kubernetes: Uses OPA Gatekeeper to enforce Pod Security Admission standards, container registry restrictions, and resource limits directly on AKS or Arc-enabled K8s clusters.