Currently Empty: $0.00
Legendary Ways Academy · DevOps & Cloud Track
Learn Terraform the way working engineers actually use it.
A complete, practical walkthrough of Infrastructure as Code: what Terraform is, how it works, and how to start provisioning real cloud infrastructure with confidence.
2,000+ word guide
Beginner friendly
Real config example
Terraform is the tool most engineering teams reach for when they need to provision cloud infrastructure without clicking through a console by hand. Instead of manually creating servers, networks, and databases one at a time, you describe the infrastructure you want in a simple configuration file, and it gets built for you, consistently, repeatably, and across almost any cloud provider. If you’ve ever wondered what this tool actually does, why so many DevOps job postings list it as a requirement, and how to start using it, this guide walks through everything from first principles.
What Is Terraform?
Terraform is an open-source Infrastructure as Code (IaC) tool created by HashiCorp. It lets engineers define cloud and on-premises resources, servers, load balancers, databases, DNS records, networking rules, and hundreds of other resource types, in human-readable configuration files written in HashiCorp Configuration Language (HCL). Once that configuration exists, the CLI reads it, compares it against whatever infrastructure currently exists, and calculates exactly what needs to be created, changed, or removed to make reality match the plan.
This is fundamentally different from manually clicking through a cloud console. When infrastructure is defined as code, it can be version-controlled in Git, reviewed through pull requests, tested, and reused the same way application code is. That single shift is why this workflow has become foundational in modern DevOps and platform engineering, and why “Terraform” now shows up in job descriptions right alongside Docker and Kubernetes.
In short: Terraform turns infrastructure into a text file. That file becomes the single source of truth for what your environment should look like, and the tool’s entire job is to make that a reality, over and over, without drift.
Why Teams Use Terraform
Its popularity is not an accident. It solves real, recurring problems that engineering teams hit as soon as their infrastructure grows past a handful of manually managed servers.
Consistency Across Environments
The same configuration applies to dev, staging, and production, eliminating the classic “it worked on staging” problem caused by drift.
Multi-Cloud Support
Not tied to one vendor, the same workflow manages AWS, Azure, GCP, Kubernetes, and hundreds of other platforms.
Version-Controlled
Infrastructure changes go through the same Git review process as application code: diffs, approvals, full history.
Plan Before Apply
Always preview exactly what will change before anything happens. No surprises, no guessing.
Reusable Modules
Common infrastructure patterns package into modules and get reused across teams, just like software libraries.
Faster Onboarding
New engineers run one command and get a working environment that matches production, no wiki required.
“Infrastructure becomes a text file, reviewed, versioned, and reproducible, instead of remembered.”
How Terraform Works
Underneath the workflow, four core concepts explain how everything actually operates.
Providers
A plugin that lets the CLI talk to a specific platform’s API: AWS, Google Cloud, Azure, Kubernetes, and thousands more. It translates HCL into real API calls, handling authentication and request formatting behind the scenes.
Resources
A single piece of infrastructure: a virtual machine, a storage bucket, a DNS record, a firewall rule. Each resource block describes exactly what that piece should look like, down to its specific settings.
State
A file recording what infrastructure already exists and how it maps to the configuration, so each run only changes what actually needs to change instead of rebuilding everything from scratch.
Modules
A reusable, self-contained group of configuration files. Teams wrap recurring patterns, like “a standard web application stack,” into one so it can be reused instead of copy-pasted project to project.
The Terraform Workflow
Every project built this way follows the same predictable lifecycle, expressed through four commands:
1
terraform init
Downloads the providers and modules a configuration depends on and prepares the working directory.
2
terraform plan
Compares the configuration to the current state and prints exactly what will be created, changed, or destroyed.
3
terraform apply
Executes the plan and provisions the real infrastructure, asking for confirmation first.
4
terraform destroy
Tears down every resource under management, most often used to clean up temporary or test environments.
This init → plan → apply loop is the heartbeat of the entire workflow, whether you are provisioning a single storage bucket or an entire multi-region production environment.
Terraform vs. Other Infrastructure as Code Tools
It is not the only Infrastructure as Code option, and understanding how it compares helps clarify why so many teams still choose it as their default.
| Tool | Approach | Cloud Support | Best For |
|---|---|---|---|
| Terraform | Declarative, HCL | Multi-cloud (any provider) | Teams that want one consistent workflow across multiple platforms |
| AWS CloudFormation | Declarative, JSON/YAML | AWS only | AWS-only shops fully committed to native tooling |
| Pulumi | Imperative, real programming languages | Multi-cloud | Teams that prefer writing infrastructure in Python, TypeScript, or Go |
| Ansible | Procedural, YAML playbooks | Multi-cloud + config management | Configuration management and application deployment more than provisioning |
The short version: its biggest advantage is being cloud-agnostic and declarative at the same time, you describe the end state once, and the engine figures out how to get there on almost any platform, without you writing imperative step-by-step scripts.
A Simple Terraform Example
Here is a minimal configuration that provisions a single AWS S3 storage bucket, just to show what the language actually looks like in practice:
main.tf
# main.tf
terraform {
required_providers {
aws = {
source = “hashicorp/aws”
version = “~> 5.0”
}
}
}
provider “aws” {
region = “us-east-1”
}
resource “aws_s3_bucket” “example” {
bucket = “my-terraform-demo-bucket”
tags = {
Environment = “learning-terraform”
}
}
terraform {
required_providers {
aws = {
source = “hashicorp/aws”
version = “~> 5.0”
}
}
}
provider “aws” {
region = “us-east-1”
}
resource “aws_s3_bucket” “example” {
bucket = “my-terraform-demo-bucket”
tags = {
Environment = “learning-terraform”
}
}
Running terraform init followed by terraform apply against this file creates the bucket exactly as described. Change the bucket name and run apply again, and you’ll see a plan to update it, no manual console clicking required, and no guessing what changed.
Real-World Use Cases
Beyond the textbook definition, here is where this actually shows up day to day inside engineering teams:
On-Demand Environments
A pull request can trigger a temporary, isolated environment for testing, then tear it down automatically when it merges.
Multi-Account Standardization
Large organizations use modules to enforce the same networking, logging, and security baseline across dozens of accounts.
Disaster Recovery
Because the environment is described in configuration, a region-wide outage can be recovered from by re-applying the same files elsewhere.
Faster Onboarding
Instead of a wiki page of manual setup steps, a new hire runs one command and gets an environment matching production.
State Management in Detail
The state file deserves special attention because most real-world problems trace back to it. By default, state is stored locally as a JSON file, which works fine solo but breaks down the moment more than one person touches the same infrastructure, two people applying changes at once can corrupt it or silently overwrite each other’s work.
The standard fix is a remote backend: state is stored in a shared location, such as an S3 bucket, with a locking mechanism (often DynamoDB) that prevents two runs from applying changes simultaneously. Treating this file as sensitive, shared infrastructure, not a throwaway artifact, is one of the biggest mental shifts teams make when moving from solo experiments to production usage.
Best Practices & Security
A working knowledge of good habits matters more than memorizing syntax. These are the ones that prevent real incidents:
Store state remotely with locking instead of keeping it on a local laptop, so teams can collaborate safely.
Never edit state by hand, use built-in state subcommands or import blocks instead.
Separate environments so a mistake in dev can never touch production.
Always review the plan, never auto-approve an apply against production.
Pin provider and module versions to avoid “it worked yesterday” incidents.
Keep secrets out of config files entirely, use a secrets manager or environment variables.
Because configuration files often reference real infrastructure and, indirectly, real credentials, restrict who can run an apply against production through CI/CD permissions rather than personal laptops, and enable state file encryption at rest since it can contain sensitive values in plain text. Treating the state file with the same caution as a database backup is a good rule of thumb.
The Registry and Ecosystem
Most of the day-to-day experience of writing configuration happens through a public registry of pre-built providers and modules, maintained by HashiCorp and the open-source community. Rather than writing a resource block from scratch for every situation, engineers typically start by searching the registry for an existing, well-maintained module, a “VPC module” or a “Kubernetes cluster module,” for example, and then customizing it with input variables specific to their environment. This ecosystem is a big part of why the learning curve flattens out quickly after the first project: most common infrastructure patterns have already been solved and published by someone else, tested against real-world usage, and kept up to date as cloud providers change their APIs.
Want a guided path instead of piecing it together alone?
Legendary Ways Academy’s DevOps & Cloud track walks you through Terraform, Docker, and Kubernetes with real projects, not just theory.
Explore CoursesFrequently Asked Questions
Is Terraform free to use?
Yes. The core CLI is open source and free. HashiCorp also sells Terraform Cloud, a paid product with extra collaboration and governance features, but it is entirely optional.
Is Terraform hard to learn?
The basics, providers, resources, and the init/plan/apply workflow, are approachable for anyone comfortable reading structured configuration files. Depth comes from learning state management, modules, and provider-specific resources over time.
What language does Terraform use?
Configuration is written in HashiCorp Configuration Language (HCL), a declarative, JSON-compatible language designed to be both human-readable and machine-parseable.
Is Terraform the same as Kubernetes?
No. One provisions infrastructure, servers, networks, clusters, databases, while Kubernetes orchestrates containerized applications once they’re running. Many teams use both together: one to provision the cluster, the other to run workloads on it.
Do I need to know a cloud provider first?
Basic familiarity with at least one cloud provider (AWS, Azure, or Google Cloud) makes this much easier to pick up, since its resources map directly onto that provider’s own services.
How is Terraform different from a bash script?
A bash script describes steps to take; this tool describes an end state to reach. It tracks what already exists via its state file, so re-running it doesn’t recreate resources that are already correct, a plain script has no such awareness.
Getting Started with Terraform
The fastest way to actually learn it is to install the CLI, set up a free-tier account with a cloud provider, and provision something small and low-risk, a storage bucket or a single virtual machine, before moving on to multi-resource projects and modules. Reading documentation matters, but this is a hands-on tool, and the concepts in this guide click much faster once you’ve run init, plan, and apply yourself.
About Legendary Ways Academy
We teach practical, job-ready DevOps and cloud engineering skills through hands-on projects, not just slides. This guide is part of our free learning library; our full courses go deeper with guided labs and instructor support.
Terraform has become the default choice for teams that need reliable, repeatable, multi-cloud infrastructure provisioning, and once the core workflow of init, plan, and apply becomes second nature, it’s hard to go back to managing infrastructure by hand.