"An architect who clicks through the portal to deploy production infrastructure is not an architect — they are a technician with admin rights. Architects define infrastructure as code: repeatable, reviewable, auditable, reversible."
The Blueprint Analogy
ARM Templates vs Bicep — Same Engine, Different Languages
ARM (Azure Resource Manager) is the deployment engine that processes all Azure resource deployments. ARM Templates are JSON files describing desired state. Bicep is a domain-specific language that compiles to ARM JSON — not a new deployment engine, but a better syntax for the same engine.
BICEP EXAMPLE: Deploy a Storage Account
param storageAccountName string
param location string = resourceGroup().location
param sku string = 'Standard_LRS'
resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: sku
}
}
output storageId string = sa.id
Equivalent ARM JSON: ~60 lines including schema headers,
dependsOn arrays, apiVersion metadata, and nested property objects.
Bicep compiles this to valid ARM JSON automatically.
CI/CD Pipeline for Infrastructure
IaC is only as good as its deployment pipeline. Ad-hoc deployments from a developer laptop defeat the purpose of version-controlled infrastructure. The architect designs a pipeline that enforces review, validation, and approval before any infrastructure change reaches production.
INFRASTRUCTURE CI/CD PIPELINE
1. Developer commits Bicep changes to feature branch
|
2. Pull Request created -- PR triggers:
- Bicep lint (syntax check)
- Bicep what-if (preview changes -- what will be created/modified/deleted)
- Security scan (detect exposed secrets, policy violations)
|
3. Code review by second engineer (required approver)
|
4. Merge to main -- triggers:
- Deploy to STAGING environment automatically
- Integration tests run against staging
|
5. Manual approval gate (designated approver)
Blocks pipeline until someone explicitly approves
|
6. Deploy to PRODUCTION
|
7. Post-deployment: smoke tests + monitoring alert check
Template Specs and Deployment Stacks
As IaC matures in an organisation, two Azure-native features enable enterprise governance of templates:
Template Specs: Store your Bicep/ARM templates in Azure as versioned, RBAC-controlled artefacts. Instead of each team managing their own template files, they reference a shared Template Spec. You control who can deploy which version via RBAC.
TEMPLATE SPEC WORKFLOW
Infrastructure team publishes:
Template Spec: "StandardWebApp" v2.0
Location: Azure Resource Group "templates-rg"
Access: Development teams have Reader + Deploy rights
|
Each development team deploys by referencing:
az deployment group create
--template-spec /subscriptions/.../templateSpecs/StandardWebApp/versions/2.0
All teams get identical, approved infrastructure.
Infrastructure team controls the blessed version.
No team maintains their own copy of the template.
Deployment Stacks: Manages a group of resources as a single unit. When you update a stack, added resources are created, changed resources are updated, and removed resources are deleted (based on policy). Prevents configuration drift — the stack IS the definition of what should exist.
Workload Identity Federation — Keyless CI/CD
Traditionally, CI/CD pipelines authenticate to Azure using a Service Principal with a client secret stored in the pipeline's secret store. Workload Identity Federation / OIDC eliminates secrets entirely.
OIDC KEYLESS AUTH FLOW
1. GitHub Actions workflow runs
2. GitHub generates a short-lived OIDC token for this run
(signed by GitHub, contains: repo, branch, workflow name)
|
3. Workflow exchanges the token with Entra ID
4. Entra ID verifies: "Is this from the trusted GitHub Actions issuer?"
"Does this repo/branch match the configured trust policy?"
|
5. Entra ID issues an Azure access token (valid for 1 hour)
|
6. Workflow uses access token to deploy resources
NO secret ever stored in GitHub.
NO secret to rotate.
NO secret to expire unexpectedly.
Token is usable ONLY from this specific repo + branch.
Architect Scenario — Multi-Client Deployment
You need to deploy the same 15-resource Azure environment (App Service + SQL + Key Vault + Monitor + networking) for 5 different clients. Each client has a different subscription, different naming conventions, and is in a different Azure region. The infrastructure team must be able to update all 5 environments when the standard changes. What is the most maintainable design?
Show Answer + Reasoning
Parameterized Bicep template published as a Template Spec, with a parameter file per client.
Why Template Spec instead of a shared Git repo? Git repos require teams to clone, pull updates, and manage versions themselves. Template Specs are versioned in Azure — you publish v2.1 and reference it. When the infrastructure team publishes v2.1, all clients can upgrade on their schedule by changing the spec version reference. One source of truth, controlled versioning, access via RBAC.
Parameter file per client contains: client name prefix, target region, subscription ID, specific SKU choices. The Bicep template is identical for all clients — only parameters differ.
When the infrastructure standard changes: Infrastructure team updates the Bicep template, publishes as v2.2 of the Template Spec. Each client's pipeline is updated to reference v2.2. No copying of Bicep files. No template divergence between clients.
🎯 Quick Check — Module 4
Q1: Why is Bicep preferred over ARM JSON for new Azure IaC projects?
Show Answer
Bicep has significantly cleaner syntax — a typical ARM JSON template is 5-10x longer than the equivalent Bicep file. Bicep supports first-class modules for reuse and composition. It has full IntelliSense in VS Code with the Bicep extension — type checking and autocompletion prevent mistakes. It compiles to ARM JSON, so it uses the exact same deployment engine with the same capabilities. Bicep is Microsoft's recommended approach for Azure-native IaC.
Q2: What does idempotency mean in IaC and why does it matter for enterprise deployments?
Show Answer
Idempotency means: applying the same template with the same parameters multiple times produces the same result as applying it once. If the storage account already exists with the correct configuration, the deployment verifies it and makes no changes. If configuration has drifted, the deployment corrects it. For enterprise deployments, idempotency means: you can safely re-run deployments to fix drift, run the same pipeline multiple times without side effects, and use deployment as the authoritative source of truth. ARM and Bicep deployments are idempotent by default.
Q3: A CI/CD pipeline currently uses a Service Principal with a client secret stored in Azure DevOps library to deploy infrastructure. What is the more secure modern alternative?
Show Answer
Workload Identity Federation using an Azure DevOps service connection with OIDC. Instead of storing a client secret, Azure DevOps exchanges a short-lived OIDC token with Entra ID at pipeline runtime. No secret is stored anywhere. The token is valid only for the specific pipeline run, automatically expires, and can only be used from the configured Azure DevOps organisation and project. This eliminates secret rotation, secret expiry failures, and secret leak risk.
Key Takeaways — Module 4
- ARM Templates and Bicep use the same deployment engine — Bicep is a cleaner syntax that compiles to ARM JSON; prefer Bicep for new projects
- IaC is only as effective as its pipeline — enforce PR review, what-if preview, and manual approval gates before production deployments
- Template Specs store versioned, RBAC-controlled templates in Azure — the right pattern for standardising infrastructure across teams or clients
- Deployment Stacks manage resource lifecycle as a unit — resources removed from the template are deleted from Azure, preventing orphaned resource drift
- Workload Identity Federation / OIDC is the modern keyless CI/CD authentication pattern — no secrets to store, rotate, or expire
- Idempotency: same template + same parameters = same result every time — the foundation of reliable infrastructure management