Terraform

What is Terraform?

Terraform (by HashiCorp) is the most widely-used Infrastructure as Code (IaC) tool for provisioning cloud infrastructure. You declare the resources you want — servers, networks, databases, load balancers, DNS — in configuration files (HCL), and Terraform figures out how to create, change, or destroy real resources to match that declared state, across AWS, Azure, GCP, and hundreds of other providers. It replaced clicking in cloud consoles and hand-writing scripts with a declarative, version-controlled, reviewable definition of your infrastructure, which is why it became the default for IaC.

Provisioning vs configuration, and the plan/apply workflow

An important distinction: Terraform does provisioning (creating the infrastructure — VMs, VPCs, managed services), which is different from configuration management (Ansible, Chef — configuring software on existing servers). They’re complementary: Terraform builds the servers, a config tool (or, increasingly, a baked immutable image) sets up what runs on them. Terraform’s core workflow is plan then apply: plan shows you exactly what will change (what will be created, modified, or destroyed) before anything happens — a crucial safety feature that lets you review infrastructure changes like code — and apply executes it. Being declarative, you describe the desired end state and Terraform computes the diff from current reality; being cloud-agnostic (via providers), the same tool and workflow manage multi-cloud and third-party resources, though the resource definitions themselves are provider-specific.

State — the powerful, dangerous core

The single most important thing to understand about Terraform is state. Terraform records what it has provisioned in a state file, its mapping between your config and the real-world resources, and it relies on this to compute diffs. State is powerful but the source of most Terraform pain. It must be stored remotely and shared for any team (a remote backend like S3 with locking) — keeping state on a laptop or in Git is a recipe for conflicts and disaster. It must be locked during operations so two people don’t apply simultaneously and corrupt it. It often contains secrets (resource attributes like database passwords) in plaintext, so it must be secured and encrypted. And drift — when someone changes infrastructure manually outside Terraform — makes reality diverge from state, so the next plan wants to “fix” it, sometimes destructively. Other realities: terraform destroy and certain changes can replace or delete resources (a modification that forces recreation of a production database is a classic foot-gun — always read the plan), modules enable reuse but add complexity, and provider/version pinning matters for reproducibility. Note the ecosystem shift: after HashiCorp’s license change, the community fork OpenTofu emerged as an open-source drop-in, which matters for teams sensitive to licensing. The recurring mistakes: mismanaged/unlocked/local state, not reading the plan before applying (and destroying production resources), making manual changes that cause drift, and committing state or secrets to version control.

What people get wrong

• Mismanaged state — local or unlocked state causes team conflicts and corruption, and state files hold secrets in plaintext; use a locked, encrypted remote backend.
• Not reading the plan: apply without scrutinizing the plan can replace or destroy production resources (a change that forces database recreation is the classic disaster).
• Manual changes causing drift — editing infrastructure outside Terraform makes reality diverge from state; the next plan may try to revert it, sometimes destructively.

Primary source: Terraform documentation