DevOps, SRE & Cloud Interview · Infrastructure as Code & Config · Lesson 2 of 2
State, locking & modules
Terraform tracks what it manages in a state file — a mapping between your config and the real resource IDs. State is what lets it compute diffs and know what to change or destroy. Managing state well is where teams get burned.
- Remote state: store state in a shared backend (S3, Terraform Cloud), not on a laptop, so the team shares one source of truth.
- State locking: prevent two people applying at once (which would corrupt state) via a lock — natively on S3 in modern Terraform (
use_lockfile, 1.10+), or the legacy DynamoDB table. Concurrent applies are the classic way to wreck state. - Secrets in state: state can contain sensitive values in plaintext — encrypt the backend and restrict access; never commit state to Git.
- Modules: reusable, parameterized bundles of resources (a 'network' module, a 'service' module) — DRY infra, consistent patterns across environments.
Why state existsIf asked 'why does Terraform need state?': it needs a record mapping declared resources to real cloud IDs so it can compute the diff and know what to update or destroy. Without state it could not tell an update from a create, or detect drift.
◆ Lock it in
- State maps config to real resource IDs — it is how Terraform computes diffs.
- Use remote state + locking so a team shares one truth and cannot corrupt it with concurrent applies.
- State can hold secrets: encrypt it, restrict access, never commit it; use modules to stay DRY.
Feynman drill — say it out loudExplain why Terraform keeps a state file and why remote state with locking matters for a team.
Step 1 rate your confidence · Step 2 pick your answer
Why is remote state with locking important for a team using Terraform?
Step 1 — how sure are you?