Whats up People!
In case your IaC repo has a dev folder, a take a look at folder, and a prod folder that each one began out similar and have since drifted in three totally different instructions, this session is for you. On the Microsoft Azure Infrastructure Summit 2026, Jack Tracey and Jared Holgate (the crew behind Azure Touchdown Zones and Azure Verified Modules) laid out, in plain language, the right way 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 below 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 identification.
So this session is squarely in your lane. It covers:
- Why hand-rolled modules are slowly turning into an anti-pattern on Azure.
- A repo format that scales to dozens of environments with out copy-paste.
- Easy methods to do away with static shopper secrets and techniques and federated cert auth, for good.
- The place approvals truly have to dwell 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 figuring out snigger from anybody who has been doing this for greater than a yr. You begin with one repo, one Bicep file, one comfortable crew. Eighteen months later, you’ve gotten 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 method twice.
- Per-environment folders that diverge silently over time.
- Lengthy-lived secrets and techniques and certificates sitting in pipeline variables.
- One identification doing each plan and apply, with Proprietor on the administration group.
- No approvals, or approvals within the flawed 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 properly understood. The session walks via them within the order you’d truly undertake them.
That is greatest apply primary, and Jack and Jared spent a full chapter on it for a motive. Azure Verified Modules (AVM) is the official Microsoft initiative that consolidates IaC modules for Azure right into a single, supported, Properly-Architected-aligned library, accessible in each Bicep and Terraform. The Bicep variations dwell within the Public Bicep Registry beneath the avm/ namespace. The Terraform variations dwell on the HashiCorp Terraform Registry beneath Azure/avm-*.
What you get without spending a dime while you eat an AVM module:
- Defaults that line up with the Properly-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 assessment the diff earlier than upgrading.
- Deployment checks on each module, run by the AVM crew.
- An actual Microsoft help path, not a random GitHub subject.
An ideal backchannel query got here up about brownfield. Jared’s reply: AVM is simply customary IaC, no particular tooling. In Bicep, brownfield adoption is simple as a result of there isn’t any state. In Terraform, the brand new import blocks make it much less painful than it was.
Repo format is the place most groups go flawed, and the repair is easy. It is best to have one set of module code, and per-environment variations must be expressed as information, not as duplicated code. In Bicep, meaning a single major.bicep and one .bicepparam file per setting. In Terraform, the identical major.tf with one .tfvars file per setting.
If you end up copying a module folder to dev, take a look at, and prod, cease. Inside six months these three folders won’t look the identical, and at that time you not have IaC, you’ve gotten three handwritten environments that occur to be checked into Git.
This was the chat spotlight. The query got here in: “So briefly, substitute all service principals with credential secrets and techniques with user-assigned managed identification?” Jack and Jared each replied inside seconds: sure, 10 factors to you.
Workload Identification Federation (OIDC) lets your GitHub Actions or Azure DevOps pipeline alternate a short-lived token from its personal OIDC supplier for a Microsoft Entra ID token. No shopper 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:setting:prod fashion claims; Azure DevOps makes use of sc://org/challenge/connection. Choose the appropriate one or auth silently fails.
- Use a user-assigned managed identification because the goal. It survives the pipeline being deleted and offers 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 identification 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. Cut up them into two identities, federated to 2 totally different levels of your pipeline, and you’ve got an actual least-privilege story to take to your safety crew.
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 by way of the job_workflow_ref declare on GitHub or required template checks on Azure DevOps. If somebody forks the workflow, the OIDC alternate refuses to subject 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 will be bypassed by a intelligent YAML writer. The Service Connection approval can not.
- Shift left, arduous. 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 take a look at environments spun up per PR and torn down on the finish. One attendee talked about utilizing Pester for end-to-end infra checks towards a sandbox sub. That’s precisely the sample.
- Three-layer state. For Terraform on Azure Touchdown Zones, the advisable break up is: platform touchdown zone (one state), software touchdown zone / subscription merchandising (one state per touchdown zone), software 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 flawed time.
You shouldn’t have to do all of this directly. Choose the highest-pain merchandise first.
- Nonetheless utilizing shopper secrets and techniques in pipelines? Repair that this dash. Wire up OIDC and a user-assigned managed identification.
- Drifting per-environment folders? Consolidate to at least one module plus per-env param information.
- Writing your individual storage account module for the fifth time? Strive 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.
- Cut up plan and apply identities.
- Layer your Terraform state.
It’s a roadmap, not a weekend challenge. 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
