Terraform — The Interview Cheatsheet.

# remote, locked, versioned backend (the right setup for teams)
terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "prod/app.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tf-locks"     # state locking
    encrypt        = true
  }
}

6. Drift & imports

Drift = real infra changed outside Terraform (a console click). Detect: terraform plan -refresh-only. Reconcile by updating config to match reality, or let Terraform revert the manual change. Import existing resources so TF manages them:

# import block (TF 1.5+) — reviewable, in code
import {
  to = aws_s3_bucket.logs
  id = "my-existing-bucket"
}
# then: terraform plan -generate-config-out=generated.tf

7. Modules

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.0"
  name    = "main"
  cidr    = "10.0.0.0/16"
  azs     = ["us-east-1a", "us-east-1b"]
}
# consume outputs elsewhere:
resource "aws_instance" "web" { subnet_id = module.vpc.public_subnets[0] }

• Module sources: local path, Terraform Registry, Git, S3.
• Inputs = variable blocks; returns = output blocks.
• Pin version on registry modules; keep modules small + composable.

8. Environments & workspaces

terraform workspace list / new staging / select prod
# terraform.workspace is available in config

Workspaces give multiple states from one config — fine for light dev/staging splits. For real prod isolation prefer separate state files / directories per environment (and often separate backends/accounts) so a mistake in dev can't touch prod.

9. Provisioners (last resort)

local-exec / remote-exec run scripts during create/destroy. Avoid them — they're not tracked in state, break idempotency, and fail unpredictably. Prefer cloud-init / user_data, configuration management, or baked images (Packer). If you must, pair with null_resource + triggers.

10. Best practices

• Remote, locked, versioned state backend; one state per environment.
• Pin required_version, provider versions, and module versions.
• Never commit secrets or state to git; mark sensitive outputs sensitive = true.
• plan in CI on every PR; gated apply on merge (apply the saved plan).
• Prefer data sources + for_each over copy-paste; small modules.
• Use -target and force-unlock rarely — they hide problems.
• terraform fmt + validate + a linter (tflint) + a policy gate (OPA/Sentinel) in CI.

11. Troubleshooting

12. Rapid-fire Q&A

• What is state and why does it matter?JSON mapping config to real resource IDs. It's how TF knows what exists, computes diffs, and avoids recreating things. Lose/corrupt it and TF loses track of your infra.
• count vs for_each?count = index-keyed (shifts on removal → recreation); for_each = key-keyed (stable). Prefer for_each.
• plan vs apply?plan computes/preview the diff; apply executes it. In CI, save a plan and apply exactly that.
• How do you manage existing infra?terraform import (or import blocks) to bring it under state, then plan should be a no-op.
• How do teams share state safely?Remote backend with locking (S3+DynamoDB / TF Cloud) so applies serialize; encrypted, versioned.
• local vs variable vs output vs data?local = computed reuse; variable = input; output = exposed/module return; data = read existing infra.
• What is drift?Real infra changed outside Terraform. Detect with plan -refresh-only; reconcile.
• create_before_destroy?Lifecycle rule to make the replacement before destroying the old — avoids downtime on replace.
• Why avoid provisioners?Not in state, not idempotent, fail unpredictably. Prefer user_data / images / config management.
• How is dependency order decided?Implicitly, by attribute references between resources; depends_on only when there's no reference.