How Terraform Works
IntermediateTerraform is an infrastructure-as-code tool: you describe the cloud resources you want in declarative configuration, and Terraform makes reality match. Instead of clicking through a console, you write what should exist, and Terraform figures out what to create, change, or destroy. It tracks what it manages in a state file, shows you a plan before making changes, and uses providers to talk to AWS, GCP, Azure, and hundreds of other platforms.
Think of Terraform as a blueprint plus a diligent builder
You hand over a blueprint describing the finished house (declarative config) rather than step-by-step build instructions. A meticulous builder compares the blueprint to what is already on site (the state), tells you exactly what they will add, change, or demolish before touching anything (the plan), and only then does the work (apply). Update the blueprint and they adjust just the difference — they never rebuild the whole house.
Step by Step
Key Concepts
Declarative Infrastructure
You describe the desired end state, not the steps. Terraform computes the actions needed to reach it, so the same config always converges to the same infrastructure (idempotent).
State File
Terraform record of the resources it manages and their real IDs. It enables diffing, drift detection, and safe updates — and must be stored securely (often in a remote backend with locking) for teams.
Plan vs Apply
plan previews the changes (add/change/destroy) without touching anything; apply executes them. The plan-then-apply flow prevents surprise changes to production infrastructure.
Providers
Plugins that implement resource types for a platform (AWS, Kubernetes, Cloudflare). They translate Terraform declarative resources into concrete API calls, making the tool multi-cloud.
Key Facts
- Terraform is declarative and idempotent: applying the same config repeatedly converges to the same state without duplicating resources.
- The state file is sensitive and central — use a remote backend with locking so team members do not corrupt it with concurrent applies.
- Terraform manages infrastructure (provisioning), while configuration tools like Ansible manage what runs on it — they are complementary, not competitors.
Real-World Applications
Reproducible environments
The same Terraform config provisions identical dev, staging, and production environments, eliminating "works in staging" drift and letting you rebuild an environment from code if it is lost.
Safe infrastructure changes in CI
A pull request runs terraform plan so reviewers see exactly what will change in production; merging triggers apply, giving infrastructure the same review and audit trail as application code.
Frequently Asked Questions
What is Terraform and how does it work?
Terraform is an infrastructure-as-code tool where you declare the cloud resources you want in configuration files, and it makes your real infrastructure match. It uses providers to talk to platforms like AWS and Azure, records what it manages in a state file, shows you a plan of changes before applying them, and then creates, updates, or destroys resources in dependency order to reach your desired state.
What is the Terraform state file?
The state file is Terraform record of the real resources it has created and their actual IDs, mapping your configuration to what exists in the cloud. It lets Terraform detect differences (drift) between your config and reality and calculate what to change. Because it can contain sensitive data and is central to correctness, teams store it in a remote backend with locking to prevent concurrent corruption.
What is the difference between terraform plan and apply?
terraform plan compares your desired configuration to the current state and shows exactly what it would add, change, or destroy — without making any changes. terraform apply then executes that plan, actually provisioning the infrastructure. The plan-then-apply workflow is a key safety feature, letting you review changes before they touch production.
Is Terraform declarative or imperative?
Terraform is declarative: you describe the desired end state of your infrastructure rather than the sequence of steps to achieve it. Terraform figures out the actions needed and executes them idempotently, so applying the same configuration repeatedly converges to the same result without creating duplicate resources. This contrasts with imperative scripts that specify each step explicitly.