AzureFeeds

Hello Folks!

If your IaC repo has a dev folder, a test folder, and a prod folder that all started out identical and have since drifted in three different directions, this session is for you. At the Microsoft Azure Infrastructure Summit 2026, Jack Tracey and Jared Holgate (the team behind Azure Landing Zones and Azure Verified Modules) laid out, in plain language, how to ship Infrastructure as Code on Azure without leaking secrets, blowing up production, or duplicating thousands of lines of module code across folders. Here are the bits that matter most for IT Pros and platform engineers.

📺 Watch the session: 

Why IT Pros Should Care

You are the one paged at 2am when a pipeline rolls out a broken NSG rule. You are the one carrying the cert that the deploy service principal still uses. You are the one explaining to audit why the prod plan and the prod apply ran with the same Owner-scoped identity.

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

• Why hand-rolled modules are slowly becoming an anti-pattern on Azure.


• A repo layout that scales to dozens of environments without copy-paste.


• How to get rid of static client secrets and federated cert auth, for good.


• Where approvals actually need to live in GitHub vs. Azure DevOps so they cannot be bypassed.


• The three-layer Terraform state model that Microsoft uses inside Azure Landing Zones.

In short, this is the practitioner version of “do IaC properly,” from the people who write the platform code Microsoft ships.

The IaC CI/CD problem

Jack opened with a slide that gets a knowing laugh from anyone who has been doing this for more than a year. You start with one repo, one Bicep file, one happy team. Eighteen months later, you have a landingzone-prod-v2-final-USE-THIS-ONE folder, a service principal whose secret expired two days ago, and a pipeline nobody dares touch.

The drivers of that pain are consistent:

• Modules written from scratch, never tested the same way twice.


• Per-environment folders that diverge silently over time.


• Long-lived secrets and certificates sitting in pipeline variables.


• One identity doing both plan and apply, with Owner on the management group.


• No approvals, or approvals in the wrong place.


• No tests until the deploy fails in prod.

The good news is none of these problems are new, and the patterns to fix them are well understood. The session walks through them in the order you would actually adopt them.

Patterns that work in production

1. Don’t write modules. Consume Azure Verified Modules.

This is best practice number one, and Jack and Jared spent a full chapter on it for a reason. Azure Verified Modules (AVM) is the official Microsoft initiative that consolidates IaC modules for Azure into a single, supported, Well-Architected-aligned library, available in both Bicep and Terraform. The Bicep versions live in the Public Bicep Registry under the avm/ namespace. The Terraform versions live on the HashiCorp Terraform Registry under Azure/avm-*.

What you get for free when you consume an AVM module:

• Defaults that line up with the Well-Architected Framework (RBAC over access policies, TLS 1.2, private endpoint support out of the box).


• Semantic versioning so you can pin and review the diff before upgrading.


• Deployment tests on every module, run by the AVM team.


• A real Microsoft support path, not a random GitHub issue.

A great backchannel question came up about brownfield. Jared’s answer: AVM is just standard IaC, no special tooling. In Bicep, brownfield adoption is straightforward because there is no state. In Terraform, the new import blocks make it less painful than it used to be.

2. One folder, one source of truth

Repo layout is where most teams go wrong, and the fix is simple. You should have one set of module code, and per-environment differences should be expressed as data, not as duplicated code. In Bicep, that means a single main.bicep and one .bicepparam file per environment. In Terraform, the same main.tf with one .tfvars file per environment.

If you find yourself copying a module folder to dev, test, and prod, stop. Within six months those three folders will not look the same, and at that point you no longer have IaC, you have three handwritten environments that happen to be checked into Git.

3. Kill static secrets. Use Workload Identity Federation.

This was the chat highlight. The question came in: “So in short, replace all service principals with credential secrets with user-assigned managed identity?” Jack and Jared both replied within seconds: yes, 10 points to you.

Workload Identity Federation (OIDC) lets your GitHub Actions or Azure DevOps pipeline exchange a short-lived token from its own OIDC provider for a Microsoft Entra ID token. No client secrets, no certs to rotate, no Key Vault dance to retrieve them.

A couple of things to know:

• Subject claim format differs by platform. GitHub uses repo:org/repo:environment:prod style claims; Azure DevOps uses sc://org/project/connection. Pick the right one or auth silently fails.


• Use a user-assigned managed identity as the target. It survives the pipeline being deleted and gives you one place to manage role assignments.


• The Azure Bicep Deploy GitHub Action and the official AzureRM / AzAPI Terraform providers all support OIDC natively.

4. Split plan from apply

Even with OIDC, a single Owner-scoped identity that does both terraform plan and terraform apply is a problem. Plan needs Reader (and a few read-data permissions). Apply needs Contributor or Owner depending on what you deploy. Split them into two identities, federated to two different stages of your pipeline, and you have a real least-privilege story to take to your security team.

Securing the pipeline

Auth is half the story. The other half is making sure only the right pipelines, with the right approvals, can use those identities at all.

• Governed templates. Keep reusable pipeline templates in a separate, locked-down repo. Pin federated credentials or service connections to those templates via the job_workflow_ref claim on GitHub or required template checks on Azure DevOps. If someone forks the workflow, the OIDC exchange refuses to issue a token.


• Approvals in the right place. On GitHub, use Environments and require reviewers on prod. On Azure DevOps, put the approval on the Service Connection, not the Environment. The Environment approval can be bypassed by a clever YAML author. The Service Connection approval cannot.


• Shift left, hard. Pre-commit hooks for bicep format and terraform fmt, lint on every PR, GitHub Advanced Security for secret and code scanning, automated tests on PRs, and ephemeral test environments spun up per PR and torn down at the end. One attendee mentioned using Pester for end-to-end infra tests against a sandbox sub. That is exactly the pattern.


• Three-layer state. For Terraform on Azure Landing Zones, the recommended split is: platform landing zone (one state), application landing zone / subscription vending (one state per landing zone), application workload (one state per workload). Never collapse all subs into one state file. You will regret it the first time someone runs apply at the wrong time.

Getting Started

You do not have to do all of this at once. Pick the highest-pain item first.

• Still using client secrets in pipelines? Fix that this sprint. Wire up OIDC and a user-assigned managed identity.


• Drifting per-environment folders? Consolidate to one module plus per-env param files.


• Writing your own storage account module for the fifth time? Try the matching AVM module from the registry.


• Put approvals on the Service Connection (ADO) or Environment (GitHub) for prod.


• Add linting and pre-commit hooks.


• Split plan and apply identities.


• Layer your Terraform state.

It is a roadmap, not a weekend project. Every step pays back the moment you take it.

Resources

• Azure Verified Modules portal. the official AVM home, with module indexes for Bicep and Terraform, specs, and FAQ.


• Azure Verified Modules on GitHub. the tracking repo and source of truth for module proposals.


• Bicep on Microsoft Learn. official language docs, deployment guidance, and references for the public registry.


• Azure Bicep Deploy GitHub Action. the OIDC-friendly action for deploying Bicep from GitHub Actions.


• GitHub Actions for Azure on Microsoft Learn. Workload Identity Federation setup for GitHub Actions targeting Azure.


• Configuring OpenID Connect in Azure (GitHub Docs). the canonical OIDC subject claims and federated credential walkthrough for GitHub.


• Azure Pipelines documentation. service connections, approvals and checks, required templates, and YAML reference.

Watch the rest of the Summit

This session was one of many at the Microsoft Azure Infrastructure Summit 2026. If you want the keynotes, the Bicep deep dives, the AKS sessions, and the storage track, the full playlist is here:

Microsoft Azure Infra Summit 2026 playlist

Cheers!

Pierre Roman