Finest practices for Infrastructure as Code CI/CD on Azure

Hi there Of us!

In case your IaC repo has a dev folder, a check folder, and a prod folder that each one began out equivalent and have since drifted in three completely different instructions, this session is for you. On the Microsoft Azure Infrastructure Summit 2026, Jack Tracey and Jared Holgate (the staff behind Azure Touchdown Zones and Azure Verified Modules) laid out, in plain language, find out how to ship Infrastructure as Code on Azure with out leaking secrets and techniques, blowing up manufacturing, or duplicating hundreds of traces of module code throughout folders. Listed here are the bits that matter most for IT Professionals and platform engineers.

📺 Watch the session: 

You’re the one paged at 2am when a pipeline rolls out a damaged NSG rule. You’re the one carrying the cert that the deploy service principal nonetheless makes use of. You’re the one explaining to audit why the prod plan and the prod apply ran with the identical Proprietor-scoped id.

So this session is squarely in your lane. It covers:

• Why hand-rolled modules are slowly changing into an anti-pattern on Azure.
• A repo format that scales to dozens of environments with out copy-paste.
• Easy methods to eliminate static consumer secrets and techniques and federated cert auth, for good.
• The place approvals truly have to reside in GitHub vs. Azure DevOps in order that they can’t be bypassed.
• The three-layer Terraform state mannequin that Microsoft makes use of inside Azure Touchdown Zones.

Briefly, that is the practitioner model of “do IaC correctly,” from the individuals who write the platform code Microsoft ships.

Jack opened with a slide that will get a realizing snicker from anybody who has been doing this for greater than a 12 months. You begin with one repo, one Bicep file, one glad staff. Eighteen months later, you’ve a landingzone-prod-v2-final-USE-THIS-ONE folder, a service principal whose secret expired two days in the past, and a pipeline no one dares contact.

The drivers of that ache are constant:

• Modules written from scratch, by no means examined the identical approach twice.
• Per-environment folders that diverge silently over time.
• Lengthy-lived secrets and techniques and certificates sitting in pipeline variables.
• One id doing each plan and apply, with Proprietor on the administration group.
• No approvals, or approvals within the improper place.
• No checks till the deploy fails in prod.

The excellent news is none of those issues are new, and the patterns to repair them are nicely understood. The session walks by means of them within the order you’d truly undertake them.

That is greatest follow primary, and Jack and Jared spent a full chapter on it for a purpose. Azure Verified Modules (AVM) is the official Microsoft initiative that consolidates IaC modules for Azure right into a single, supported, Nicely-Architected-aligned library, out there in each Bicep and Terraform. The Bicep variations reside within the Public Bicep Registry beneath the avm/ namespace. The Terraform variations reside on the HashiCorp Terraform Registry beneath Azure/avm-*.

What you get free of charge if you devour an AVM module:

• Defaults that line up with the Nicely-Architected Framework (RBAC over entry insurance policies, TLS 1.2, non-public endpoint help out of the field).
• Semantic versioning so you may pin and evaluation the diff earlier than upgrading.
• Deployment checks on each module, run by the AVM staff.
• An actual Microsoft help path, not a random GitHub challenge.

An ideal backchannel query got here up about brownfield. Jared’s reply: AVM is simply commonplace IaC, no particular tooling. In Bicep, brownfield adoption is easy as a result of there is no such thing as a state. In Terraform, the brand new import blocks make it much less painful than it was.

Repo format is the place most groups go improper, and the repair is straightforward. You must have one set of module code, and per-environment variations needs to be expressed as knowledge, not as duplicated code. In Bicep, which means a single principal.bicep and one .bicepparam file per surroundings. In Terraform, the identical principal.tf with one .tfvars file per surroundings.

If you end up copying a module folder to dev, check, and prod, cease. Inside six months these three folders won’t look the identical, and at that time you not have IaC, you’ve three handwritten environments that occur to be checked into Git.

This was the chat spotlight. The query got here in: “So in brief, substitute all service principals with credential secrets and techniques with user-assigned managed id?” Jack and Jared each replied inside seconds: sure, 10 factors to you.

Workload Identification Federation (OIDC) lets your GitHub Actions or Azure DevOps pipeline trade a short-lived token from its personal OIDC supplier for a Microsoft Entra ID token. No consumer secrets and techniques, no certs to rotate, no Key Vault dance to retrieve them.

A few issues to know:

• Topic declare format differs by platform. GitHub makes use of repo:org/repo:surroundings:prod type claims; Azure DevOps makes use of sc://org/undertaking/connection. Choose the appropriate one or auth silently fails.
• Use a user-assigned managed id because the goal. It survives the pipeline being deleted and provides you one place to handle function assignments.
• The Azure Bicep Deploy GitHub Motion and the official AzureRM / AzAPI Terraform suppliers all help OIDC natively.

Even with OIDC, a single Proprietor-scoped id that does each terraform plan and terraform apply is an issue. Plan wants Reader (and some read-data permissions). Apply wants Contributor or Proprietor relying on what you deploy. Break up them into two identities, federated to 2 completely different phases of your pipeline, and you’ve got an actual least-privilege story to take to your safety staff.

Auth is half the story. The opposite half is ensuring solely the appropriate pipelines, with the appropriate approvals, can use these identities in any respect.

• Ruled templates. Preserve reusable pipeline templates in a separate, locked-down repo. Pin federated credentials or service connections to these templates through the job_workflow_ref declare on GitHub or required template checks on Azure DevOps. If somebody forks the workflow, the OIDC trade refuses to challenge a token.
• Approvals in the appropriate place. On GitHub, use Environments and require reviewers on prod. On Azure DevOps, put the approval on the Service Connection, not the Atmosphere. The Atmosphere approval could be bypassed by a intelligent YAML writer. The Service Connection approval can’t.
• Shift left, laborious. Pre-commit hooks for bicep format and terraform fmt, lint on each PR, GitHub Superior Safety for secret and code scanning, automated checks on PRs, and ephemeral check environments spun up per PR and torn down on the finish. One attendee talked about utilizing Pester for end-to-end infra checks in opposition to a sandbox sub. That’s precisely the sample.
• Three-layer state. For Terraform on Azure Touchdown Zones, the beneficial break up is: platform touchdown zone (one state), utility touchdown zone / subscription merchandising (one state per touchdown zone), utility workload (one state per workload). By no means collapse all subs into one state file. You’ll remorse it the primary time somebody runs apply on the improper time.

You wouldn’t have to do all of this without delay. Choose the highest-pain merchandise first.

• Nonetheless utilizing consumer secrets and techniques in pipelines? Repair that this dash. Wire up OIDC and a user-assigned managed id.
• Drifting per-environment folders? Consolidate to at least one module plus per-env param information.
• Writing your personal storage account module for the fifth time? Attempt the matching AVM module from the registry.
• Put approvals on the Service Connection (ADO) or Atmosphere (GitHub) for prod.
• Add linting and pre-commit hooks.
• Break up plan and apply identities.
• Layer your Terraform state.

It’s a roadmap, not a weekend undertaking. Each step pays again the second you’re taking it.

This session was considered one of many on the Microsoft Azure Infrastructure Summit 2026. If you’d like the keynotes, the Bicep deep dives, the AKS classes, and the storage observe, the complete playlist is right here:

Microsoft Azure Infra Summit 2026 playlist

Cheers!

Pierre Roman