Overview
- 1Terraform is an open-source Infrastructure as Code (IaC) tool from HashiCorp that lets teams define cloud and on-prem infrastructure in human-readable configuration files.
- 2It uses its own declarative language, HashiCorp Configuration Language (HCL), to describe the desired end-state of infrastructure rather than the exact steps to reach it.
- 3Terraform works through a plugin-based provider model, with providers available for AWS, Azure, Google Cloud, Kubernetes, and hundreds of other services.
- 4A core concept is the state file, which maps real-world resources to your configuration so Terraform can calculate diffs and know what to create, update, or destroy.
- 5The standard write-plan-apply workflow makes infrastructure changes predictable, reviewable, and repeatable across environments and teams.
Key Features in 1.10
Declarative HCL syntax for defining resources, data sources, variables, and outputs
Provider ecosystem spanning major clouds, SaaS platforms, and networking/security tools
Plan/apply workflow that previews changes before they are made to real infrastructure
Remote state backends (S3+DynamoDB, Azure Blob, GCS, HCP Terraform) with locking to prevent conflicts
Reusable modules for packaging and sharing infrastructure patterns
Workspaces for managing multiple environments (dev/staging/prod) from one configuration
Drift detection and `terraform import`/`plan -refresh-only` for reconciling manual changes
Use Cases
- →Provisioning multi-cloud infrastructure (VPCs, compute, storage, networking) from a single codebase
- →Standing up Kubernetes clusters and the surrounding cloud resources they depend on
- →Managing infrastructure for CI/CD pipelines so environments are created and torn down consistently
- →Enforcing compliance and governance via policy-as-code (Sentinel/OPA) alongside version-controlled infrastructure changes
HCL Language Fundamentals
- Resources define infrastructure objects; data sources fetch read-only information from providers or existing infrastructure
- Input variables and outputs let modules and configurations pass values between each other
- Local values (`locals`) compute derived values that are reused throughout a configuration
- Expressions support string interpolation, conditionals, and built-in functions for string, list, and map manipulation
- `for_each` and `count` create multiple instances of a resource from a single block
- `depends_on` and implicit reference-based dependencies control the order resources are created in
- Provider blocks configure credentials, regions, and aliases for multiple instances of the same provider
State Management
- The state file (terraform.tfstate) tracks the mapping between configuration and real-world resource IDs
- Remote backends like S3 with DynamoDB locking, Azure Blob Storage, GCS, or HCP Terraform store state centrally and prevent concurrent writes
- State locking stops two team members or CI runs from applying changes to the same infrastructure simultaneously
- `terraform state` subcommands (list, mv, rm, show) let you inspect and safely modify state without touching real infrastructure
- Sensitive values in state should be protected via encrypted backends, strict access controls, and ephemeral values that avoid persisting secrets at all
- `terraform plan -refresh-only` reconciles state with actual infrastructure to surface drift caused by manual or out-of-band changes
- State should never be hand-edited; `import` blocks and `moved` blocks are the safe way to bring existing resources under management or rename them
Modules & Providers
- Modules bundle resources into reusable, parameterized units published to the public Terraform Registry or a private registry
- The root module calls child modules via `module` blocks, passing inputs and consuming their outputs
- Version constraints on modules and providers keep environments reproducible across a team
- Providers are plugins that translate HCL into API calls; most major clouds, SaaS tools, and platforms like Kubernetes or Helm have official or community providers
- Provider aliases allow managing resources across multiple regions or accounts from within one configuration
- The public Terraform Registry hosts thousands of community and HashiCorp-verified modules and providers so teams avoid reinventing common patterns
- `terraform init` downloads providers and records their exact versions in the `.terraform.lock.hcl` file for consistent, repeatable builds
CI/CD & Best Practices
- Run `terraform fmt` and `terraform validate` in CI to enforce consistent style and catch syntax errors early
- Store state remotely with locking rather than locally, especially once more than one person touches a configuration
- Use separate workspaces or directory structures per environment instead of duplicating configuration code
- Pin provider and module versions so upstream updates cannot introduce unplanned drift
- Require `terraform plan` output to be reviewed, for example posted as a pull request comment, before `apply` runs
- Use policy-as-code tools like Sentinel or Open Policy Agent to enforce guardrails on what plans are allowed to apply
- Keep secrets out of state and version control by using ephemeral values, environment variables, or a dedicated secrets manager integration
Frequently Asked Questions
What is Terraform used for?▼
Terraform is an open-source Infrastructure as Code tool that lets you define, provision, and manage cloud and on-premises infrastructure using declarative configuration files. Instead of manually clicking through cloud consoles, you describe the desired state of servers, networks, databases, and other resources in HCL, and Terraform figures out how to create, update, or destroy them to match. It supports hundreds of providers, so the same workflow applies whether you're managing AWS, Azure, GCP, or on-prem systems.
What is Terraform state and why does it matter?▼
Terraform state is a file, typically terraform.tfstate, that maps the resources defined in your configuration to the real-world objects Terraform created, along with metadata about their current attributes. Terraform uses this file to calculate what changed since the last apply, so losing or corrupting it means Terraform no longer knows what it manages. Because state can contain sensitive data, teams store it in remote backends with locking and encryption rather than committing it to version control.
Terraform vs Ansible vs Pulumi - what is the difference?▼
Terraform and Ansible both automate infrastructure, but Terraform is primarily a declarative provisioning tool that tracks state to manage the full lifecycle of resources, while Ansible is an imperative configuration management tool better suited to configuring software on servers that already exist. Pulumi covers similar ground to Terraform but lets you write infrastructure definitions in general-purpose languages like TypeScript, Python, or Go instead of HCL. Many teams combine Terraform for provisioning with Ansible for configuration and application-level setup.
What is Terraform vs OpenTofu?▼
OpenTofu is an open-source fork of Terraform created in 2023 under the Linux Foundation after HashiCorp changed Terraform's license from the MPL to the more restrictive Business Source License. OpenTofu aims to remain a drop-in, MPL-licensed alternative that stays compatible with existing Terraform configurations, modules, and providers. Terraform itself continues to be developed by HashiCorp, now part of IBM, under the BSL, which restricts building competing commercial products on top of it but leaves ordinary usage largely unaffected.
How do Terraform modules work?▼
A module is a directory of Terraform configuration files that accepts input variables and produces outputs, letting you package a reusable piece of infrastructure such as a VPC or a Kubernetes cluster. You call a module from another configuration with a `module` block, pointing at a local path, the public Terraform Registry, or a private registry or Git repository. Modules keep configurations DRY and let teams standardize patterns like a shared networking layer or a standard storage bucket across projects.
What is the Terraform plan/apply workflow?▼
`terraform plan` compares your configuration against the current state and shows exactly what will be created, changed, or destroyed without making any changes - it is a dry run. `terraform apply` executes that plan against real infrastructure, prompting for confirmation unless run non-interactively as in CI/CD. This two-step workflow is central to Terraform's safety model, since it lets engineers review the blast radius of a change before committing to it.