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, every property it declares has one agreed value — and where the environment has wandered, redeploying the file pulls those properties back into line. (What the file does not mention, a default deployment leaves alone; §4 returns to that boundary.) 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.

The decorators — the @-prefixed lines above a parameter — are worth a second look, because they turn a parameter from a hole anyone can fill into a contract the file enforces. @allowed restricts the value to a fixed set, so a typo like Standard_LSR fails at compile time rather than deploying something wrong. @minLength and @maxLength bound a name or an array; @description documents the input for the next engineer and for the auto-generated parameter form. The one that matters most in production is @secure(): mark a string or object parameter secure and its value is kept out of deployment logs and history, which is the difference between a password that lives for a deploy and a password that lives forever in a log file. Decorators are how a Bicep file stops trusting its caller to be careful and starts refusing bad input on its own — the same instinct as the branch protection of Class Nineteen, moved into the template.

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.

The shape to hold in your head is a module as a function: parameters go in the top, resources are built inside, and outputs come out the bottom for the next module to consume. Figure 1 draws that interface, and the wiring between two modules that lets Bicep work out the order by itself.

Modules do not have to live beside the file that calls them. A team that has built a good vnet.bicep can publish it to a registry — a container registry Azure treats as a module store — and every project then references it by name and version, the same way code depends on a versioned library. That versioning is the point: pin br:campux.azurecr.io/bicep/vnet:1.2.0 and a fix to the module ships as 1.3.0 that no project inherits until it chooses to. One reviewed network module, versioned and shared, becomes the way an organisation stops re-solving subnetting in every repository — which is the same reuse argument as the modules themselves, told one level up.

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 \
    --mode Complete

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.

The flag on the last line of that command deserves a paragraph of its own, because it decides whether delete lines can appear at all. Deployments run in incremental mode by default: resources you add or change are applied, but a resource you remove from the file is simply left running — unmanaged, unmentioned, and still on the invoice. The file stops describing it; Azure does not touch it. Delete lines like campuxtemp appear only in complete mode, where the template is the whole truth and anything absent from it is removed — or under deployment stacks, the newer mechanism built to manage exactly this lifecycle. Know which mode a pipeline runs before you trust its preview: an incremental what-if that shows no deletes is not promising your resources are safe. It never looked.

Trust the preview, but not blindly. what-if is a best-effort comparison, and it has known rough edges: it occasionally reports a property as changing when nothing meaningfully will — "noise" from fields the provider normalises or fills in server-side — and for a handful of resource types it cannot see far enough to predict a change perfectly. Read it the way a pilot reads weather radar: a strong signal of what is coming, not a guarantee of every gust. The delete lines and the large modifies are reliable and are the ones that matter; the occasional spurious ~ on a tag or a computed field is worth learning to recognise rather than fear. The habit the tool builds is the valuable part — that no change reaches production without a human first reading a description of it — and that habit survives the tool's imperfections intact.

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.

Scopes also compose, which is what makes that whole-footprint deployment possible from one entry point. A file at 'subscription' scope creates the resource group, then calls a module and hands it that group as its scope: — the module runs at resource-group scope and fills the group the parent just made, all in a single deployment. So the levels are not four separate worlds you deploy in turn; they nest, exactly like the Class Seven hierarchy, and a parent deployment can reach down a level through a module. This is why "the whole environment from an empty subscription" is not a slogan: one subscription-scope main.bicep can declare the groups, then compose the resource-group-scope modules that populate each one, and what-if previews the entire chain before a single resource exists. The file is not just the truth about one storage account; it can be the truth about the estate.

So far every resource in the file has been written out once, by hand. Real estates are rarely that tidy. Campux's vnet.bicep declares three subnets — app, data, and management — and copy-pasting a subnet block three times is exactly the repetition that lets one of the three drift out of step with the other two. Bicep answers with a loop: describe the shape once, list the things that vary, and let the language stamp out the rest.

// vnet.bicep — three subnets from one description
param subnets array = [
  { name: 'app',  prefix: '10.20.1.0/24' }
  { name: 'data', prefix: '10.20.2.0/24' }
  { name: 'mgmt', prefix: '10.20.3.0/24' }
]

resource vnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: 'vnet-campux'
  properties: {
    addressSpace: { addressPrefixes: [ '10.20.0.0/16' ] }
    subnets: [for s in subnets: {
      name: s.name
      properties: { addressPrefix: s.prefix }
    }]
  }
}

The [for s in subnets: { ... }] reads as "one of these for every entry in the array." Adding a fourth subnet is now a one-line edit to data, not a copy of a block — and because the shape is written once, all four subnets are guaranteed to share it. You can loop over a count as easily as a list: [for i in range(0, 3): ...] stamps out three of something numbered 0 to 2, which is how you would build a fixed pool of identical VMs. The loop belongs to the thing that varies; the description stays single and reviewable.

Its partner is the condition. Not every environment wants every resource — dev does not need the jump host that production locks itself behind, and paying for one idle in dev is money set on fire monthly. An if makes a resource conditional on a parameter, so the same file builds the right shape for each environment instead of forking into three near-identical templates that drift apart.

// a bastion in every environment except dev
param environment string

resource bastion 'Microsoft.Network/bastionHosts@2023-09-01' = if (environment != 'dev') {
  name: 'campux-bastion'
  location: location
  // ...properties
}

One file, three environments, and the difference between them stated as data rather than duplicated as code. This is the same instinct as the parameter of §2, pushed one step further: the loop and the condition let a single reviewed template describe a family of environments, which is what turns "build me a staging copy" from a project into a flag.

Point at it without owning it.

The last piece of authoring is the existing keyword, and it fixes a specific trap. Sooner or later your file needs to refer to a resource it did not create and must not manage — the shared Key Vault the platform team owns, or a VNet already built by another module. Declare that resource normally and Bicep will try to bring it under this file's control, and the next deploy will attempt to overwrite settings that are not yours to touch. Marking it existing tells Bicep the opposite: look this up, let me read from it, but leave it alone.

// read the shared VNet's id without managing it
resource hub 'Microsoft.Network/virtualNetworks@2023-09-01' existing = {
  name: 'vnet-campux-hub'
}

// use hub.id to peer or attach — but never change it
output hubId string = hub.id

The existing resource has no properties block because you are not declaring a desired state — you are borrowing a reference. It appears in no what-if line, because your file changes nothing about it. This is how one team's Bicep wires cleanly into another team's infrastructure: read the id you need, attach to it, and never let your file drift a resource that belongs to someone else. Ownership stays where it should, and the boundary is legible in the source.

A Bicep file that compiles is not the same as a Bicep file that is safe. The compiler checks that your syntax is legal; it does not check that you left an unused parameter behind, put a secret where anyone can read it, or gave a password a hardcoded default. That second layer of judgement is the linter — a set of rules the Bicep tooling runs automatically, in your editor as you type and again when the file builds, flagging the mistakes that pass the compiler but fail a careful review.

The rules are named and specific, and worth knowing by name because they are the review comments you would otherwise wait for a colleague to write. no-unused-params catches a parameter nobody reads — usually the fossil of a deleted resource. outputs-should-not-contain-secrets stops you handing a password back through an output, where it lands in deployment history in plain sight. secure-parameter-default refuses a default value on a @secure() parameter — because a default sits in the file, and a secret in the file is the exact leak §2 warned about. The linter will not catch every careless secret, so it is a floor and not a ceiling; but it enforces the same instinct the whole class runs on — that the reviewable file is the last place a credential should live — and it does it before a human has to.⁴

Which rules fire, and whether each is a quiet note or a build-breaking error, is decided by a single file: bicepconfig.json. Drop one in a folder and every Bicep file at or below it inherits its settings; the nearest file up the tree wins, so a repository can set a strict baseline and a subfolder can relax one rule without arguing with the rest.

// bicepconfig.json — govern the linter for the whole repo
{
  "analyzers": {
    "core": {
      "rules": {
        "no-unused-params": { "level": "warning" },
        "secure-parameter-default": { "level": "error" },
        "outputs-should-not-contain-secrets": { "level": "error" }
      }
    }
  }
}

Each rule takes a level of off, info, warning, or error — and error is the setting that earns its keep, because a rule set to error fails the build, which fails the pull request check, which means the mistake never merges. That is the whole arc of the last four classes closing: a standard the team agreed on, written down, and enforced by a machine on every change rather than remembered by whoever happens to review. The same file is also where you register the registry aliases from §3, so br/campux:vnet:1.2.0 resolves to your ACR without spelling the full path each time. One config file, checked into the repository, is how a Bicep estate stops depending on everyone being careful and starts being careful by default.