Provisioning cloud infrastructure by clicking through a web console works, right up until you need to do it a second time, exactly the same way, under time pressure, without a mistake. Infrastructure as code (IaC) exists to remove that repetition and its risk.
What infrastructure as code actually means
Infrastructure as code is the practice of defining infrastructure — servers, networks, storage, permissions, and more — in configuration files that are checked into version control, rather than provisioned through manual, one-off actions. Once infrastructure is code, it inherits everything that already works for application code: code review before a change is applied, a version history explaining why a resource looks the way it does, and the ability to reconstruct an entire environment from the configuration alone.
Declarative versus imperative
IaC tools generally take one of two approaches. An imperative approach specifies the exact sequence of steps to reach a desired state — “create this VM, then attach this disk, then configure this network rule,” in order. A declarative approach specifies only the desired end state — “this VM, this disk, this network rule should exist” — and leaves the tool to figure out what steps are needed to get there from whatever the current state actually is.
Terraform, from HashiCorp, is the most widely adopted declarative IaC tool and is a useful concrete example of how the model works. HashiCorp’s own introduction to Terraform and its comparison to alternative approaches describe the model in detail; the short version is a three-step cycle:
- Write configuration describing the desired infrastructure in Terraform’s configuration language.
- Plan — Terraform compares the configuration against a state file representing what it believes currently exists, and computes exactly what would need to change: what gets created, modified, or destroyed.
- Apply — once the plan is reviewed and approved, Terraform executes those specific changes against the actual cloud provider APIs.
That plan step is the key safety property: you see precisely what will change before anything actually changes, rather than discovering the effect of a configuration edit only after it’s already been applied.
Idempotency: running it twice should be safe
A well-behaved declarative IaC tool is idempotent — applying the same configuration repeatedly, when nothing has actually changed, should result in no further changes, not duplicate resources or errors. This property is what makes IaC configuration something you can safely run repeatedly (including in an automated pipeline) rather than a one-shot script that has to be run exactly once.
Why this pairs directly with CI/CD
Infrastructure as code is what makes automated deployment pipelines, discussed in What Is CI/CD?, trustworthy for infrastructure changes and not just application code. Treating infrastructure configuration the same way as application code — reviewed, tested where practical, and applied through an automated pipeline rather than by someone manually running commands from their laptop — closes a real gap: without it, “the pipeline is fully automated” is only true for application deployments, while the infrastructure underneath is still provisioned by hand.
Drift: when reality and configuration disagree
Configuration drift happens when the actual state of infrastructure diverges from what’s defined in code — usually because someone made a manual change directly (a console click, an emergency fix) that was never reflected back into the configuration. Drift undermines the core value of IaC, because the configuration file stops being an accurate description of reality. Detecting and correcting drift — either by updating the configuration to match a legitimate manual change, or reverting the manual change to match the configuration — is an ongoing operational discipline, not a one-time setup task.
Key takeaway
Infrastructure as code turns infrastructure provisioning into a reviewable, repeatable, version-controlled process instead of a manual one. Declarative tools like Terraform add a specific safety property on top of that — computing and showing an explicit plan of changes before applying them — which is what makes automating infrastructure changes through a CI/CD pipeline a reasonable thing to do rather than a risky one.
This article explains general infrastructure-as-code concepts. Specific tool syntax, features, and best practices change over time — check current vendor documentation before adopting a specific tool. See our disclaimer.