Why IaC Exists

Every tool exists because something before it hurt. Terraform's predecessor wasn't a worse tool — it was a human being in a web console, clicking, and then a second human being trying to reproduce what the first one did. This page is about what actually goes wrong in that world, why the obvious fix (write a script) doesn't work, and what a declarative tool does differently.

What & Why

Infrastructure as code (IaC) is the practice of defining your servers, networks, databases and storage in machine-readable files that live in version control, and having a tool create and modify the real infrastructure to match those files.

The bad practice it replaces

Click-ops — provisioning infrastructure by hand through a cloud provider's web console — is the default, and it is genuinely the fastest way to get one thing working once. It fails in five specific ways, and it's worth being precise about them, because "it doesn't scale" is not an argument anyone should accept.

There is no record of intent. The console shows you a bucket with versioning enabled. It cannot tell you whether versioning is on because someone decided it should be, or because someone clicked it by accident in 2022. A .tf file that says versioning { enabled = true }, committed by a named person with a commit message, is a record of a decision. The console is a record of an outcome.

You cannot review a click. The single largest quality control in software — someone else reads your change before it happens — has no analogue in a web console. There is no diff. By the time a colleague could look at what you did, you have already done it to production.

Reproduction is manual and therefore wrong. Building staging to match production means someone opening two browser tabs and comparing. This works, in the sense that it produces a staging environment. It doesn't produce an identical one, and the differences are invisible until the deployment that worked in staging fails in production.

Deletion is unreliable. Nothing is more expensive than infrastructure nobody remembers creating. A console has no concept of "everything that belongs to this project", so decommissioning is an archaeology exercise, and the load balancer nobody found bills monthly forever.

And the real one: drift. Drift is divergence between what you believe your infrastructure is and what it actually is. Someone widens a security group at 2am during an incident and doesn't change it back. That's not negligence; that's an engineer fixing an outage. The problem is that nothing in the click-ops world will ever tell you it happened. Drift is silent, it accumulates, and it is the failure that IaC is genuinely built to solve — the others are conveniences by comparison.

Where Terraform sits

Terraform is a provisioning tool: it creates, changes and destroys infrastructure objects — buckets, networks, virtual machines, DNS records, IAM policies. It is cloud-agnostic, meaning it speaks to any platform with an API through a plugin, and declarative, meaning you describe the end state rather than the steps to reach it.

Three things it gets confused with

Configuration management. Ansible, Chef and Puppet configure the inside of a machine — install packages, write files, restart services. Terraform creates the machine. The boundary blurs (Ansible can create a VM; Terraform can run a script on one) and in both directions the crossing is a mistake. Terraform's provisioner block, which runs commands on a resource after creating it, exists and is almost always the wrong answer — see In Practice.

CI/CD. Jenkins, GitHub Actions and GitLab CI run your pipeline; they don't know what a subnet is. They are the thing that runs Terraform, covered in CI/CD & Automation. Confusing the two produces pipelines that shell out to aws CLI commands and call it infrastructure as code.

GitOps. A workflow — git is the single source of truth and a controller continuously reconciles reality to it — most associated with Kubernetes and Argo CD. Terraform is a tool you can use GitOps-ily, but by default it reconciles when you run it, not continuously. That gap is exactly what Drift & Reconciliation is about.

When NOT to use it

Being honest about this is more useful than another list of benefits.

• A genuine one-off you will delete this afternoon. A test VM to reproduce a bug does not need a repository. Click it, use it, delete it.
• Anything with an inherently imperative, ordered, stateful procedure — a database major-version upgrade, a data migration, a cutover. Terraform describes end states. "Take a snapshot, then upgrade, then verify, then flip the DNS" is a runbook, and expressing it in Terraform means fighting the model with provisioner and null_resource until something breaks halfway through.
• Application deployment. Rolling out a new container image every twenty minutes is a job for a deployment tool. Terraform's plan/apply cycle is deliberately slow and deliberately supervised.
• Where you're only willing to manage half of it. The single worst outcome in Terraform is a resource that is partly managed by Terraform and partly maintained by hand, because every plan will now propose to undo the hand-maintained part. Either bring it under management properly — see Import & Refactoring — or leave it out entirely and document that it's out. Half is worse than neither.

Core Concepts

Infrastructure as code — your infrastructure, written down in files you can diff. The practice of defining infrastructure in declarative or programmatic source files, version-controlled and applied by a tool, such that the files are the authority and the running system is derived from them.

Click-ops — building things by hand in a web console. Manual provisioning through a graphical interface. Not a slur; it's the correct approach for exploration and the wrong one for anything that must survive.

Declarative — you describe the destination. You state the desired end configuration, and the tool computes the operations required to reach it from wherever things currently are. The same file applied twice produces the same result, because the second run finds nothing to do.

Imperative — you describe the journey. You specify the operations themselves, in order. The result depends on the starting point, which means the author has to anticipate every starting point.

Desired state — what you said you want. The configuration expressed in your .tf files: the set of resources that should exist and the attributes they should have.

Actual state — what is really there. The current configuration of the real objects in the cloud provider, discoverable only by asking the provider's API.

Drift — reality quietly disagreeing with your files. Any difference between desired and actual state that your configuration didn't cause: a manual console change, an out-of-band automation, a provider-side default that changed. Covered properly in Drift & Reconciliation.

Convergence — repeated runs move towards the description, not away from it. The property that applying the same desired state repeatedly brings actual state closer to it and then leaves it alone.

Idempotence — running it twice is the same as running it once. An operation whose repetition has no additional effect. apply is idempotent; curl -X POST /buckets is not.

Provisioning versus configuration management — making the machine exist, versus making the machine useful. Terraform is the former. Ansible, Chef, Puppet and cloud-init are the latter.

Resource — one thing Terraform manages. A single object in a provider's API — one bucket, one subnet, one DNS record — declared in a resource block. The full grammar is in Resources & References.

Provider — the plugin that knows one platform's API. A separately versioned binary that translates Terraform's generic operations into calls against AWS, Azure, GCP, Cloudflare, GitHub or several thousand others. See Providers & the Registry.

State — Terraform's record of what it made. A file mapping each resource in your configuration to the real object it created, so the tool can tell "create this" apart from "modify that". It exists because the alternative — rediscovering the whole world on every run — is impossible at any real scale. Introduced properly in Anatomy of a Project; the mechanics are in State & Backends.

Plan — the dry run that tells you what would change. A computed diff between desired state, recorded state and actual state, rendered for a human to approve. See The Plan/Apply Lifecycle.

Blast radius — how much breaks if this change is wrong. The set of resources a single operation could affect. A phrase used throughout this article, and the main reason state gets split into separate files as an estate grows.

How It Works

The mechanism is a three-way comparison. Not two — that's the part people get wrong.

A tool that compared only desired state (your files) against actual state (the cloud) could tell that a bucket exists and that your file describes a bucket, but not whether this bucket is that declaration — and it could never detect deletion, because a resource you removed from your files looks identical to a resource you never wrote. So Terraform keeps a third thing: a record of what it created and which configuration address created it. Each run compares all three:

That last row is worth sitting with, because it's the one that ambushes people on a real estate. A resource that exists in the cloud but not in Terraform's record is invisible to Terraform, and the moment you write configuration for it, Terraform tries to create a second one.

Two consequences fall out of this design immediately, and both shape everything later in the article:

Convergence is a property of the comparison, not of your files. You don't write "create if not exists". The diff produces that. This is why applying the same configuration twice is safe and why applying it to an empty account and a half-built account both work.

The record is load-bearing and therefore dangerous. If it's lost, Terraform forgets what it owns and proposes to create everything again. If it's wrong, Terraform acts on a false belief about reality. If two people run apply simultaneously, they write over each other's record. Those three sentences are the entire agenda of State & Backends and Failure & Recovery.

Getting Started

The smallest thing that demonstrates the difference isn't a Terraform tutorial — it's running each approach twice.

First, the imperative version

A perfectly reasonable script that creates a bucket. Every cloud CLI has one of these, and every team has a directory full of them.

```bash
#!/usr/bin/env bash
aws s3api create-bucket \
  --bucket tf-article-demo-0725 \
  --region eu-west-1 \
  --create-bucket-configuration LocationConstraint=eu-west-1
```

```bash
#!/usr/bin/env bash
az storage account create \
  --name tfarticledemo0725 \
  --resource-group tf-article-demo \
  --location westeurope \
  --sku Standard_LRS
```

```bash
#!/usr/bin/env bash
gcloud storage buckets create gs://tf-article-demo-0725 \
  --location=europe-west1
```

Run it once: a bucket. Run it a second time:

# UNVERIFIED — confirm against a real run
An error occurred (BucketAlreadyOwnedByYou) when calling the CreateBucket operation:
Your previous request to create the named bucket succeeded and you already own it.

That error is the whole lesson. The script isn't wrong — it did exactly what it was told. It has no idea what already exists, so it cannot be run twice, which means it cannot be the thing you run to make sure your infrastructure is correct. You can fix this by adding an existence check, and then a check for the region, and then a check for whether versioning is enabled, and after about two hundred lines you have written a bad, single-purpose version of Terraform. This is the honest reason IaC tools exist: not because scripts are unprofessional, but because the convergence logic is the hard part and it is the same for everybody.

Now the declarative version

Bucket names must be globally unique in all three clouds, so change the suffix. Azure needs a resource group to put the storage account in, which is why its tab has an extra resource — GCP and AWS have no equivalent.

```hcl
# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-1"
}

resource "aws_s3_bucket" "demo" {
  bucket = "tf-article-demo-0725"
}
```

```hcl
# main.tf
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "demo" {
  name     = "tf-article-demo"
  location = "westeurope"
}

resource "azurerm_storage_account" "demo" {
  name                     = "tfarticledemo0725" # 3–24 chars, lowercase alphanumeric only
  resource_group_name      = azurerm_resource_group.demo.name
  location                 = azurerm_resource_group.demo.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}
```

```hcl
# main.tf
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = "your-project-id"
  region  = "europe-west1"
}

resource "google_storage_bucket" "demo" {
  name     = "tf-article-demo-0725"
  location = "EUROPE-WEST1"
}
```

terraform init      # download the provider
terraform apply     # show the plan, ask for confirmation, create the bucket
terraform apply     # ...and again

The second apply:

# UNVERIFIED — confirm against a real run
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

Not an error. Not a second bucket. Nothing — which is the correct answer to "make sure this bucket exists" when it already does. Every command here is explained properly in The Core Workflow; the point of running them now is that sentence.

If you want to see drift with your own eyes, open the console, add a tag or label to the bucket by hand, and run terraform plan. Terraform will notice and propose to remove it.

Then clean up, so this doesn't become the infrastructure nobody remembers creating:

terraform destroy

In Practice

The interesting question isn't whether to use IaC. It's what changes in how a team works, and which of those changes people skip.

The rule that makes it work, and the exception everyone actually needs. The rule is: nobody changes managed infrastructure by hand. The exception is: during a production incident, somebody will, and they should — a firewall rule that stops an outage is worth more than a clean audit trail. So the workable version of the rule is no manual changes except during an incident, and every incident's manual changes get reconciled into code before the incident is closed. Teams that state the absolute rule without the exception get the exception anyway, plus silence about it. Make the reconciliation step part of the incident template, not part of somebody's memory.

Coverage is a cliff, not a slope. Fifty per cent IaC coverage is not half the benefit. Any resource that Terraform partly manages is a resource that produces a confusing plan every time, and confusing plans are how teams learn to approve plans without reading them — which costs more than the manual work ever did. Draw the boundary explicitly: this state file owns these resources, and everything else is out of scope and documented as such.

Adopt brownfield incrementally, by boundary. Nobody starts on an empty account. The workable sequence is: pick one bounded thing (a single environment, a single application's networking), import it, get its plan to "no changes", and only then move to the next. The tooling for this — import blocks, moved blocks, generated configuration — is a survival skill, and it's covered in Import & Refactoring.

provisioner is the trap. It's a block that runs shell commands on a resource after creation, and it looks like the obvious bridge between "Terraform makes the VM" and "and now install nginx on it". HashiCorp's own documentation describes provisioners as a last resort, and they're right: a provisioner runs only at creation, so it's invisible to plan, absent from state, and never re-runs when the script changes. Your configuration management is now something Terraform cannot see and cannot converge. Use a machine image built beforehand, or cloud-init/user-data, or a configuration management tool triggered separately.

What a reviewer should look for, on a pull request that introduces Terraform to something:

• Does the plan output appear in the pull request, and does it say create where you expect creates and nothing where you expect nothing? An import that's working correctly produces no changes, and a plan full of replacements on an "import" PR means the configuration doesn't match reality yet.
• Is anything being destroyed? Every - and -/+ in a plan needs a sentence explaining it.
• Are provider versions pinned, and is the lock file committed?
• Is the boundary stated — what this configuration owns, and what it deliberately doesn't?

Rollback isn't git revert. Reverting the commit and applying takes infrastructure back to the previous described state, which is not the same as the previous real state: a deleted database is still deleted, and re-creating it creates an empty one. Data-bearing resources have a one-way door in them. This is the difference between rolling back application code and rolling back infrastructure, and it's why the destroy line in a plan deserves more attention than any other.

Ecosystem

The tools you'll be asked to compare Terraform against in a design review, and the honest one-line version of each.

The one-line summary. Single-cloud, all-in, and happy to be — use the native tool; the managed state alone is worth it. More than one cloud, or cloud plus DNS plus GitHub plus a SaaS provider — Terraform, because the alternative is three tools and three mental models. Infrastructure that is genuinely programmatic, generated from data — look seriously at Pulumi and be honest about who will maintain it.

Production

Security

IaC is a security improvement and a security liability in the same move. The improvement: every change to a firewall rule, IAM policy or public-access setting is a reviewable diff with an author and a timestamp — an auditor's dream compared to console logs. The liability: your repository now describes your entire attack surface, and the credentials that apply it can change anything. Two consequences arrive on day one — the credentials Terraform runs with are the most powerful in your organisation and should be short-lived rather than long-lived keys (see CI/CD & Automation), and secrets must never be written in .tf files, because state records them in plaintext (see Secrets & Sensitive Data).

Blast radius

The same automation that creates a hundred resources correctly destroys a hundred resources correctly. Click-ops has a natural rate limit: a human can only click so fast, and gets bored before deleting the whole VPC. Terraform has no such limit. The mitigations — splitting state so no single apply can reach everything, prevent_destroy on data-bearing resources, requiring approval on plans containing destroys — are covered in Meta-Arguments and Repo & Environment Structure. What matters at this stage is the instinct: read the destroy lines first.

Scale

IaC's value is roughly proportional to how often infrastructure changes multiplied by how many people change it. One person with three servers gets little; twenty people with three environments and a compliance auditor get a great deal. The costs scale too — plans get slower, state files get bigger, and at some point the answer stops being "tune a flag" and becomes "split this state", which is Scale & Performance.

Team workflow

The change is that infrastructure joins the software development lifecycle: branch, pull request, review, merge, apply. The failure mode is adopting the file format without the workflow — a terraform/ directory that everyone applies from their laptop, with no review and no shared state, which has all the constraints of IaC and none of the benefits. If you take one operational habit from this article, take plan output goes in the pull request.

Reliability

Reproducibility is the payoff. Recreating an environment in a new region becomes a matter of different variables against the same configuration rather than a fortnight of clicking. Two honest caveats: the configuration reproduces infrastructure, not data, so backups remain a separate problem entirely; and a reproduction path that has never been exercised is a hypothesis, not a plan — see Failure & Recovery.

Interview Questions

Conceptual

Technical depth

Scenario and design

Commands & Gotchas

At this stage the command surface is deliberately tiny. Everything here is covered properly in The Core Workflow.

terraform version              # which Terraform, which providers — the first thing to check
terraform init                 # download providers; run once per directory, and after changing versions
terraform fmt                  # canonical formatting; run before every commit
terraform validate             # syntax and internal consistency; no cloud credentials needed
terraform plan                 # the dry run — what would change, and why
terraform apply                # show the plan, ask for confirmation, then make it so
terraform destroy              # remove everything this configuration manages

← Back to Orientation · Next: The Core Workflow →

⚠️ Verification checklist (delete before publishing)

Commands and output

• Run the AWS bucket script twice; capture the real second-run error. The BucketAlreadyOwnedByYou text is from memory — the exact wording and error code differ by region (us-east-1 returns BucketAlreadyExists in some cases). ⚠️ verify.
• Run the Azure and GCP scripts twice and capture their second-run errors too — currently not shown at all. az may return success on re-run rather than an error, which would weaken the example; check before relying on it.
• Confirm aws s3api create-bucket still requires --create-bucket-configuration LocationConstraint for non-us-east-1 regions.
• Confirm gcloud storage buckets create is the current form (it replaced gsutil mb; ⚠️ verify gsutil deprecation status before implying it's gone).
• Run all three Terraform configs; capture the real apply output and the real second-apply "No changes" text — the wording shown is reconstructed.
• Verify the drift demonstration actually produces a plan diff: add a tag/label by hand and confirm plan proposes removing it. For GCP, confirm labels behave this way and aren't ignored.

Versions and syntax

• Provider version constraints ~> 5.0 (aws), ~> 3.0 (azurerm), ~> 5.0 (google) — all three are likely stale. Check current major versions and update; azurerm 4.x in particular has breaking changes including a required subscription_id. ⚠️ verify.
• Confirm provider "google" still accepts region at the provider level alongside project.
• Confirm azurerm_storage_account argument names (account_tier, account_replication_type) are unchanged in the current major version.
• GCP bucket location = "EUROPE-WEST1" — confirm the expected case and whether lowercase is accepted.

Asserted constraints

• Azure storage account name: 3–24 characters, lowercase alphanumeric only. ⚠️ verify exact rule.
• "Bucket names are globally unique in all three clouds" — verify for GCP and Azure specifically.
• The claim that a failed provisioner marks the resource tainted and forces replacement on next apply. ⚠️ verify current behaviour.
• The characterisation of GCP Deployment Manager as effectively end-of-life, and of Config Connector as the successor. ⚠️ verify current Google guidance — flagged inline already.
• HashiCorp's documented position on provisioners as "last resort" — confirm the wording still exists in current docs before paraphrasing it.
• terraformer — confirm it's still maintained before recommending it.

Rendering

• Both <Tabs> blocks render correctly on the published site. If tabs aren't available, fall back to labelled consecutive fences throughout.
• The <details> blocks render on the site (they work on github.com regardless).
• All fifteen relative links resolve once the target files exist. Currently every one of them is a dead link.