Best practices for Infrastructure as Code CI / CD on Azure

Tired of brittle pipelines, leaked secrets, and dev/test/prod folders drifting out of sync? In this no-nonsense session from the Microsoft Azure Infrastructure Summit, Jack Tracey and Jared Holgate — from the team behind Azure Landing Zones and Azure Verified Modules — lay out the battle-tested best practices for Infrastructure as Code CI/CD on Azure, covering Bicep, Terraform, Azure DevOps, and GitHub Actions. You will learn why you should stop writing modules from scratch and lean on Azure Verified Modules (AVM), how to enforce "code once, configure many" repo layouts driven by parameter or tfvars files, and why static secrets and certificates are dead while Workload Identity Federation (OIDC) is the only sane choice. The session walks through federated credential subject claims for GitHub vs. Azure DevOps, least-privilege RBAC with split plan/apply identities, and how to lock pipelines down with governed templates and required approvals. Closing out, the speakers cover shift-left practices — linting, pre-commit hooks, GitHub Advanced Security, ephemeral test environments, and production monitoring — the three-layer Terraform state model used by ALZ (platform, application landing zone, application workload), and how to bootstrap subscription vending end-to-end so application teams can spin up in minutes, not days. A live GitHub demo ties it all together. 📢 Speakers Jack Tracy — Senior Cloud Solution Architect, Microsoft Jared Holgate — Senior Cloud Solution Architect, Microsoft 💡 Key Takeaways - Don't write IaC from scratch — consume Azure Verified Modules from the Bicep Public Registry or HashiCorp Terraform Registry, which are pre-aligned to the Well-Architected Framework. - Use one folder, one branch, one source of truth. Drive per-environment differences with tfvars or bicep param files, never duplicated module code in dev/test/prod folders. - Kill static secrets and certificates for deploy-time auth. Use Workload Identity Federation (OIDC) with a user-assigned managed identity wherever possible. - Apply least-privilege RBAC by splitting identities per environment: a reader-scoped plan/what-if identity and a separate contributor/owner-scoped apply/deploy identity. - Use governed pipelines stored in a separate, more tightly controlled repository, and pin service connections or federated credentials to them via required templates or job_workflow_ref claims. - Require human approvals on production — on GitHub environments (enforced via OIDC environment subject claims) and on Azure DevOps service connections (not environments, which can be bypassed in YAML). - Shift left aggressively: pre-commit hooks, linting, GitHub Advanced Security, automated tests on PRs, and ephemeral test environments that are spun up and torn down per run. - Structure Terraform state in three layers — platform landing zone, application landing zone (subscription vending), and application workload — never collapse all subscriptions into one state file. 📖 Resources - Bicep on Microsoft Learn https://learn.microsoft.com/azure/azure-resource-manager/bicep/ — Official documentation for the Bicep DSL, language reference, and deployment guidance. - Azure Bicep GitHub repository https://github.com/Azure/bicep — Source for the Bicep compiler, tooling, and the public registry of modules referenced by AVM. - Azure Bicep Deploy GitHub Action https://github.com/Azure/bicep-deploy — Official action for deploying Bicep and ARM templates from GitHub Actions with OIDC. - GitHub Actions for Azure on Microsoft Learn https://learn.microsoft.com/azure/developer/github/ — Authenticate from GitHub Actions to Azure with Workload Identity Federation and deploy IaC. - Azure Pipelines documentation https://learn.microsoft.com/azure/devops/pipelines/ — Reference for service connections, approvals and checks, required templates, and YAML pipelines in Azure DevOps.