Terraform Complete Guide 2026: State, Modules, CI/CD, Multi-Account & Interview Q&A

Terraform is the industry-standard Infrastructure as Code tool for DevOps and platform engineering. I use Terraform daily in production — provisioning EKS clusters, VPCs, RDS instances, IAM roles, and CloudFront distributions across multiple AWS accounts. This guide covers Terraform from core concepts to advanced patterns used in real production environments, with the depth needed to pass senior DevOps interviews.

What is Terraform and Why Is It the Standard?

Terraform by HashiCorp lets you define cloud infrastructure as declarative HCL (HashiCorp Configuration Language) code. You describe the desired end state of your infrastructure, and Terraform figures out how to create, update, or delete resources to reach that state. This is fundamentally different from scripting (Bash, Python boto3) where you write imperative steps — Terraform handles the dependency resolution, ordering, parallelisation, and state tracking for you.

Terraform won the IaC landscape because of three things: provider ecosystem (2,000+ providers covering every cloud, SaaS tool, database, and monitoring platform), the plan/apply workflow (you see exactly what will change before it changes — no surprises), and the module system (reusable, versioned infrastructure components that standardise patterns across teams). AWS CloudFormation covers AWS only. Pulumi is a code-based alternative but has a smaller community. Terraform has the largest ecosystem, most job postings, and most production deployments.

Core Concepts — State, Plan, Apply, Destroy

Terraform's workflow has four phases that you must understand deeply for interviews:

• terraform init — Initialises the working directory. Downloads provider plugins (the AWS, GCP, or Kubernetes provider binaries), initialises the backend (where state is stored), and installs any modules referenced. Must be run after any change to provider versions or backend configuration. Safe to run repeatedly — it is idempotent.
• terraform plan — Compares the desired state (your HCL code) against the current state (the state file) and the real infrastructure (by calling cloud provider APIs). Outputs a diff showing exactly which resources will be created (+), updated (~), or destroyed (-). Critically: a plan that shows no changes is your confirmation that real infrastructure matches your code. Always review the plan before applying.
• terraform apply — Executes the plan. Calls provider APIs to create, update, or delete resources. Updates the state file after each resource operation. Can be run with -auto-approve in CI/CD to skip the interactive prompt — but only after the plan has been reviewed and approved in a prior pipeline stage.
• terraform destroy — Creates a plan to destroy all resources in the state file, then applies it. Irreversible. In production, protect against accidental destroy with lifecycle { prevent_destroy = true } on critical resources (databases, S3 buckets) and by restricting who can run destroy in your CI/CD pipeline.

Terraform State — The Most Critical Concept

Terraform state is the source of truth for what Terraform has created. It maps your HCL resource definitions to real infrastructure resource IDs. Without state, Terraform cannot know what already exists and would try to create everything from scratch on every apply, causing duplicate resources and errors.

Never store Terraform state locally in production. Local state is not shared between team members, is lost if the developer's machine is lost, and cannot support locking (preventing simultaneous applies). Always use remote state with state locking:

Variables, Outputs, and Locals

Modules — Reusable Infrastructure Components

Modules are Terraform's code reuse mechanism. A module is a directory of .tf files with a defined interface (input variables and output values). The same module can be called multiple times with different inputs to create similar infrastructure for different environments or teams. Well-designed modules reduce duplication, enforce standards, and make large Terraform codebases manageable.

Workspaces vs Separate State Files

Terraform workspaces allow multiple state files within a single backend, identified by workspace name. The default workspace is called "default". You can create a "staging" and "production" workspace within the same backend bucket. Workspaces are most useful for short-lived feature environments (PR environments) where the infrastructure is identical but needs isolation.

For long-lived environments (dev, staging, production) most experienced teams use separate state file paths instead of workspaces. Separate paths give clearer isolation, simpler blast radius, and avoid the common mistake of accidentally applying production changes to staging (or vice versa) by being in the wrong workspace. Use workspaces for ephemeral environments; use separate backends or state key paths for permanent environments.

Terraform in CI/CD — The GitOps Workflow

Running Terraform manually is only acceptable for initial bootstrapping. Production infrastructure changes must go through a CI/CD pipeline with plan review and approval gates. The standard pattern I use with GitHub Actions:

Production Best Practices

• Use lifecycle prevent_destroy for critical resources. Add lifecycle { prevent_destroy = true } to RDS instances, S3 state buckets, and production EKS clusters. This causes Terraform to error instead of destroying these resources, even with terraform destroy.
• Tag everything with a common_tags local. Define a locals block with standard tags (Environment, Project, ManagedBy, Owner, CostCenter) and apply them to every resource. AWS Cost Explorer, resource group searches, and security audits all depend on consistent tagging.
• Use data sources to reference existing resources. If a resource was not created by Terraform, use a data source to look it up: data "aws_vpc" "existing" { filter { name="tag:Name"; values=["prod-vpc"] } }. Never hardcode ARNs or IDs — they change between accounts and environments.
• Pin provider versions. Use version constraints like ~> 5.0 (allow 5.x but not 6.x) for providers. A major provider version bump can contain breaking changes that silently destroy and recreate resources.
• Separate state per service. Don't put all infrastructure in one state file. Separate by: networking (VPC, subnets), compute (EKS, node groups), data (RDS, ElastiCache), and application (Helm releases). This limits blast radius and plan runtime.
• Use sensitive = true for secret variables. Variables marked sensitive are never printed in plan or apply output, reducing the risk of secrets appearing in CI/CD logs.

Common Terraform Errors and How to Fix Them

• Error acquiring state lock — Another apply is running (or a previous one crashed without releasing the lock). Run terraform force-unlock LOCK_ID with the lock ID shown in the error. Only do this if you are certain no other apply is actually running.
• Error: Resource already exists — The resource exists in AWS but not in Terraform state. Import it: terraform import aws_s3_bucket.my_bucket my-existing-bucket-name. After import, run plan to verify no unintended changes.
• Plan shows unexpected destroy of critical resource — Usually caused by renaming a resource block (Terraform sees it as destroy old + create new), moving a resource into or out of a module, or changing a force-new argument. Use terraform state mv to rename resources in state without destroying them. Use moved blocks (Terraform 1.1+) for module refactoring.
• Provider authentication errors in CI/CD — Never use long-lived IAM access keys in CI/CD. Use OIDC federation: GitHub Actions, GitLab CI, and CircleCI all support assuming an IAM role via OIDC without stored credentials. This generates temporary credentials per pipeline run.

12 Terraform Interview Questions with Expert Answers