Infrastructure as code: Terraform

Terraform does the same job as Bicep: you declare the infrastructure you want in text, and a tool makes reality match the file. The difference is philosophical, and it matters more than the syntax. Bicep hands your file to Azure Resource Manager and lets Azure work out what exists and what to change — Azure is the bookkeeper. Terraform trusts nobody's books but its own. It keeps a private record of every resource it has ever created — their real Azure ids, their last-known settings — in a file called state, and every decision it makes is a comparison between three things: what your code asks for, what its state remembers, and what the cloud actually contains.¹

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 = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "platform" {
  name = "rg-campux-platform"
}

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.

Run terraform apply on your laptop and the ledger appears next to your code as a local file, terraform.tfstate. For a solo experiment that is fine. For a team it is a slow-motion accident: the state on your laptop and the state on your colleague's laptop diverge the first time either of you deploys, and each machine now holds a different account of the same production estate. The fix is a remote backend — the state moves to shared storage that every engineer and every pipeline reads from and writes to. On Azure, that backend is a storage account:

# 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"
  }
}

Two properties of that arrangement do the real work. First, locking: before any operation that writes state, the blob is automatically locked with a lease, so two engineers who run apply at the same moment cannot both write the ledger — the second is refused until the first finishes. Corrupted state from concurrent writes is the classic team-Terraform disaster, and the Azure backend prevents it by default. Second, the state is itself a secret. It is plain JSON, it records resource attributes, and some of those attributes are sensitive — connection strings, generated passwords, and access keys all land in it in readable text. That is why state never goes into Git, why the storage account holding it is locked down as tightly as a Key Vault, and why .gitignore in every Terraform repository lists *.tfstate before the first commit.

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.

The three-way comparison also gives you drift detection almost for free. Suppose someone "fixes" a setting in the portal on a Tuesday. Your code did not change; the state did not change; the cloud did. The next plan refreshes against reality, sees the cloud disagreeing with the code, and reports it — a ~ line changing the setting back. Run on a schedule, plan becomes a drift alarm for the whole estate: an empty plan is a certificate that production still matches the repository, and a non-empty one names, line by line, where somebody's Tuesday click diverged from the agreed design. That certificate — reality provably matching the reviewed code — is what an employer is actually buying when the job posting says "Terraform".

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.³