What is infrastructure as code in one sentence?

Infrastructure as code is the practice of defining your servers, networks, and cloud resources in version-controlled text files so they can be created, changed, and destroyed automatically instead of by hand.

What is the difference between declarative and imperative IaC?

Declarative tools (Terraform, CloudFormation) describe the desired end state and let the tool figure out the steps. Imperative tools (scripts, Ansible playbooks) spell out the steps in order. Most modern IaC is declarative.

What tools are used for IaC?

Terraform and OpenTofu for multi-cloud provisioning, AWS CloudFormation and Azure Bicep for single-cloud, Pulumi for code-based definitions, and Ansible, Chef, or Puppet for configuration management.

What is configuration drift?

Configuration drift is when the real infrastructure no longer matches what the code says — usually because someone made a manual change in the console. IaC tools detect drift by comparing actual state to the declared state.

Is infrastructure as code only for the cloud?

No. IaC is most associated with public cloud, but the same tools provision on-premises VMware, bare-metal, Kubernetes clusters, DNS records, and SaaS configuration. Anything with an API can usually be managed as code.

Glossary · Infrastructure

What is Infrastructure as Code?

Infrastructure as Code (IaC) is the practice of defining your servers, networks, databases, and every other cloud resource in version-controlled text files, then letting a tool create, change, and tear them down automatically — so spinning up an entire environment becomes a reviewable, repeatable command instead of an afternoon of clicking through a console.

The shift it replaced

For most of computing history, infrastructure was provisioned by hand: an engineer logged into a console or SSH session, clicked through wizards, edited config files on individual machines, and wrote a runbook documenting what they did. The result was environments that no two people could rebuild identically, servers nobody dared touch, and "it works on staging but not production" as a way of life. IaC replaced the runbook with the actual executable definition — the documentation and the implementation became the same file.

Declarative vs. imperative

There are two broad styles. Imperative IaC spells out the steps: create this VM, then attach this disk, then open this port. Declarative IaC describes the desired end state — "I want three web servers behind a load balancer" — and the tool computes the difference between what exists and what you asked for, then makes only the changes needed to close the gap. Most modern tooling (Terraform, CloudFormation, Bicep) is declarative because it is idempotent: running it twice produces the same result, and it can be safely re-applied to repair drift.

Provisioning vs. configuration management

It helps to separate two jobs that both fall under "IaC." Provisioning tools like Terraform create the resources themselves — the network, the database, the compute instances. Configuration management tools like Ansible, Chef, and Puppet take a server that already exists and bring its contents into a known state: install packages, write files, start services. Many teams use both, with provisioning handling the cloud-level shape and configuration management handling what runs inside each box. On Kubernetes, much of the configuration layer moves into manifests and Helm charts instead.

Why it matters

The payoff is not just speed. Because infrastructure lives in version control, every change is reviewed in a pull request, attributed to an author, and reversible. Disaster recovery becomes re-running the code in a new region. Compliance auditors can read exactly how a system is built. New environments — a per-developer sandbox, an ephemeral preview for a feature branch — become cheap because they are one command. And configuration drift, the slow decay where reality diverges from documentation, gets caught by a plan that shows the diff before anything changes.

At QUANT LAB

We treat infrastructure as code as the default, not an upgrade. Every environment we build under cloud infrastructure and DevOps engineering ships as version-controlled definitions so the client owns a reproducible system rather than a snowflake nobody can rebuild. It also matters for security: when infrastructure is declared in code, an over-permissive IAM policy or a publicly exposed bucket shows up in a diff and a review, not six months later in an incident. Pairing IaC with observability gives you a system you can both rebuild and explain.

A pragmatic adoption path

You do not have to codify everything at once. A practical sequence: start by importing the resources you are most afraid to touch so they are at least captured; put the code in a repository with required reviews; wire a CI pipeline that runs a plan on every pull request so reviewers see the exact diff; store state remotely with locking so two engineers cannot apply at the same time; and only then expand to new environments. Trying to convert a large legacy estate in one sprint is how teams end up abandoning IaC halfway and living with a worse hybrid than before.

Long-form deep-dives that use this term

All posts

Related terms

Want reproducible infrastructure?

We build cloud environments as version-controlled code so you own a system you can rebuild, review, and audit. Book a 30-minute call.

DevOps engineering