Infrastructure as code: Bicep

In the earlier practical classes you have inspected Azure and built selected resources through the portal or CLI — 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.

The payoff is a reviewable record. The file shows the settings the team chose; Git history can explain why they changed; and the same template can deploy to another environment with different parameters. This does not eliminate drift: a portal change can still alter a resource, and a property absent from the file may follow a service default. Rebuilding also requires permissions, data backups, dependencies, and time. Bicep is Azure's declarative language for ARM deployments: you describe resources rather than write each create or update step.² The portal remains useful for inspection and emergency action. Reconcile any emergency change back into code once the incident is contained.

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.

The file declares a desired state rather than a list of steps. Azure Resource Manager compares that declaration with the existing resource and applies the deployment. Repeating the same deployment usually reaches the same declared state, but it can still reapply properties, fail because of permissions or policy, or encounter a changed service default. Review the plan each time. The explicit allowBlobPublicAccess: false makes the Class Twelve security choice visible in a pull request.

The decorators are the @-prefixed lines above a parameter. @allowed restricts inputs to a listed set, @minLength and @maxLength bound values, and @description explains an input to the next engineer. @secure() marks a string or object as sensitive so Azure does not log its value in deployment history; still keep secrets out of source control, command history, outputs, and error messages. These checks catch some mistakes, not every invalid resource setting.

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-bicep-example \
    --template-file main.bicep \
    --parameters namePrefix=campuxlab

Illustrative resource change: 1 to create.

  + Microsoft.Storage/storageAccounts/<generated-name> [create]

The example is illustrative, not a transcript from Azure; create the group before running it. + means create and ~ means modify. In Lab Two, changing a tag should produce a modify entry. A pipeline can run what-if on a PR and show it to a reviewer, but only if the team configures it. Read diagnostics too: Azure may be unable to evaluate part of a deployment.³

This Bicep deployment uses incremental mode. A resource omitted from the file is not deleted merely because you redeploy it; for example, an older campuxtemp account outside this file could remain. Bicep deployments do not use --mode Complete. For managed removal of resources with Bicep, learn deployment stacks and preview their changes separately. A clean incremental preview does not tell you which unmanaged resources can be deleted.

what-if is a prediction, not a guarantee. Some expressions cannot be resolved before deployment; some modules can be omitted from analysis, and computed properties can look changed even when the deployed value will stay the same. Treat an unevaluated or ignored resource as a gap to investigate, not as approval to deploy. Compare the template, parameter values, diagnostics, permissions, and live resource before a consequential change.

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.

// conditional-resource sketch; add required Bastion properties before deployment
param environment string
param location string = resourceGroup().location

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.