What Infrastructure as Code Is

Infrastructure as Code is the practice of declaring your projects, networks, service accounts, and resources in text files that you version, review, and apply — instead of clicking through the Cloud Console or firing off a pile of gcloud commands. The files are the source of truth; a tool reads them and makes Google Cloud match. Your infrastructure stops being a thing you remember building and becomes a thing you can read, diff, and rebuild.

The problem it solves is that hand-built infrastructure is unreproducible. Nobody can say exactly how a project was assembled, staging quietly diverges from production, and rebuilding after an incident becomes archaeology against a half-remembered runbook. Write the same infrastructure as code and those questions have answers: the code is the record, the git history is the changelog, and a second identical project is one apply away.

The Cost of Console-Building

Building infrastructure by hand — clicking through the Console, or running gcloud commands one at a time — feels fast for the first resource and compounds into debt by the hundredth. Each manual change escapes the codebase: an audit log may note that it happened, but nothing captures the intent behind it, the desired end state, or how to reproduce it. Two engineers solving the same problem build it two different ways. The knowledge of how a project fits together lives in people's heads and walks out the door when they do.

The sharpest version of this pain is drift between environments. You assemble a production project by clicking, then build staging the same way a month later from memory. The two are subtly different, so a change that works in staging breaks in production, and the difference is undocumented because there was never a document. The Console gives you no diff, no review, and no undo beyond your own recollection.

Declarative, Not Imperative

There are two ways to tell a computer to build infrastructure. The imperative way is a sequence of steps: create this bucket, then this dataset, then wire them together — and you own every step, including checking whether each thing already exists. The declarative way is a description of the end state: here is the bucket, the dataset, and the wiring I want to exist. You describe the destination; the tool computes the route.

That difference is not stylistic. A gcloud script that creates a bucket fails the second time you run it, because the bucket already exists — so you end up wrapping every command in "does this exist yet?" logic. A declarative tool compares your description to what is actually there and does only what is needed to close the gap. The snippet below is the entire instruction to ensure a bucket exists in a project; there is no "create" verb and no "already exists" handling, because you declared a state, not an action.

resource "google_storage_bucket" "raw" {
  name     = "hatch-events-raw"   # globally-unique name — declared, not "created"
  location = "US"
}

Run the equivalent imperative command twice and the second run errors because the bucket is already there; you would have to catch that yourself. Apply the declarative resource twice and the second run is a no-op, because the desired state already matches reality. That property has a name, and it is the next idea.

Idempotency and Desired State

Idempotency means applying the same configuration twice yields the same result — the first apply creates what is missing, and the second changes nothing because nothing needs changing. The tool holds a model of desired state and reconciles reality toward it, rather than blindly re-running actions. This is why a declarative apply is safe to run repeatedly and a hand-rolled script is not.

Desired state is also what makes change reviewable. Because the configuration describes the end result, a change to it is a diff — add three lines to add a subnet, change one to resize an instance. That diff goes through the same pull-request review as application code, which means infrastructure changes get the same scrutiny, history, and rollback that code has had for decades.

Provisioning, Configuration, and Orchestration

"Infrastructure as Code" is an umbrella over three different layers, and confusing them is the most common newcomer mistake. Provisioning creates the resources — the project, the network, the Compute Engine instance, the database. Configuration management sets up what runs inside them — installs packages, edits config files, manages services. Orchestration schedules long-running workloads across machines, as Google Kubernetes Engine does for containers.

Terraform is a provisioning tool. It is precise at creating and tracking the existence and shape of cloud resources, and it deliberately does not configure the operating system inside a VM — that is the configuration layer's job, handled by a startup script or a tool like Ansible. Keeping these layers distinct, rather than forcing one tool to do all three, is what keeps an infrastructure pipeline clean. The next topic places Terraform precisely; the one after maps the whole GCP landscape.