What Is Terraform? Infrastructure as Code Explained

Provisioning infrastructure used to mean filing a ticket, waiting for someone to click through a console, or hoping a shell script written two years ago still worked. Terraform changes that by treating infrastructure as a versioned, testable artifact rather than a one-off task. This article walks through what Terraform actually does, the concepts you need to use it well, and how it fits into a broader enterprise toolchain.

What Is Terraform, Exactly?

Terraform is an open-source infrastructure as code (IaC) tool built by HashiCorp. It lets you define servers, networks, databases, and other cloud resources in configuration files instead of clicking through a web console or running one-off scripts.

The model is declarative: you describe the end state you want — "three web servers, one load balancer, one database" — and Terraform figures out how to get there. You don't write step-by-step instructions; you write the destination.

This solves a real problem. Manual provisioning doesn't scale and isn't repeatable — two engineers building "the same" environment by hand will produce subtly different results. Ad hoc scripts are better, but they're usually imperative, undocumented, and brittle when infrastructure needs to change or roll back.

Terraform gives you a single source of truth for infrastructure that can be reviewed, versioned, and reused, the same way application code is.

How Terraform Works: Providers, State, and the Core Workflow

Terraform configuration is written in HCL (HashiCorp Configuration Language), a readable, structured syntax designed specifically for describing infrastructure. You write plain text files describing what you want, and Terraform handles the API calls.

Those API calls happen through providers — plugins that translate your HCL into requests against a specific platform. There are providers for the major cloud providers, as well as for SaaS tools, DNS services, and on-prem systems.

Terraform tracks everything it manages in a state file, a record of what resources exist, their current configuration, and how they map to your code. This is how Terraform knows what to change rather than recreating everything from scratch every time.

The core workflow follows a consistent cycle:

• Write: you author or update HCL configuration describing desired infrastructure.
• Plan: Terraform compares your configuration against the current state and shows exactly what it will add, change, or destroy.
• Apply: once you approve the plan, Terraform executes the necessary API calls to make reality match your configuration.
• Refresh/reconcile: on subsequent runs, Terraform re-checks state against real infrastructure before planning again.

That plan step is what makes Terraform trustworthy in production. You see the exact diff before anything changes — no surprises, no guessing.

Master the right skills for your goal

Not sure which path fits? Get a free 1:1 consultation with our team.

Request a callback

Related courses

DevOps & SRE

Terraform / IaC

Live Online · 24 Hrs · Beginner to Intermediate

DevOps & SRE

DevOps

Live Online · 40 Hrs · Beginner to Intermediate

Key Terraform Concepts You Need to Know

A handful of building blocks show up in nearly every Terraform project. Understanding them is more valuable than memorizing syntax.

• Resources: the individual infrastructure objects you manage — a virtual machine, a storage bucket, a DNS record. Each resource block maps to one real-world object.
• Modules: reusable, parameterized bundles of resources. A "web app" module might bundle a server, a load balancer, and a firewall rule so teams don't rebuild the same pattern repeatedly.
• Variables: inputs that let the same configuration behave differently across environments — a variable might control instance size or region without duplicating code.
• Outputs: values Terraform exposes after applying, such as a generated IP address or database endpoint, which other systems or modules can consume.
• State file: the authoritative record of what Terraform believes exists. It's what makes incremental, non-destructive updates possible instead of full teardown-and-rebuild cycles.

In practice, most real projects are built almost entirely from modules and variables, with a small number of hand-written resource blocks tying them together.

Why Terraform Matters for Enterprises

At small scale, manual infrastructure management is annoying. At enterprise scale, it's a liability. Terraform addresses several problems that compound as environments grow.

• Consistency across environments: the same configuration can produce identical dev, staging, and production environments, eliminating "it worked in staging" surprises.
• Auditability: because configuration lives in version control, every infrastructure change has a commit history, an author, and a reviewable diff.
• Disaster recovery: if an environment is lost or corrupted, you can rebuild it from code rather than reconstructing it from memory or stale documentation.
• Reduced configuration drift: drift happens when live infrastructure diverges from what's documented. Terraform's plan step surfaces drift automatically, instead of letting it accumulate silently.
• Multi-cloud and hybrid flexibility: the same tool and workflow apply whether you're provisioning in one cloud, across several, or alongside on-prem systems.

For organizations managing hundreds of resources across teams, these aren't nice-to-haves — they're what makes infrastructure manageable at all.

Terraform isn't really about automating clicks — it's about making infrastructure reviewable. The real shift isn't speed, it's that a change to your network now looks like a pull request instead of a rumor.

A Typical Terraform Workflow in Practice

In a mature team, Terraform rarely runs as a one-off command from someone's laptop. It's embedded in a repeatable process.

• Write configuration: an engineer adds or modifies HCL files describing the desired infrastructure change.
• Version control it: the change is committed to a Git repository, just like application code, and opened as a pull request.
• Code review: teammates review the diff, often alongside an automatically generated plan output showing exactly what will change.
• Run plan: either locally or in a pipeline, Terraform generates a plan so everyone can see additions, modifications, and deletions before they happen.
• Run apply: after approval, apply executes the change — ideally through automation rather than a manual terminal command.
• Integrate with CI/CD: many teams wire this entire cycle into continuous integration pipelines, so plans run automatically on pull requests and applies run automatically on merge.

This mirrors how software is shipped, which is deliberate. Infrastructure changes get the same scrutiny, history, and rollback options as application code.

Terraform vs. Other Infrastructure Tools

Terraform isn't the only option, and it's worth knowing where it fits relative to its closest neighbors.

• CloudFormation is AWS's native IaC tool. It integrates tightly with AWS services but only works within AWS, whereas Terraform works across providers with a consistent syntax.
• Pulumi takes a similar declarative approach but lets you write configuration in general-purpose programming languages instead of a dedicated syntax. It appeals to teams that want full programming constructs — loops, functions, testing frameworks — built in natively.
• Configuration-management tools like Ansible solve a different problem: they configure what runs inside a server (installing packages, managing files, starting services) rather than provisioning the server itself. Many teams use Terraform to create infrastructure and Ansible to configure it afterward.

None of these tools is strictly superior — they're optimized for different layers of the stack, and plenty of enterprises use more than one.

Common Misconceptions and Pitfalls

Terraform is easy to start using and easy to misuse. Most problems trace back to a handful of recurring misunderstandings.

• "Terraform deploys applications." It doesn't, directly. Terraform provisions infrastructure — the servers, networks, and platforms your application runs on. Deploying application code is typically handled by separate tooling, often triggered after Terraform finishes.
• Treating the state file carelessly. The state file is sensitive and critical. Storing it only on a local laptop, or editing it by hand, is a common way to corrupt an environment or lose track of what Terraform manages.
• Manual changes causing drift. If someone edits a resource directly in a cloud console after Terraform created it, Terraform's record of reality becomes stale. The next plan will either try to "fix" the manual change or produce confusing output.
• Secrets ending up in state. Database passwords, API keys, and other sensitive values can end up stored in plain text inside the state file unless you actively manage secrets through a dedicated secrets manager or encryption at rest.
• Assuming plan guarantees safety. A clean plan reduces risk but doesn't eliminate it — dependencies, timing, and external changes can still produce surprises during apply.

Most of these are process failures, not tool failures. Teams that treat state management and review discipline seriously avoid the vast majority of Terraform horror stories.

Getting Started: Practical First Steps

You don't need a sprawling production environment to learn Terraform — a small, disposable project teaches the fundamentals quickly.

• Install Terraform and confirm it runs from your command line.
• Pick one provider you already have access to, rather than trying to learn multiple platforms at once.
• Write a minimal configuration — a single resource, like a storage bucket or a small virtual machine, is enough to see the full cycle work.
• Run plan, then apply, and read the output carefully both times. This is where the declarative model clicks for most people.
• Destroy it when you're done to confirm you understand teardown, not just creation.
• Adopt remote state early — even for personal projects — so you build the habit before it becomes a requirement on a shared team project.

Once the basics feel natural, the next layer is modules, variable files, and tying Terraform into a CI/CD pipeline. If you want a structured path through that progression, the Terraform Course programme covers it in depth. It's also worth exploring how Terraform-provisioned infrastructure interacts with container orchestration platforms and how teams layer zero trust security models on top of infrastructure that's defined as code.

Glossary

• HCL (HashiCorp Configuration Language): The declarative language used to write Terraform configuration files, designed to be human-readable.
• Provider: A plugin that lets Terraform talk to a specific platform's API, such as AWS, Azure, or Kubernetes.
• State file: Terraform's record of the infrastructure it manages and how it maps to your configuration, used to plan changes.
• Module: A reusable, packaged set of Terraform configuration that can be called with different inputs across projects.
• Plan: A preview step that shows what Terraform will create, change, or destroy before any action is taken.
• Apply: The step where Terraform executes the planned changes against real infrastructure.