Terraform & Infrastructure as Code Cheat Sheet

Infrastructure as Code means your cloud resources are declared in versioned text files and materialized by a tool, instead of clicked together in a console. Terraform is the declarative, cloud-agnostic standard: you write the desired end state in HCL, and Terraform diffs it against what actually exists and computes the minimal set of creates/updates/destroys to converge. Declarative (describe WHAT, the tool derives HOW) beats imperative scripts because it is idempotent - applying twice changes nothing the second time. Providers translate HCL resources into cloud API calls (AWS, GCP, Azure, GitHub, Datadog - same workflow everywhere). Interviews probe three things: do you understand state, can you narrate the plan/apply lifecycle safely, and have you been burned by the gotchas at the bottom of this sheet.

Why state exists

The cloud has no idea which S3 bucket 'belongs to' your config. State records resource addresses -> real IDs plus attributes, so Terraform can diff desired vs actual and know what to update or destroy rather than re-create.

Remote backend

Local terraform.tfstate on a laptop means no team access, no durability, and merge disasters. Production state lives in a remote backend - S3, GCS, Azure Blob, or Terraform Cloud/HCP - versioned and encrypted at rest.

State locking

Two concurrent applies against one state file corrupt it. Backends acquire a lock per operation (DynamoDB table alongside S3, or S3-native lockfile on recent versions; GCS and Terraform Cloud lock natively). 'Error acquiring the state lock' means someone else is mid-apply - investigate, don't force-unlock reflexively.

Secrets in state

State stores resource attributes VERBATIM - database passwords, private keys, anything a provider returns. Marking a variable sensitive only hides it from CLI output, not from the state file. Treat state as a secret: encrypt it, restrict who can read the bucket, never commit it to git.

State surgery

terraform state mv (rename/refactor without destroy), terraform state rm (forget a resource without destroying it), import (adopt an existing resource). These edit the mapping, never the real infrastructure - the standard tools for refactoring config safely.

terraform_remote_state / data sources

One stack can read another stack's outputs (network stack exports subnet IDs, app stack consumes them). Prefer explicit data sources or a small interface of outputs over one giant shared state.

The loop is write -> init -> plan -> apply. terraform init downloads providers and modules and configures the backend - run it once per checkout and after backend/provider changes. terraform plan refreshes state against reality, diffs it with your config, and prints the execution plan: + create, - destroy, ~ update in-place, and -/+ destroy-then-recreate (REPLACE - the one to read twice, because some attribute changes force replacement and that can mean data loss on a database or reshuffling on a stateful node). terraform apply executes a plan. The production-grade habit: terraform plan -out=tfplan, review it (in CI, post it to the PR), then terraform apply tfplan - applying a SAVED plan guarantees exactly what was reviewed is what runs, with no re-plan window for the world to change underneath you. A bare terraform apply re-plans and prompts, which is fine interactively and wrong in automation. terraform destroy tears everything in the state down - in production it should be blocked by policy and prevent_destroy, not by hoping nobody types it.

Module

A directory of .tf files - the unit of reuse. The root module is where you run terraform; child modules are called with module blocks (source = "./modules/vpc" or a registry path). Good modules wrap one cohesive concern (a VPC, a service) behind a small variable/output interface.

Variables

variable blocks declare inputs with type, default, description, validation, and sensitive. Precedence (later wins): defaults < env TF_VAR_name < terraform.tfvars < -var-file < -var. Per-environment config = one directory or workspace per env feeding different tfvars into the same modules.

Outputs

output blocks export values - from a child module to its caller, and from the root module to humans, CI, and other stacks (via remote state). A module's outputs are its public API; keep them deliberate.

Locals

locals are named expressions for readability and DRY (common tags, computed names). Unlike variables they cannot be set from outside - use them for derivation, not configuration.

Version pinning

Pin providers (required_providers with ~> constraints) and module sources (?ref=v1.2.0 / registry versions), and commit .terraform.lock.hcl. An unpinned provider upgrading itself in CI is a classic surprise-diff generator.

Drift is reality diverging from state: someone hot-fixes a security group in the console, an autoscaler resizes something, a script deletes a resource Terraform still thinks exists. Terraform notices during the refresh phase of the next plan, and the plan will propose reverting the manual change - which is either exactly what you want (the console change was a mistake) or a production incident (the console change was the fix). Detect drift proactively with a scheduled terraform plan -detailed-exitcode in CI (exit 2 = changes pending = drift alarm); reconcile by either updating the config to match reality or letting apply revert it - a deliberate decision, never a shrug. Import is the other direction: infrastructure that predates Terraform gets adopted with terraform import (or, on 1.5+, declarative import blocks that show the adoption in a plan). Import only writes the state mapping - you still write the matching resource block, and iterate until plan shows no diff. That 'import, then plan-until-clean' loop is how legacy consoles get migrated into IaC one resource at a time.

• ·prevent_destroy (lifecycle block) on databases, state buckets, and KMS keys - it turns 'terraform typo'd into destroying prod' into a plan-time error. Note it also blocks legitimate replacements until removed - that friction is the feature.
• ·Secrets end up in state verbatim - sensitive = true masks output, not storage. Encrypt the backend, lock down read access, and prefer resources that avoid materializing secrets (IAM auth, secret-manager references) over passwords in attributes.
• ·Replace (-/+) is destroy-then-create - on a DB or stateful node that is data loss. Read plans for forced replacement and use create_before_destroy where ordering matters.
• ·-target skips dependency resolution - it exists for surgical emergencies and leaves a partially-converged stack. If -target is routine, the stack is too big; split it.
• ·Applying without a saved plan in CI - plan -out + apply <planfile> is the only way to guarantee the reviewed diff is the executed diff.
• ·Giant single state = long plans, broad blast radius, and one lock for the whole company - split state by ownership and change cadence (network / data / per-service).
• ·terraform.tfstate or .terraform/ committed to git - state leaks secrets and the providers dir is huge. Both belong in .gitignore from day one.
• ·Unpinned providers/modules - a minor provider release can change defaults and produce surprise diffs in every stack the same morning. Pin and commit the lock file.

• ·Everything through code - if it matters, it is declared, reviewed, and versioned; console access in prod is read-only outside break-glass.
• ·Idempotent and convergent - applying the same config twice is a no-op; the tool converges reality toward the declaration, not a script of steps.
• ·Immutable-leaning - prefer replacing servers/images over mutating them in place; drift has nowhere to accumulate.
• ·Reviewed like code - infra changes go through PRs with the plan output attached; the plan IS the review artifact.
• ·Environments differ by data, not by structure - same modules everywhere, different tfvars; a prod-only architecture is an untested architecture.
• ·State is production data - remote, encrypted, locked, access-controlled, and recoverable (versioned bucket).
• ·Least-privilege automation - CI applies with a scoped role per stack, not an org-admin key shared by everything.