Infrastructure as code: Terraform

Ada’s colleague creates the test storage account. Ada’s configuration describes the same account, but her local records do not say it already exists. “Why is it trying to create another one?” she asks. Terraform needs a record connecting the resource in configuration to the resource in Azure. That record is state. Once two engineers use it, keeping that record shared and protecting simultaneous changes becomes part of the job.

Terraform state

Terraform's own record of the resources it manages — the mapping from each resource block in your code to the real cloud resource it created, with its last-known attributes. Code says what you want; the cloud is what exists; state is how Terraform knows which is which.

Why carry that third thing at all? Because it buys Terraform its defining trait: it is not married to Azure. ARM can be the bookkeeper for Azure resources because ARM is Azure. Terraform manages Azure, AWS, GCP, GitHub, and a few thousand other platforms through plug-in providers, and no single cloud can keep books for all of them — so Terraform keeps its own. The price of that independence is that the books must be looked after. Lose the state file and Terraform forgets everything it built; corrupt it and Terraform's picture of the world goes wrong in ways that surface as baffling plans. Most of what beginners find strange about Terraform stops being strange the moment you hold one sentence: there are three things — the code, the cloud, and the ledger between them.

Terraform files are written in HCL — HashiCorp Configuration Language — and once you have read Bicep, most of it is recognisable at a squint. Here is the Campux VNet from Class Ten, deliberately the same network you wrote in Bicep last class, so the comparison is felt rather than read.

# main.tf — the same VNet, second language
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 5.0"
    }
  }
}

provider "azurerm" {
  features {}
}

variable "resource_group_name" {
  type = string
}

data "azurerm_resource_group" "platform" {
  name = var.resource_group_name
}

resource "azurerm_virtual_network" "hub" {
  name                = "vnet-hub"
  location            = data.azurerm_resource_group.platform.location
  resource_group_name = data.azurerm_resource_group.platform.name
  address_space       = ["10.20.0.0/16"]
}

output "vnet_id" {
  value = azurerm_virtual_network.hub.id
}

provider

The plug-in that teaches Terraform a platform's API — azurerm for Azure resources, with siblings for Entra ID, AWS, GitHub. Pinning its version is not optional politeness; providers change behaviour between major versions.²

resource

A thing Terraform creates and manages — a type, a local name, and the desired settings. The Bicep resource block wearing different clothes.

data

A thing Terraform reads but does not manage — here, an existing resource group. Data sources are how your code references infrastructure that belongs to someone else without taking ownership of it.

variable / output

Inputs you supply and values handed back — the same in-and-out flow as Bicep's param and output, so the mental model carries straight across.

The distinction worth pausing on is resource versus data. Marking something as a resource means Terraform owns it — it enters the state, and removing the block from your code means Terraform plans to destroy the real thing. A data source carries no such ownership. Mixing the two up is how teams accidentally schedule the deletion of a resource group somebody else built; the code reads almost identically, and the consequence does not.

The example already declares a resource_group_name variable. You can set input values with environment variables such as TF_VAR_resource_group_name, CLI arguments, or a terraform.tfvars file. Keep credentials out of values committed to Git. Here is a separate location example:

# variables.tf — declare the input; reference it as var.location
variable "location" {
  type    = string
  default = "eastus"
}

# terraform.tfvars — one line, and the default gives way
location = "westus2"

With the default local backend, terraform apply writes terraform.tfstate beside your code. That is useful for a solo lab, but teammates need one protected, shared state for the same infrastructure. A remote backend stores it centrally. On Azure, a storage account can hold the state blob:

# backend.tf — the ledger moves to shared storage
terraform {
  backend "azurerm" {
    resource_group_name  = "rg-tfstate"
    storage_account_name = "campuxtfstate"
    container_name       = "tfstate"
    key                  = "platform.tfstate"
    use_azuread_auth     = true
  }
}

use_azuread_auth = true asks the backend to use Microsoft Entra identity for blob data. It does not grant access by itself: the learner or pipeline identity needs the Storage Blob Data Contributor role on the container or storage account. The AzureRM provider's permissions to manage Azure resources are separate from backend permissions to read and write state.

Two properties matter. Locking: the Azure blob backend takes a lease for an operation that could write state. A second operation cannot write concurrently; without a configured wait it may return a lock error, while -lock-timeout can wait for the lock. Confidentiality: state is JSON that can contain sensitive resource attributes. Keep state and its backups out of Git, restrict blob access, enable recovery controls on the storage account, and exclude *.tfstate, *.tfstate.*, and .terraform/ from commits. A remote backend can still write a local recovery copy if a state write fails.

Guard the ledger like a credential.

The working rhythm of Terraform is two commands. terraform plan is the sibling of Bicep's what-if: it refreshes its picture of the cloud, compares code against state against reality, and prints exactly what it intends to do. terraform apply does it. The symbols carry the same weight they did last class, plus one that is new and dangerous:

$ terraform plan
azurerm_virtual_network.hub: Refreshing state...

  ~ update in-place
  ~ resource "azurerm_virtual_network" "hub" {
        name          = "vnet-hub"
      ~ address_space = ["10.20.0.0/16"] -> ["10.20.0.0/20"]
    }

Plan: 0 to add, 1 to change, 0 to destroy.

+ creates, ~ updates in place, - destroys — and a fourth, -/+, means destroy and recreate. Some properties cannot be changed on a live resource, so Terraform's honest plan is to delete the old one and build a replacement; for a stateless network that is an interruption, for a database it is data loss. Read every -/+ twice before you type yes.

A normal plan can also expose drift. Suppose someone changes a VNet tag in the portal. Terraform refreshes the VNet it manages, then may propose a change to return the tag to what the configuration declares. Read the refresh note and the proposed action separately. An empty plan is useful evidence for resources and attributes Terraform manages; it is not proof that every Azure resource or security setting in the subscription matches the repository. Unmanaged resources and ignored attributes need other checks.

The working rhythm is four verbs, and you have already run two. init prepares a folder before anything else can happen: it reads your terraform block, downloads the providers your code names into a hidden .terraform directory, and wires up the backend from §3. You run it once per folder, and again whenever you add a provider or change where state lives — forget it and every other command refuses to start. apply builds. destroy is apply read backwards: it deletes exactly what state says Terraform owns, in the reverse of the order it built them, and asks first. For Campux that reverse order is not a nicety — a subnet cannot be removed while a VM still sits inside it, and Terraform tears down the VM first without being told to.

init

Prepares the folder — downloads the declared providers, configures the backend. Runs once per folder, and again after any provider or backend change. Nothing else runs until it has.

plan

The three-way comparison from §4, printed and nothing more. Changes no infrastructure; the safe command to run a hundred times a day.

apply

Applies a reviewed plan in dependency order, normally asking for confirmation. Other commands, including destroy and state operations, can also write; check the command and target before running it.

destroy

The ledger read in reverse — deletes what state owns, children before parents, after a confirmation. What it will remove is exactly what plan would have listed.

Knows to delete the VM first how? This is the quiet cleverness of the tool. When one resource references another's attribute — the VNet's id, the resource group's name — Terraform records that reference as an edge in a dependency graph and works out the safe order itself. You almost never write "build this before that." You write the references, and the order falls out of them. Declare a subnet that names its parent VNet and Terraform creates the VNet first, every time, across a hundred resources, without a single line of ordering from you. These are implicit dependencies, and they are most of the reason HCL reads as a description of a system rather than a script that assembles one.

Implicit dependency

An ordering Terraform infers because one resource's configuration references another's attribute. The reference both passes the real value along and tells Terraform which resource must exist first — so correct ordering is a free side effect of writing honest references.

Sometimes, though, A must exist before B and nothing in B's code mentions A. The textbook case: a role assignment has to be in place before an app can read a secret from Key Vault, yet the app's resource block never references the role assignment — the dependency is real in Azure and invisible in the code. For exactly that gap there is depends_on = [azurerm_role_assignment.app], which hands Terraform the edge it could not infer. Reach for it rarely and on purpose: most "I need depends_on" moments are really a missing reference you could add instead, and an honest reference is always the better fix because it carries a value as well as an order. An explicit depends_on that could have been a reference is a small confession that the code is not saying everything it knows.

Write the references; the order is Terraform's problem.

Four constructs remain, and each is a place where the portal-trained engineer and the Terraform-fluent one visibly part ways. None is exotic; all of them decide how much breaks on an ordinary Tuesday.

count versus for_each

Both build many copies of a resource from one block; the difference is how Terraform remembers each copy, and that decides how much churns when the set changes. count indexes copies by number — subnet[0], subnet[1], subnet[2]. Delete the middle subnet from a list of three and every copy after it shifts index; Terraform, reading position as identity, plans to destroy and rebuild everything downstream of the gap. for_each keys copies by a stable string instead — subnet["web"], subnet["data"] — so removing one touches exactly that one and leaves its neighbours alone. For Campux's subnets, that is the difference between a plan that edits one line and a plan that proposes to rebuild the network.

The one place count still earns its keep is a simple conditional — count = var.enabled ? 1 : 0 to include a resource or not. For a real set of things with names, the senior default is for_each, and the reasoning above is the answer an interviewer is fishing for when they ask why.

locals, and packaging with modules

Where a variable is an input from outside, a local is a value you compute inside and reuse — a naming convention assembled once and referenced everywhere as local.prefix, so the rule lives in one place rather than being retyped into forty resource names. When a resource group and a network want the same campux-prod stem, a local is how you say it once. And when a whole shape of infrastructure repeats — the three-copies rule from §5's cousin — you reach for a module: a folder of .tf files called as a unit, Class Twenty's Bicep modules in the other dialect.

# calling a local module — the network shape, packaged once, reused
module "network" {
  source        = "./modules/network"
  address_space = local.hub_cidr
  environment   = var.environment
}

# the module hands values back the same way a resource does
output "hub_vnet_id" {
  value = module.network.vnet_id
}

Local modules live under a path in your own repository like ./modules/network; the public Terraform Registry offers thousands more, versioned and pinned exactly like providers — and owed exactly the same suspicion as any dependency you did not write. When a shop advertises a "module library," this is the noun: a vetted internal set that turns a new VNet into a ten-line module call. Arriving already fluent in the word is one of the cheaper good impressions available in an interview.

lifecycle — admitting what you do not fully own

Two settings inside a lifecycle block earn their place in memory. prevent_destroy = true makes Terraform refuse any plan that would delete this resource — the guard rail on Campux's production database, so that a stray -/+ aborts loudly instead of erasing the orders table. ignore_changes tells Terraform to stop fighting over an attribute that something else legitimately manages — a tag Azure Policy stamps on from Class Eight, an instance count an autoscaler moves — so plan stops proposing to revert a change that is supposed to happen. Both are honest admissions that not every attribute in the cloud is yours to own outright, and encoding that in the file is better than a morning plan that lies about drift which is not really drift.

import, and why provisioners are a last resort

Drill 02's amnesia — the resources still exist, the state forgot them — is undone by terraform import, which writes an existing Azure resource into state without recreating it, so Terraform adopts what is already there. It is also the on-ramp for a hand-built estate: rather than destroy and rebuild, you import each resource, then write matching HCL until plan comes back empty. Tedious, one resource at a time, and precisely the tax an organisation pays for infrastructure that was clicked into being before anyone wrote it down.

Which leaves the temptation to avoid. Terraform can be told to run a shell script on a machine it just built — a provisioner such as remote-exec or local-exec — and it is the wrong reach nine times in ten. A provisioner runs imperative steps that never appear in plan, never enter state, and are not undone cleanly on destroy, so it punches a hole in everything this class values: the reviewed diff, the honest ledger, the reversible teardown. Prefer the native path — cloud-init or a prebuilt image for machine setup, a real Azure resource for anything Azure already models, a configuration-management tool for what lives inside the VM. HashiCorp's own documentation names provisioners a last resort in those words; treat the phrase as the rule it is.

You will be asked, in interviews and in meetings, which one is better. The honest answer is that they are the same idea with one structural difference — who keeps the books — and a handful of consequences that follow from it.

So the interview answer is not a side; it is a decision rule, delivered in about four sentences. Both are declarative, both preview before they apply, and I have written the same network in each. An Azure-only shop should lean Bicep: native, no state to operate, new features on day one. A multi-cloud shop, or one with an existing Terraform estate and module library, should lean Terraform: one language and one workflow across every platform, at the cost of operating state. The skill that transfers is infrastructure as code itself — the tool is a fitting. Candidates who say that get hired by both kinds of shop; candidates who declare one tool dead get filtered by whichever shop runs it happily at scale.³

One more noun from that answer earns a definition, because interviewers ask for it by name: modules. A Terraform module is a folder of .tf files invoked as a unit — Class Twenty's Bicep modules in the other dialect, with the same rule about when to extract: three copies, then a module, not before. Local modules live in your own repository under a path like ./modules/network; the public Terraform Registry offers thousands more, versioned and pinned like providers, and owed the same suspicion as any dependency you did not write. When a shop says it has a "module library", this is what it means — a vetted internal set that turns a new VNet into a ten-line module call — and arriving already knowing the word is one of the cheaper good impressions available.