Enterprise Policy as Code (EPAC) — Structuring and Deploying Your First Policy Assignments

Now that we have covered the introduction, setup, and how to manage EPAC in a multi-tenant environment, I will walk through a basic setup for assigning compliance initiatives per customer and rolling out policy definitions per customer.

1. Folder structure

In my code, under Definitions/policyAssignments, I have the customer folders. Under each folder, subfolders are created for compliance and monitoring. Naturally, the compliance initiatives go in the compliance folder. The monitoring folder contains two initiatives, azure-monitor-agent-linux and azure-monitor-agent-windows, which ensure that the Azure Monitor Agent is always deployed to virtual machines. Under _shared are policies that apply to all customers.

EPAC does not care how you structure this — you are free to put all policies and initiatives under a single folder, but in my opinion that quickly becomes hard to manage.

2. Reviewing changes before deployment

After deploying to the feature branch (dev pipeline) or release-prod branch (prod pipeline), I recommend always deploying to a feature branch first so you can review what EPAC is about to execute. Below is a partial output of what EPAC will execute for my tenant:

▶ Processing Policy Assignments
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  • Source folder: ./Definitions/policyAssignments
  ✓ Found 8 assignment files
    ✓ New: Require Environment tag on resource groups at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
    ✓ New: [cloudmartinpronk] Deploy Azure Monitor Agent op Linux VMs at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Log Analytics Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Virtual Machine Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Monitoring Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Azure Connected Machine Resource Administrator at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Log Analytics Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Monitoring Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
    ✓ New: [cloudmartinpronk] Deploy Azure Monitor Agent op Windows VMs at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Log Analytics Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Virtual Machine Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Monitoring Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Azure Connected Machine Resource Administrator at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Log Analytics Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
      ✓ Add role: Monitoring Contributor at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
    ✓ New: [cloudmartinpronk] CIS Microsoft Azure Foundations Benchmark v2.0.0 at /managementGroups/cccccccc-cccc-cccc-cccc-cccccccccccc
  • Unchanged assignments: 0

As you can see, the output matches exactly what I have defined in code.

3. Deploying to production

After deploying to the release-prod branch, EPAC actually deploys the policies to Azure via the Deploy Policy Changes and Deploy Role Changes pipeline stages.

In this case the deployment succeeded! When I verify this in Policy | Assignments in Azure, I can see them listed there — mission accomplished.

---

Conclusion

With a well-structured folder layout under Definitions/policyAssignments, you have a solid foundation for managing compliance and monitoring policies per customer. The separation between _shared and customer-specific folders keeps things organized and makes it immediately clear what applies to everyone versus what is customer-specific.

The real value becomes visible once you deploy: EPAC gives you a clear preview of exactly what will change before anything is applied to Azure. That dry-run step — deploying to the feature branch first — removes uncertainty and makes policy changes fully reviewable, just like any other code change.

The end result is a reproducible, auditable setup where every policy assignment is tracked in git, every change goes through a pipeline, and every customer gets exactly the policies they are supposed to get — nothing more, nothing less.