Infrastructure as Code — AVM, OIDC, and Deployment Stacks

1. Azure Verified Modules (AVM) as the Building Blocks

The platform team standardizes Azure infrastructure on Bicep modules from the public module registry, especially Azure Verified Modules. AVM provides reviewed module contracts for common Azure resource types, so stack authors compose resource groups, identities, storage, networking, and platform services instead of hand-writing every ARM resource block.

This does not remove engineering judgment. Teams still decide naming, RBAC boundaries, tags, diagnostics, network posture, and lifecycle scope. AVM simply moves the low-level resource shape to a maintained baseline and lets the local stack focus on the platform pattern.

2. The Dual UMI Pattern (control-plane vs data-plane managed identities)

The SPA calls out two suffixes that matter: ctl and dat. A control-plane user-assigned managed identity deploys and updates infrastructure. A separate data-plane user-assigned managed identity is granted runtime access to Key Vault, Storage, Event Hubs, databases, and other workload services.

That separation prevents the deployment identity from becoming a universal runtime credential. It also makes reviews easier: control-plane RBAC answers “what can create or modify resources,” while data-plane RBAC answers “what can read or write workload data.”

3. OIDC Federated Identity (no long-lived secrets in GitHub Actions)

GitHub Actions authenticates to Azure with OpenID Connect federation. The job requests a short-lived token, Microsoft Entra ID validates the federated credential for the repository and environment, and azure/login receives an Azure access token. No client secret is stored in GitHub, copied into a runner, or rotated by hand.

The variables in this excerpt are non-secret identifiers: client ID, tenant ID, and subscription ID. Real tenant IDs and subscriptions are intentionally represented here with Microsoft Learn-style placeholders.

4. Deployment Stacks (vs traditional ARM deployments; deny-settings)

Traditional ARM or Bicep deployments apply a template to a scope, but lifecycle ownership can be ambiguous after the deployment finishes. Azure Deployment Stacks add a management layer around that deployment: Azure knows which resources belong to the stack, what should happen when resources disappear from the template, and whether unmanaged changes should be denied.

Deny settings are the sharp edge. They can block deletes or updates outside the stack, which makes production safer when used deliberately. The design goal is not to make emergencies impossible; it is to make out-of-band changes visible, time-bound, and followed by a PR so desired state catches up to reality.

5. Trunk-Based CI/CD (main = production; feature branches via PR)

The delivery model is trunk-based. Engineers create short-lived feature branches, open pull requests, run validation, and merge through protected gates. The main branch represents production-ready desired state. If a bad change lands, the rollback path is a git revert rather than a hand-built undo script.

This is especially important for infrastructure. Portal edits, local az commands, and workspace clickops all create configuration drift. The governance pattern is simple: exploration can happen in dev, but production writes come from CI/CD using federated identity.

6. Modules, Stacks, and Composition (how main.bicep references AVM)

A stack folder contains the composition root: main.bicep, environment-specific main.{env}.bicepparam files, and optional dashboards or runbooks. The root Bicep file should read like a platform bill of materials. It wires AVM modules together, passes shared tags and naming variables, and exposes only the outputs that downstream workloads actually need.

The pattern keeps local modules rare. If a resource type exists in AVM, use the public registry reference first. If a custom wrapper is necessary, it should encode a platform standard that AVM does not cover, not repackage a single resource for convenience.

CAF Naming Table