Infrastructure as code: Bicep

For nineteen classes you have built Azure by clicking — a resource group here, a VNet there, a storage account with the right redundancy. It works, and it is exactly how you should have learned. But a portal click leaves almost no trace of intent: six months later, nobody can say why that subnet is a /24, whether the firewall rule was deliberate or a debugging leftover, or how to rebuild any of it if the region burns down. Infrastructure as code is the fix — you describe the desired state of your Azure resources in text files, commit them to the repository, and let a tool make reality match the file.¹

Infrastructure as code

Defining your cloud resources in declarative text — versioned, reviewed, and deployed like software — so that the file is the source of truth and the running environment is its output, not the other way round.

State the payoff as the three things clicking fails to give you. No drift: when the file is authoritative, the environment cannot quietly diverge from what was agreed — and where it has, a deployment pulls it back. No archaeology: the "why" lives in the code and its Git history, so a decision made today is legible in a year instead of being reverse-engineered from a running system under incident pressure. Repeatability: the same file builds dev, test, and prod identically, and rebuilds any of them from nothing — the difference between a nine-hour recovery and a nine-minute one. Bicep is Azure's own language for this: a clean, declarative file that compiles down to the ARM JSON you met in Class Sixteen.² The portal does not stop existing; it stops being the truth. The file is the truth, and the portal becomes one window onto it.

A Bicep file has only a handful of moving parts, and once you can name them the language stops looking foreign. Here is a small but complete file — a storage account, parameterised — with every element you will use ninety percent of the time.

// main.bicep — a parameterised storage account
@description('Azure region for all resources')
param location string = resourceGroup().location

@allowed([ 'Standard_LRS', 'Standard_GZRS' ])
param redundancy string = 'Standard_LRS'

param namePrefix string

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

resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageName
  location: location
  sku: { name: redundancy }
  kind: 'StorageV2'
  properties: { allowBlobPublicAccess: false }
}

output storageId string = storage.id

param

An input you supply at deploy time — the thing that differs between dev and prod. Decorators like @allowed and @description constrain and document it.

var

A value computed inside the file — here, a name built from a prefix and a hash. Not an input; derived once, reused.

resource

The heart of it: a symbolic name, a type@apiVersion, and the properties that describe the desired state. This is the ARM resource of Class Sixteen, written cleanly.

output

A value the deployment hands back — an id, a hostname — so the next file or pipeline step can use it without guessing.

Notice what the file is: a declaration of the end state, not a script of steps. You do not tell Bicep "if the account is missing, create it, otherwise update the SKU" — you state the account you want and Bicep works out the difference. That declarative nature is the whole point, and it is why the same file is safe to run a hundred times. Notice too allowBlobPublicAccess: false sitting right there in the source: the security decision from Class Twelve is now reviewable in a pull request, not buried in a portal blade nobody revisits.

One file describing one storage account is a toy. Real infrastructure is dozens of resources, and cramming them into a single thousand-line file is the Bicep equivalent of a nine-hundred-line pull request — unreviewable and fragile. The answer is modules: a Bicep file can call another Bicep file the way a program calls a function, passing parameters in and receiving outputs back.

// main.bicep — composes reusable modules
param location string = resourceGroup().location

module network './modules/vnet.bicep' = {
  name: 'networkDeploy'
  params: {
    location: location
    addressSpace: '10.20.0.0/16'
  }
}

module storage './modules/storage.bicep' = {
  name: 'storageDeploy'
  params: {
    location: location
    subnetId: network.outputs.appSubnetId   // one module feeds the next
  }
}

Read what that composition buys you. Each module is a small, self-contained file you can review, test, and reuse — the VNet module that builds Campux's 10.20.0.0/16 can be the same one a future project calls with different numbers. The network.outputs.appSubnetId line is the important trick: Bicep sees that storage depends on an output of network, so it works out the deployment order for you — network first, storage second — without you writing a single "do this before that" instruction. This is the same lesson as short-lived branches, one layer down: compose the system from small pieces that each fit in a reviewer's head, and let the tool handle how they join. A repository of well-named modules is what turns Class Seven's tenant sketch and Class Ten's VNet from diagrams into a platform that rebuilds itself on command.

Declarative code has one frightening property: you describe an end state, hand it to Azure, and trust it to work out the steps. The first time you deploy a change to a live environment, "trust it" is not good enough — you want to see, before anything happens, exactly what will be created, changed, or deleted. Bicep gives you that preview with what-if.

$ az deployment group what-if \
    --resource-group rg-campux-prod \
    --template-file main.bicep

Resource changes: 1 to create, 1 to modify, 1 to delete.

  + Microsoft.Storage/storageAccounts/campuxlogs   [create]
  ~ Microsoft.Network/virtualNetworks/vnet-hub     [modify]
      addressSpace.addressPrefixes: ["10.20.0.0/16"] => ["10.20.0.0/20"]
  - Microsoft.Storage/storageAccounts/campuxtemp    [delete]

Read that output like a pilot reads a checklist, because the symbols are the whole story: + creates, ~ modifies, and - deletes. That delete line is why what-if exists. A parameter typo that shrinks an address space or drops a resource looks harmless in the source and catastrophic in production, and this preview is where you catch it — before, not after. In a real pipeline the what-if runs automatically on every pull request and its output is posted for a human to read, so approving the PR means approving a named list of changes rather than a hopeful guess.³ It is the same instinct as reviewing a diff: never change what you have not first seen described.

One last thing decides where a Bicep file acts. A file that creates a storage account runs against a resource group; a file that creates the resource groups themselves has to run one level up. That level is the deployment scope, declared with targetScope and matched by the command you run.

The file is the truth.

The mental model is the hierarchy from Class Seven, now made operational: you deploy at a level to create things that live at that level. Most of your day is 'resourceGroup' — it is the default, so you rarely write it. You reach for subscription scope on the day you want the resource groups themselves in code rather than clicked into being, which is exactly what Build I asked you to govern by hand. A subscription-scope file can create an RG and, in the same deployment, hand off to a module that fills it — the whole environment, from empty subscription to running platform, described in one reviewable place. That is the destination of this class: not a storage account written in Bicep, but an entire Azure footprint that lives as text.