If you manage cloud infrastructure at any meaningful scale, you have almost certainly heard of Terraform. It has become the default tool for teams that want to define, provision, and version their infrastructure the same way they treat application code.

But for engineers who are new to it, or for teams evaluating whether it is the right fit, the question of what Terraform actually is — and what it is not — deserves a clear, honest answer.

This guide walks through how Terraform works, why teams adopt it, where it fits into a modern platform engineering workflow, and what to consider as you scale.

What You Will Find in This Guide

•        What Terraform is and the problem it solves

•        How Terraform works under the hood

•        The core Terraform workflow

•        Terraform vs manual provisioning

•        Key Terraform concepts every team should know

•        Common use cases across cloud providers

•        How Terraform fits into a larger platform engineering strategy

•        What to think about as you scale

What Is Terraform?

Terraform is an open source infrastructure as code (IaC) tool built by HashiCorp. It lets you describe your cloud infrastructure — servers, databases, networking, access policies, and more — in configuration files, and then applies those files to make your actual cloud environment match what you have described.

Instead of clicking through a cloud console or running a sequence of CLI commands that only exist in someone’s memory, you write down exactly what your infrastructure should look like. Terraform reads those files and figures out what to create, change, or delete to get there.

Terraform uses its own configuration language called HCL (HashiCorp Configuration Language). HCL is designed to be readable by humans and parseable by machines, which makes it approachable for engineers who are not professional developers but need to manage infrastructure reliably.

The Problem Terraform Solves

Before tools like Terraform became common, provisioning infrastructure meant one of two things: you either used a cloud provider’s console and clicked through a series of menus, or you wrote custom scripts in Bash, Python, or PowerShell to automate those clicks.

Both approaches work at small scale. At larger scale, they break down quickly.

The Problem with Manual Provisioning

•        No record of what was done. A server created through a console leaves no audit trail of who created it, why, or with what settings.

•        Impossible to reproduce. If a team member set up an environment six months ago and leaves the company, recreating that environment often means starting from scratch.

•        Drift accumulates over time. One team makes a change in the console to fix an urgent issue. That change never makes it into any documentation. Gradually, environments that were supposed to be identical start behaving differently.

•        Scaling is painful. Setting up a new environment for a new customer, a new region, or a new team requires repeating every manual step.

The Problem with Custom Scripts

•        Scripts are fragile. Cloud provider APIs change. Scripts written for one context often fail in another. Maintaining a library of custom scripts across multiple cloud accounts becomes a full-time job.

•        No state awareness. A script that creates a resource has no built-in way of knowing whether that resource already exists. Running it twice might create duplicates, or fail with an unhelpful error.

•        Hard to review. A 500-line Bash script that provisions an EKS cluster is difficult to review meaningfully in a pull request.

Terraform addresses all of these issues. It is declarative (you say what you want, not how to get there), stateful (it keeps track of what it has created), and reusable (the same configuration can be applied to as many environments as you need).

How Terraform Works

Terraform works through a straightforward cycle: you write configuration, Terraform compares it to the current state of your infrastructure, shows you what would change, and then applies those changes.

Providers

Terraform connects to cloud platforms and services through plugins called providers. There are providers for AWS, Azure, Google Cloud, Kubernetes, Datadog, GitHub, and hundreds of other services. Providers expose the resources you can manage — an AWS provider gives you access to EC2 instances, S3 buckets, IAM roles, and so on.

You declare which providers your configuration needs, and Terraform downloads them automatically when you initialise a project.

Resources

A resource is the basic unit in a Terraform configuration. It represents a single piece of infrastructure: one S3 bucket, one virtual machine, one database, one DNS record. You describe the desired state of that resource — its name, its settings, its size — and Terraform works out how to create or update it.

State

Terraform keeps a record of everything it has created in a state file. This is what allows Terraform to know the difference between “this resource already exists and matches the configuration” and “this resource needs to be created.”

In team environments, the state file is usually stored remotely — in an S3 bucket, Azure Blob Storage, or a managed platform like env zero — so that everyone on the team is working from the same picture of the world.

Modules

Modules are reusable packages of Terraform configuration. Instead of rewriting the same networking setup for every new environment, you put that configuration into a module and call it wherever you need it. Modules are how teams build internal libraries of approved, tested infrastructure patterns.

The Terraform Workflow

The typical Terraform workflow has three steps. Most teams run these steps inside a CI/CD pipeline, but understanding what each step does is important.

terraform init

This is the setup step. It downloads the providers your configuration requires, sets up the backend where state will be stored, and prepares your working directory. You run this once when you start working on a configuration, and again when you add new providers or change your backend.

terraform plan

This is the preview step. Terraform reads your configuration, compares it to the current state, and produces a detailed plan showing exactly what it would create, change, or destroy if you applied the configuration. Nothing changes in your infrastructure at this point.

The plan is one of the most valuable parts of the Terraform workflow. Reviewing it carefully — ideally in a pull request, before merging — is how teams catch mistakes before they become incidents. 

terraform apply

This is the execution step. Terraform takes the plan it produced and carries it out, making the necessary API calls to your cloud provider. It updates the state file when it is done.

In well-run teams, applies only happen after a plan has been reviewed and approved. Many teams add an explicit approval step — either a manual sign-off or an automated policy check — before any apply runs in a shared environment.

Key Terraform Concepts to Know

You do not need to master every detail of Terraform before you start using it. But a few concepts come up quickly, and understanding them early saves a lot of confusion.

•        Variables. Variables let you pass different values into the same configuration — different instance sizes for different environments, for example. They make configurations reusable without changing the underlying code.

•        Outputs. Outputs expose values from a Terraform configuration so they can be used by other configurations or passed to other tools. For example, a networking module might output the IDs of the subnets it created so an application module can reference them.

•        Data sources. Data sources let you look up information about existing resources that Terraform did not create. If you need to reference an existing VPC or an AMI ID in your configuration, you use a data source.

•        Local values. Locals let you define named expressions within a configuration to avoid repeating yourself. They are similar to variables but are computed internally rather than passed in from outside.

•        For expressions. Terraform’s for expressions (including for_each and count) let you create multiple similar resources from a single block of configuration. Rather than writing twenty nearly identical resource blocks, you write one and loop over a list.

•        The Terraform Registry. The Registry is where providers and modules are published and discovered. It is the first place to look when you need a provider for a service you have not used before, or when you want to find a community module for a common pattern.

 What Teams Use Terraform For

Terraform is cloud-agnostic, which means it works across AWS, Azure, Google Cloud, and many other platforms. In practice, most teams use it for a mix of the following:

Provisioning Core Cloud Infrastructure

Virtual machines, container clusters, load balancers, databases, storage buckets, and networking components. This is the most common use case and where Terraform is most mature.

Managing Access and Identity

IAM roles, service accounts, and permissions are infrastructure too. Managing them in Terraform means access policies go through the same review process as everything else, which reduces the risk of accidental over-permission.

Deploying Kubernetes Infrastructure

Terraform is commonly used to provision the underlying Kubernetes clusters (EKS, AKS, GKE), while separate tools like Helm or Argo CD handle what runs inside them. The two layers work well together.

Setting Up Developer Environments

Platform teams use Terraform to offer self-service environment provisioning. A developer submits a request, Terraform runs, and a fully configured environment appears — without the platform team needing to be involved in every deployment.

Multi-Cloud and Multi-Region Deployments

Because Terraform uses providers rather than cloud-specific syntax, the same workflow applies whether you are deploying to one cloud or several. Teams running workloads across multiple regions or multiple providers find this consistency valuable.

Where Terraform Fits in a Larger Platform Strategy

Terraform is a tool, not a complete platform engineering strategy. Understanding where it fits — and where it needs support — helps teams avoid some common pitfalls.

Terraform Handles the What, Not the How of Collaboration

Terraform tells your cloud provider what infrastructure to create. It does not, on its own, handle who is allowed to run plans, how approvals work, where state is stored and who can access it, or how costs are tracked and controlled. Those are governance questions, and they require answers before Terraform scales beyond a small team.

Drift Is a Real Concern

Even with Terraform in place, infrastructure can drift. Someone makes an emergency change in the console. A resource is modified by another tool. A provider update changes default values. Detecting and resolving drift is an ongoing operational responsibility, not a one-time setup task.

The Terraform Registry Is Powerful but Requires Curation

Community modules accelerate development but introduce risk. A module that was last updated two years ago may use deprecated patterns or miss recent security guidance. Platform teams benefit from maintaining an internal module registry with approved, tested patterns — and from enforcing that internal modules are used in shared environments.

State Management Needs Attention

Remote state is not optional in team environments. Deciding where state lives, who can access it, how it is backed up, and how locking is handled are decisions that need to be made early. Getting this wrong is one of the most common sources of problems as teams scale.

Getting Started with env zero

Teams that are new to Terraform often start with the open source CLI and grow into automation as their needs increase. The transition point usually comes when more than a few people are running Terraform commands, when environments start to diverge from one another, or when leadership starts asking questions about cost and compliance.

env zero sits on top of Terraform (and OpenTofu) to handle the operational layer: remote state management, plan-and-apply workflows with approval gates, drift detection, cost estimation before deployment, and RBAC across teams and environments.

It is designed for teams that have outgrown the manual workflow but want to keep the flexibility and familiarity of their existing Terraform configurations. Your HCL stays exactly as it is — env zero adds the governance and automation layer around it.

Summary

Terraform is the most widely adopted infrastructure as code tool in the industry, and for good reason. It makes infrastructure reproducible, reviewable, and scalable in ways that manual provisioning and custom scripts cannot match.

The core idea is simple: describe what you want, let Terraform work out how to get there, review the plan before anything changes, and apply with confidence. That loop — write, plan, review, apply — is what makes infrastructure manageable at scale.

The operational questions around state management, access control, cost visibility, and drift detection are real, and they need answers as teams grow. Tools like env zero exist to fill that gap, so teams can focus on building rather than on managing the management layer.

‍