What is Terraform? Multi-cloud infrastructure as code explained

The plain idea: describe it, and Terraform builds it

A Terraform configuration is a set of text files, written in HCL (HashiCorp Configuration Language), describing the infrastructure you want to exist: this network, these virtual machines, that database, connected like so. You do not write the steps to build them — no “first create this, then attach that”. You describe the destination, and Terraform derives the route. When you run it, Terraform compares your description with what actually exists and produces a precise list of actions: create these three things, change this one, destroy that one. Approve, and it carries them out through the cloud provider’s APIs.

That declarative approach is what makes the files more than a build script. Because they describe the desired end state, they can be applied repeatedly and safely — running the same configuration twice changes nothing the second time — and they double as accurate, living documentation of your infrastructure, version-controlled and reviewable like any other code. Our infrastructure-as-code explainer covers why that idea matters in general; this article stays on Terraform specifically.

How it works: providers, plan and apply, and state

Three concepts carry most of Terraform’s conceptual weight:

• Providers — plugins that teach Terraform how to talk to a particular platform. There are providers for AWS, Azure and Google Cloud, and hundreds more for other services. Your configuration says what you want; the provider translates it into that platform’s API calls.
• Plan, then apply — the two-step workflow at Terraform’s heart. “Plan” shows exactly what Terraform intends to do — every create, change and destroy — before anything happens; “apply” executes it. The preview is the safety mechanism: no change reaches real infrastructure unseen.
• State — Terraform’s record of what it has built, mapping your configuration to the real resources it manages. State is what lets Terraform compute precise diffs between desired and actual, and it is why the tool can change or destroy exactly the right things later.

Why Terraform became the standard

Terraform’s defining advantage is that it is vendor-neutral. One language, one workflow and one skill set manage AWS, Azure, Google Cloud and a long tail of other platforms — DNS registrars, monitoring services, source-control systems — through the same plan-and-apply loop. For organisations running more than one cloud, that is the difference between one toolchain and several; for engineers, it means the skill transfers intact between employers and providers, which is a large part of why Terraform appears so persistently in infrastructure job adverts.

The rest of its appeal compounds from there. The declarative model makes changes reviewable and repeatable. Modules let teams package proven configuration — a standard network layout, a hardened database setup — and reuse it everywhere, so good practice replicates instead of being reinvented. And the provider ecosystem is enormous and community-driven, so almost anything with an API can be managed from the same codebase. None of this made Terraform the only choice, but together they made it the default one.

Terraform versus CloudFormation and Bicep

Each major cloud has its own native IaC: AWS CloudFormation and Azure Bicep are the ones you will meet most often. The fair comparison is single-cloud depth versus multi-cloud breadth. The native tools are built by the platform vendor, deeply integrated, and require no separate state management — the platform itself tracks what a stack contains. If your organisation is all-in on one cloud, they are entirely reasonable choices, and the cloud certifications for that platform will expect you to know them.

Terraform’s case is everything outside that boundary: one tool across every provider, a shared language for teams whose estate spans clouds and SaaS services, and a skills market that prizes the transferability. The honest summary is that this is a genuine trade-off, not a ranking — native tools buy tight integration at the price of lock-in to one platform’s ecosystem, while Terraform buys breadth at the price of maintaining its own state and living one step removed from the platform. Many organisations run both, using Terraform as the umbrella and native tooling where the integration pays.

The honest challenges

Terraform’s difficulties cluster around the same feature that gives it power: state. The state file is Terraform’s single source of truth about what it manages, and it must be stored safely, shared correctly among the team, and protected from concurrent edits — get this wrong and Terraform’s picture of the world diverges from reality, which is the tool’s most painful failure mode. Remote backends and HashiCorp’s managed platform, HCP Terraform, exist largely to make state handling safe by default, but it remains a discipline to learn rather than a detail to ignore.

Drift is the related problem: when someone changes infrastructure by hand — an emergency console fix, a well-meaning tweak — the real world no longer matches either the configuration or the state, and reconciling the three takes care. And there is a genuine learning curve: HCL, the provider model, the workflow and the state discipline arrive together, and early mistakes can plan the destruction of real resources — which is precisely why the plan step exists and why teams review plans the way they review code. These are the same fundamental challenges our infrastructure-as-code explainer describes; Terraform simply makes them concrete.

Terraform in certification study

Terraform has its own credential: the HashiCorp Certified Terraform Associate, a vendor-neutral, associate-level exam covering the concepts in this article at working depth — the workflow, configuration, modules and state management. If Terraform is or will be part of your job, it is the natural certification target, and our Terraform Associate certification guide covers the exam in full.

On the cloud-provider tracks, Terraform appears as context rather than syllabus: AWS exams teach CloudFormation as the native tool but expect you to understand what infrastructure as code is and that multi-cloud alternatives exist, and the same pattern holds on Azure with Bicep. The concept-level understanding this article gives you — declarative configuration, plan-and-apply, state — is close to what those exams require; the Terraform Associate is where the tool itself gets examined. Either way, a few hours of hands-on practice against a free-tier cloud account will teach you more about Terraform than any amount of reading.