What Is Infrastructure as Code? IaC Explained

Infrastructure as code (IaC) means defining servers, networks, load balancers, and other infrastructure in machine-readable configuration files instead of clicking through a cloud console or running one-off commands by hand. Those files live in version control alongside application code, so infrastructure changes go through the same review, diff, and history that code changes do. The environment described in the files is the environment that actually exists — or it’s a bug.

The problem IaC solves

Before IaC became standard, infrastructure was typically provisioned by hand: an engineer logs into a cloud console, spins up a server, configures networking, installs dependencies, repeats for staging and production. This works until you need to do it again — after an outage, for a new environment, for a second region — and discover that nobody fully remembers every setting that was clicked, and the three environments have quietly drifted apart. This is often called “configuration drift,” and it’s the core failure mode IaC is designed to eliminate.

With infrastructure defined as code, spinning up an identical environment is a matter of running the same configuration again. The config file is the single source of truth, not any particular engineer’s memory or a runbook that’s three months out of date.

Declarative vs imperative approaches

IaC tools split broadly into two styles.

Declarative tools describe the desired end state — “there should be a load balancer with these two backend servers” — and let the tool figure out what needs to change to get there. Terraform is the best-known example: you write .tf files describing resources, and Terraform computes a plan (create this, modify that, destroy this other thing) to reconcile actual infrastructure with the declared state.

Imperative tools describe the steps to take — “run this command, then that command” — closer to a traditional script. Older configuration management tools like shell-script-based provisioning fall into this category. Imperative scripts are easier to reason about line by line but don’t automatically know how to undo or reconcile drift the way a declarative tool’s plan-and-apply cycle does.

Most modern IaC tooling, including Terraform, Pulumi, and cloud-native options like AWS CloudFormation, is declarative — you describe the destination, not the route.

What IaC looks like in practice

A minimal Terraform example for a single cloud server:

resource "aws_instance" "web" {
  ami           = "ami-0123456789abcdef0"
  instance_type = "t3.micro"
  tags = {
    Name = "web-server"
  }
}

Running terraform plan shows exactly what would change before anything is touched; terraform apply executes it. That plan step is one of IaC’s biggest practical wins over manual changes — you see the blast radius of a change before it happens, in a pull request, reviewed by a teammate, rather than discovering it live in a production console.

IaC and the rest of the deployment pipeline

IaC is usually one piece of a larger CI/CD pipeline: a merged pull request triggers a plan, a human or an automated policy approves it, and the apply step runs the same way every time. This is the foundation of GitOps, where the git repository itself — not a person with console access — is the source of truth for what’s actually running, and any drift between the repo and reality is treated as something to reconcile automatically.

IaC also underpins immutable infrastructure: instead of patching a running server in place, you change the config, provision new infrastructure from it, and retire the old resources. Combined with containers and orchestrators like Kubernetes, IaC extends the same “describe the desired state, let the tool reconcile it” model from individual servers up to entire application platforms.

Benefits and trade-offs

Benefits:

• Reproducibility. The same config produces the same environment, every time, in every region.
• Reviewable changes. Infrastructure changes go through pull requests like code, catching mistakes before they hit production.
• Disaster recovery. Rebuilding a lost environment from scratch is a matter of re-applying the config, not reconstructing tribal knowledge.
• Documentation by default. The config file is the documentation of what infrastructure exists and how it’s configured.

Trade-offs:

• Learning curve. Declarative tools have their own syntax and mental model, and state management (Terraform’s state file, for instance) adds an operational concern of its own.
• Drift is still possible. Manual changes made outside the IaC tool — a console click during an incident — silently diverge from the declared state until someone reconciles it.
• Blast radius. A bad config change can be applied everywhere just as easily as a good one; the review and plan steps exist specifically to catch that before it happens.

The takeaway

Infrastructure as code turns servers, networks, and cloud resources into version-controlled configuration instead of manual console work — the config describes the desired state, and a tool like Terraform reconciles reality to match it. The result is reproducible environments, reviewable infrastructure changes, and a real defense against configuration drift, at the cost of a genuine learning curve and the discipline to keep manual changes out of the loop entirely.