From Tickets to Code

Scenario: A production network was created by clicking through a console. Six months later nobody can reproduce it, explain its settings, or safely build staging.

Infrastructure as Code stores the intended infrastructure in version control. A declarative tool describes the desired end state; Terraform compares configuration, state, and provider observations to calculate operations. Repeatability, peer review, audit history, automation, and disaster recovery are consequences of that source-controlled declaration—not magic properties of a file extension. Imperative scripts describe steps and often need hand-written retry and existence checks; declarative configuration lets the engine reason about convergence.

Analogy: A restaurant order states the desired meal; the kitchen chooses and sequences the work. A shell script is closer to dictating every knife movement.

A worked configuration

terraform {
  required_version = ">= 1.8, < 2.0"
}

resource "fakecloud_network" "app" {
  name = "payments-prod"
  cidr = "10.42.0.0/16"
}

In production, the configuration becomes a change proposal. A pull request can show intent, automated checks can reject unsafe policy, and a saved plan can bind approval to the exact changes applied. IaC does not eliminate operational judgment; it makes that judgment visible and repeatable.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-first-apply Terraform lab. Open /labs/terraform and choose slug tf-first-apply; the lab runs real Terraform against the offline FakeCloud provider.