Lesson 13 — Infrastructure as Code: ARM Templates & Bicep

Why Infrastructure as Code Is Non-Negotiable

Every resource you have deployed through the Azure portal can be deleted, misconfigured, or drift from its intended state. In production environments at any serious scale, manual portal operations are an audit failure, a reliability risk, and a velocity bottleneck. Infrastructure as Code (IaC) solves this by encoding your infrastructure in files that can be version-controlled, peer-reviewed, tested, and deployed repeatably — the same way application code is developed.

Azure's native IaC system is built on the Azure Resource Manager (ARM) API. ARM is the control plane that every Azure operation goes through — the portal, the Azure CLI, PowerShell, and REST APIs all translate their requests into ARM API calls. ARM templates and Bicep are declarative languages that describe what resources you want; ARM figures out how to create or update them.

ARM Template Structure (JSON)

An ARM template is a JSON file with a defined schema. Every valid ARM template must contain $schema, contentVersion, and resources. The other sections are optional but frequently used.

ARM template key functions

ARM templates have a rich built-in function library. These are the ones you must know for the exam and for daily use:

Resource Dependencies

ARM deploys resources in parallel by default for speed. When one resource must be created before another, you declare a dependency. There are two mechanisms:

Explicit dependencies — dependsOn

The dependsOn array lists resources by name or resource ID that must be deployed successfully before this resource is started. Use when you need to force ordering but there is no property reference between resources.

Implicit dependencies — reference()

When you use the reference() function to read a property from another resource, ARM automatically infers a dependency — it knows it must deploy the referenced resource first. Implicit dependencies via reference() are preferred when applicable: they make the dependency self-documenting and are less fragile than string-based dependsOn.

Deployment Modes: Incremental vs. Complete

Every ARM deployment has a mode that controls what ARM does with resources in the resource group that are not in the template.

Incremental mode (default)

ARM deploys the resources in the template. Resources in the resource group that are not in the template are left unchanged. This is the safe default — you can deploy a partial template without risk of deleting resources that are managed by other templates or were created manually.

Complete mode

ARM deploys the resources in the template, then deletes any resources in the resource group that are NOT in the template. Complete mode enforces the desired state — the resource group will exactly match what the template describes after deployment.

What-If Deployment

The what-if operation previews what changes an ARM deployment would make without executing any of them. It shows each resource that would be created, modified, deleted, or remain unchanged. Think of it as a dry run.

Running what-if from Azure CLI:

az deployment group what-if \
  --resource-group rg-example-prod \
  --template-file main.bicep \
  --parameters @params.prod.json

The output classifies each resource into one of four categories:

• Create: resource does not exist and will be created
• Modify: resource exists and one or more properties will change. Shows the before/after property diff.
• Delete: resource exists but is not in the template — will be deleted (Complete mode only)
• No change: resource exists and template matches current state exactly
• Ignore: resource exists but ARM will not manage it (e.g. extension resources)

Bicep: The Preferred IaC Authoring Language for Azure

Bicep is Microsoft's domain-specific language for Azure infrastructure. It compiles directly to ARM JSON — it is not a wrapper or an abstraction over ARM, it IS ARM, with a much cleaner syntax. Bicep is the recommended authoring experience; ARM JSON is the wire format that gets sent to the ARM API.

Why Bicep instead of ARM JSON?

• No $schema declarations, no quotation marks around identifiers, no explicit dependsOn when using symbolic references.
• Native type system with IntelliSense in VS Code (Bicep extension).
• String interpolation: '${prefix}-${uniqueString(resourceGroup().id)}' instead of concat(parameters('prefix'), '-', uniqueString(resourceGroup().id)).
• Modules: reusable Bicep files with inputs and outputs. Compose large deployments from smaller, tested units.
• Loops and conditional deployment with clean syntax.
• Compile to ARM JSON for sharing with teams not using Bicep.

Bicep keywords

Symbolic references replace reference()

In ARM JSON, accessing a property of another resource requires the verbose reference('resourceName').properties.xxx function call. In Bicep, you use the resource's symbolic name directly: storageAccount.properties.primaryEndpoints.blob. Bicep infers the dependency automatically — no dependsOn required.

Conditional deployment

Deploy a resource only if a condition is true:

param deployStorage bool = true

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = if (deployStorage) {
  name: 'mystorage${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Loops

Deploy multiple resources from a single definition:

param storageNames array = ['logs', 'data', 'archive']

resource storageAccounts 'Microsoft.Storage/storageAccounts@2023-01-01' = [for name in storageNames: {
  name: '${name}${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}]

Side-by-Side: Bicep vs. ARM JSON

Both of the following examples deploy a storage account with a configurable name prefix and SKU. They are functionally identical — the Bicep compiles to ARM JSON that is nearly identical to the handwritten ARM JSON version.

Bicep — minimal storage account module

@description('Prefix for the storage account name')
param namePrefix string = 'contoso'

@description('Storage SKU')
@allowed(['Standard_LRS', 'Standard_GRS', 'Standard_ZRS', 'Premium_LRS'])
param storageSku string = 'Standard_LRS'

var storageAccountName = '${toLower(namePrefix)}${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: resourceGroup().location
  sku: {
    name: storageSku
  }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
}

output storageAccountId string = storageAccount.id
output blobEndpoint string = storageAccount.properties.primaryEndpoints.blob

ARM JSON — equivalent template

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "namePrefix": {
      "type": "string",
      "defaultValue": "contoso",
      "metadata": { "description": "Prefix for the storage account name" }
    },
    "storageSku": {
      "type": "string",
      "defaultValue": "Standard_LRS",
      "allowedValues": ["Standard_LRS", "Standard_GRS", "Standard_ZRS", "Premium_LRS"],
      "metadata": { "description": "Storage SKU" }
    }
  },
  "variables": {
    "storageAccountName": "[concat(toLower(parameters('namePrefix')), uniqueString(resourceGroup().id))]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-01-01",
      "name": "[variables('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": { "name": "[parameters('storageSku')]" },
      "kind": "StorageV2",
      "properties": {
        "minimumTlsVersion": "TLS1_2",
        "allowBlobPublicAccess": false,
        "supportsHttpsTrafficOnly": true
      }
    }
  ],
  "outputs": {
    "storageAccountId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
    },
    "blobEndpoint": {
      "type": "string",
      "value": "[reference(variables('storageAccountName')).primaryEndpoints.blob]"
    }
  }
}

Bicep Modules

A Bicep module is a reusable Bicep file that accepts parameters and returns outputs. Modules are the primary mechanism for composing large deployments from smaller, tested components — a platform team can publish a "blessed" storage module that enforces corporate defaults (TLS 1.2, no public access, soft delete enabled) and application teams consume it without needing to know or replicate those settings.

Calling a module from a parent Bicep file:

module storage './modules/storage.bicep' = {
  name: 'storageDeployment'
  params: {
    namePrefix: 'payments'
    storageSku: 'Standard_GRS'
  }
}

// Consume the module's output
output blobUri string = storage.outputs.blobEndpoint

Modules can also be referenced from a Bicep Registry (a private module registry hosted in ACR) or the public Bicep Registry on GitHub — enabling teams to share vetted modules across the organisation.

Template Specs and Azure Deployment Stacks

Template Specs

Template Specs store versioned ARM templates or compiled Bicep files as first-class Azure resources with their own resource ID. They live in a resource group and support RBAC — you can give a team permission to deploy a Template Spec without giving them access to the source code in your Git repository.

Benefits: versioned history of approved templates, RBAC-controlled access for deployment, no local file needed to deploy (reference the spec by resource ID), deployable from the portal, CLI, or pipelines.

Azure Deployment Stacks

Azure Deployment Stacks are a newer mechanism that groups related resources (potentially across multiple resource groups or subscriptions) into a managed unit with a lifecycle. Key capabilities:

• Unified lifecycle: create, update, and delete all managed resources together as a stack.
• Deny settings: the stack can apply a deny assignment to prevent modification of managed resources outside the IaC pipeline — ensuring infrastructure drift is impossible without going through the approved deployment process.
• Detach or delete on update: when a resource is removed from the stack template, you can configure whether it is deleted or simply detached (unmanaged but not deleted).
• Deployment Stacks are the strategic replacement for Azure Blueprints, which is deprecated.