Terraform — Cheat Sheet

Tags: terraform, iac, hcl, devops, cloud, state, infrastructure

Level: intermediate

TL;DR: Declarative Infrastructure as Code tool using HCL to manage cloud resources via state management, execution plans, and immutable deployments.

Key concepts

Declarative Infrastructure as Code expressing desired target state.

HashiCorp Configuration Language (HCL) human-readable declarative syntax.

Terraform core engine compares config against state to build execution graphs.

Providers act as plugins translating HCL blocks into target API calls.

State file maps declarative resources to real-world cloud identifiers.

Remote backends store state with locking to prevent concurrent writes.

Plan phase creates an execution graph showing additions, modifications, and deletions.

Immutability prefers resource recreation over in-place mutations when drift occurs.

Modules package reusable infrastructure components with inputs and outputs.

Data sources fetch existing infrastructure attributes without managing lifecycle.

Typical questions and ready answers

Q: How do you handle state locking in a multi-developer team?R: I configure a remote backend like AWS S3 combined with DynamoDB for state locking, or Terraform Cloud/Consul, preventing concurrent pipeline runs from corrupting the state file.

Q: What is the difference between terraform plan and terraform apply?R: plan refreshes state, computes resource differences, and displays an execution diff without altering infrastructure; apply executes those exact planned changes against cloud APIs.

Q: How do you import existing infrastructure that was created manually?R: I write the matching resource block in HCL, run terraform import <resource.name> <id>, and verify with terraform plan until no unwanted drift remains.

Q: When would you use taint or -replace?R: When a resource is corrupted or unhealthy and must be destroyed and recreated on the next apply, without modifying the underlying configuration file.

Q: How do dynamic blocks differ from for_each?R: for_each iterates over whole resources or modules, whereas dynamic blocks iterate inside nested configuration blocks within a single resource.

Pitfalls and common mistakes

Committing plain .tfstate files containing plaintext secrets to Git repositories.

Modifying infrastructure manually in the cloud console, introducing undetected state drift.

Renaming resources in code without moved blocks, causing unnecessary destroy-and-recreate cycles.

Forgetting state lock handling, allowing overlapping automated CI/CD runs to cause corruption.

Hardcoding provider credentials directly in root configuration files instead of using environment variables.

Using local file backend for collaborative production workflows instead of remote backends.

Snippets and commands

# Workflow basics
terraform init -upgrade
terraform fmt -recursive
terraform validate
terraform plan -out=tfplan
terraform apply tfplan
terraform destroy

Terraform

# Backend with S3 and DynamoDB state lock
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "prod-tf-state-bucket"
    key            = "vpc/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Terraform

# Dynamic block example
resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow inbound web traffic"
  vpc_id      = var.vpc_id

  dynamic "ingress" {
    for_each = var.ingress_ports
    content {
      from_port   = ingress.value
      to_port     = ingress.value
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
}

Terraform

# Refactoring resources safely without destroy
moved {
  from = aws_instance.web
  to   = module.web_server.aws_instance.this
}

To review

[ ] Refactoring state safely using terraform state mv and moved blocks

[ ] Drift detection patterns and scheduled plan reconciliations in CI

[ ] Provider version constraints and lockfile (.terraform.lock.hcl) strategy

[ ] Handling sensitive variables with sensitive = true attribute

[x] Core workflow: init, plan, apply, destroy lifecycle

[x] Writing reusable root and child modules with typed variables

References

Terraform Core Documentation (developer.hashicorp.com/terraform/docs)

Terraform Language HCL Specification (developer.hashicorp.com/terraform/language)

Terraform AWS Provider Documentation (registry.terraform.io/providers/hashicorp/aws)

Jarvis Interviews
Jarvis