1. CI/CD for Infrastructure
Infrastructure as Code (IaC) deserves the same rigor as application code: version control, peer review, automated testing, and gated deployments. Two dominant platforms in the Azure ecosystem:
- Azure DevOps Pipelines — YAML or classic pipelines, native Azure integration, environments with approval gates.
- GitHub Actions — workflow files in
.github/workflows/, reusable actions marketplace, OIDC federation for keyless Azure auth.
2. Pipeline Architecture
3. Terraform at Scale
- Workspaces — isolate state per environment (dev/staging/prod) without duplicating code.
- Remote state — store in Azure Storage with blob lease locking; enable versioning for rollback.
- Modules — reusable, versioned components published to a private registry (Terraform Cloud or Azure Container Registry for Bicep).
- State management — use
terraform state mvfor refactoring; never edit state files manually. - Drift detection — schedule
terraform plannightly; alert on unexpected changes.
source = "registry/module?version=2.1.0" — to prevent unintended upgrades.4. GitOps for AKS
GitOps uses Git as the single source of truth for cluster desired state. An operator running inside the cluster reconciles actual state to match the repo.
- Flux v2 — CNCF project, native AKS extension (
microsoft.flux), supports Kustomize & Helm. - ArgoCD — UI-rich, app-of-apps pattern, multi-cluster support.
- Pull model — cluster pulls config; no inbound network access needed (more secure than push-based CD).
5. Environment Promotion Patterns
- Dev → Staging → Prod — each stage uses its own state file, subscription, or resource group.
- Approval gates — require sign-off before prod deploy (Azure DevOps Environments / GitHub Environment protection rules).
- Canary infra — deploy infra changes to a subset of prod (e.g., one region) before global rollout.
- Rollback strategy — re-apply previous known-good commit; Terraform state enables targeted resource rollback.
6. Infrastructure Testing
| Stage | Tool / Technique | Purpose |
|---|---|---|
| Static | tflint, Bicep linter, checkov | Catch misconfigurations before plan |
| Plan | terraform plan, az deployment what-if | Preview changes without applying |
| Policy | Azure Policy (deny), OPA/Conftest | Guardrails — block non-compliant resources |
| Integration | Terratest, Bicep test framework | Deploy to ephemeral env, validate, destroy |
7. Azure DevOps vs GitHub Actions
| Capability | Azure DevOps Pipelines | GitHub Actions |
|---|---|---|
| Pipeline Definition | YAML (azure-pipelines.yml) or Classic UI | YAML (.github/workflows/) |
| Auth to Azure | Service Connection (SPN / Managed Identity) | OIDC Federated Credential (keyless) |
| Approval Gates | Environments + Approvals & Checks | Environment protection rules |
| Reusable Components | Templates, Task Groups | Reusable Workflows, Actions Marketplace |
| Self-Hosted Runners | Agent Pools (VMSS-backed) | Self-hosted runners (or ACA jobs) |
| Best For | Enterprise, complex multi-stage, Boards integration | OSS, modern teams, tight GitHub integration |
8. Real-World: Platform Team CI/CD for Landing Zone Updates
Scenario: A platform team manages 50+ landing zone subscriptions via Terraform modules. Changes must be safe, auditable, and require zero manual portal work.
- Mono-repo with module folders; each landing zone references versioned module tags.
- PR triggers
terraform planper affected workspace; diff posted as PR comment. - Merge to
maintriggers apply to staging subscriptions first. - After 24 h soak + automated compliance scan (Azure Policy), auto-promote to prod with approval gate.
- Drift detection runs nightly; alerts Slack if actual ≠ desired state.
- Secrets managed via Key Vault; pipeline authenticates with Managed Identity (no stored credentials).
9. Exam Tip
🎯 AZ-305 expects you to recommend what-if / plan before apply patterns, and to know that GitOps uses a pull model (more secure than push). For state locking, know that Azure Storage blob leases prevent concurrent writes. If asked about keyless auth — pick Workload Identity Federation (OIDC) over service principal secrets.