Two people applied against the same state at nearly the same time; now the state is inconsistent with reality — resources Terraform thinks exist don't, or vice-versa, and plans show bizarre changes.

What is actually happening (the mental model).

Terraform reads state, computes a plan, and writes state back. If two applies interleave without a lock, they race — each overwrites the other's view, and the result is a state that no longer matches reality. The root cause is no state locking, which a proper remote backend provides. Recovery leans on state versioning (you kept it, right?).

How to work through it.

1. Stop further applies — lock the workspace / freeze.
2. Restore from a prior state version — S3 bucket versioning (or Terraform Cloud/managed backend history) lets you roll back to the last consistent state.
3. Reconcile carefully — run terraform plan and scrutinise it against reality before applying anything; use terraform refresh/state commands to align state with actual resources if needed.
4. Fix the root cause: a remote backend with locking — S3 + a DynamoDB lock table, or a managed backend (Terraform Cloud/GitLab) — which serialises applies so this cannot happen.

The root causes and trade-offs.

The root cause is simply not having state locking in place at all, and a related red flag is using local state for infrastructure that's actually shared across a team. The fix is a remote backend with locking, and the trade-off is a bit of upfront setup for a safety guarantee that's genuinely mandatory for any team working together.

The trap that less-experienced engineers fall into.

Using local state for shared infrastructure (no locking, no durability, no collaboration) — and not enabling state-bucket versioning, so there's nothing to roll back to when state corrupts.

🎯 Interviewer follow-up questions you should expect.

• "How do you prevent concurrent-apply corruption?" You use a remote backend with locking — an S3 backend with a DynamoDB lock table, or a managed backend.
• "State got corrupted — how do you recover?" You restore a previous state version, since S3 versioning is enabled, and reconcile with a plan before applying.
• "Why never local state for a team?" Because it has no locking, no durability, and no shared source of truth.

"How do you structure Terraform state?" Or a real problem: one giant state file for everything, so every plan is slow and every change risks the whole estate.

What is actually happening (the mental model).

State boundaries are blast-radius boundaries. One monolithic state means slow plans, a huge blast radius (a mistake can affect everything), and constant contention between people. So you split state by lifecycle and blast radius — network, data, app — per environment, rather than one giant state.

How to reason about it.

1. Split by lifecycle/component and blast radius — e.g. networking, data stores, and application layers in separate states, per environment. Rarely-changed foundational things (VPC) shouldn't share state with fast-moving app config.
2. Remote backend per state, encrypted and locked.
3. Cross-stack references — publish outputs and consume via terraform_remote_state data sources (or data sources on the resources), so states can reference each other without merging.
4. Terragrunt to keep multi-environment/multi-component config DRY when the duplication gets painful.

The root causes and trade-offs.

A single, monolithic state file gives you slow plans, a huge blast radius, and contention between people applying changes at the same time. Splitting into many smaller states requires more wiring between them, but each one stays isolated and fast. The trade-off is a bit more structure and more cross-references between states, in exchange for real safety and speed.

The trap that less-experienced engineers fall into.

One giant state file for the whole estate — slow, high-contention, and a single mistake can ripple across everything.

🎯 Interviewer follow-up questions you should expect.

• "How do you split state?" By lifecycle and blast radius — network, data, app — per environment, since state boundaries are blast-radius boundaries.
• "How do states reference each other?" Through remote-state data sources or published outputs.
• "What's the cost of one giant state?" Slow plans, a huge blast radius, and contention between people applying at the same time.

A monolithic state takes 15–20 minutes to plan, and you need to split it into smaller states — or refactor code (rename resources, move into modules) without Terraform destroying and recreating everything.

What is actually happening (the mental model).

Terraform tracks each resource by its address in state. If you rename a resource or move it into a module, its address changes, and Terraform — not knowing it's the same resource — plans to destroy the old and create the new. State surgery (moved blocks, state mv) tells Terraform "this is the same thing at a new address" so it just updates the pointer instead of recreating. This is the highest-risk operation in Terraform, so you back up state first and verify no-op plans.

How to work through it.

1. Back up state first — copy it. State surgery is the riskiest thing you do; a mistake can orphan or destroy resources.
2. Move resources with moved blocks (declarative, reviewable — preferred) or terraform state mv (imperative), or remove-and-re-import into the new state.
3. One component at a time, verifying a no-op plan on both sides before proceeding (a no-op plan proves the move was clean).
4. Use -target sparingly — routine use is a smell that state boundaries are wrong.

The root causes and trade-offs.

Renaming a resource or moving it between modules changes its address in state, and Terraform reads that as the old resource being destroyed and a brand-new one being created. State surgery — using a moved block or terraform state mv — avoids that entirely. The trade-off is spending a little care and time now against the alternative, which is an outage from recreating live resources unnecessarily.

The trap that less-experienced engineers fall into.

Renaming a resource or moving it into a module and applying without a moved block — Terraform destroys and recreates the live resource (an outage). And doing state surgery without backing up state first.

🎯 Interviewer follow-up questions you should expect.

• "You renamed a resource and the plan shows destroy+create — why and how to avoid?" The address changed, so you use a moved block or state mv so Terraform updates the pointer instead of recreating the resource.
• "How do you safely split a big state?" You back up the state, move one component at a time with state mv or a re-import, and verify a no-op plan on both sides.
• "When is -target a smell?" Routine use means your state boundaries are wrong — you should refactor instead of working around every apply.

A security question, or a review finding: "how do you handle secrets in Terraform?" The critical fact many miss: anything Terraform manages ends up in state in plaintext.

What is actually happening (the mental model).

Terraform state stores the full attributes of every managed resource — including generated passwords, private keys, and any secret it touches — in plaintext. So the state file itself is a secret, and protecting it is step one. Beyond that, don't hardcode secrets; source them from a secrets manager, and minimise what lands in state.

How to reason about it.

1. Encrypt the backend and restrict access tightly — state is plaintext secrets, so the backend must be encrypted (S3 SSE-KMS) with least-privilege access, treated as a secret store.
2. Don't hardcode — source secrets from Vault/SSM/Secrets Manager via data sources at apply time.
3. Mark outputs sensitive so they're not printed; keep secret .tfvars out of git.
4. Minimise what's in state — prefer letting a dedicated secrets system own the secret and having Terraform only reference it, rather than Terraform generating/holding it.

The root causes and trade-offs.

The state file being plaintext is simply inherent to how Terraform works, so the mitigation is encryption at rest, tight access control on who can read the state, and minimising how many real secrets ever end up stored in it in the first place. The trade-off is a bit of indirection, referencing a proper secret store instead of a raw value, in exchange for real security.

The trap that less-experienced engineers fall into.

Not realising state contains secrets in plaintext — leaving the state backend unencrypted or broadly readable, or committing a state file / secret .tfvars to git.

🎯 Interviewer follow-up questions you should expect.

• "Are secrets safe in Terraform?" No — state stores them in plaintext, so you encrypt the backend and restrict access to it.
• "How do you source secrets?" From Vault or Secrets Manager via data sources, marking outputs sensitive, and keeping secret tfvars out of git.
• "How do you minimise exposure?" You let a secrets manager own the secret, and have Terraform reference it rather than generating or holding it.

A manual change was made in the cloud console, and the next terraform plan shows destructive changes — Terraform wants to "fix" reality back to the code, potentially reverting something important or destroying a manually-added resource.

What is actually happening (the mental model).

Terraform's job is to make reality match the code. When someone changes a managed resource by hand, reality drifts from state/code, and the next plan wants to reconcile — which might revert a legitimate fix or, worse, be destructive. Drift is fundamentally a governance problem before it's a technical one: the real fix is removing the ability to hand-mutate managed resources.

How to work through it.

1. Detect with terraform plan (it shows the drift).
2. Decide: was the manual change intentional and correct? If yes, codify it — update the config (or import a manually-added resource) so Terraform is the source of truth again. If no, let Terraform reconcile it away.
3. Prevent drift systemically: restrict console write access via IAM so humans can't mutate managed resources; run scheduled drift-detection plans in CI so you catch drift in hours, not at the next unrelated apply; a "no manual changes" policy with break-glass exceptions.

The root causes and trade-offs.

The root cause is usually humans still having console write access to resources that Terraform is supposed to manage, combined with no drift detection in place to catch it when that access gets used. The fix is tighter IAM permissions plus scheduled drift detection, and the trade-off is losing a little ad-hoc flexibility in exchange for real consistency and safety.

The trap that less-experienced engineers fall into.

Discovering drift only when an unrelated apply suddenly wants to make a surprising destructive change — because there was no scheduled drift detection, and no lock-down of console writes.

🎯 Interviewer follow-up questions you should expect.

• "Someone changed a managed resource in the console — what do you do?" You decide whether it was intentional, and codify or import it, or unintentional, and reconcile it, then prevent it from happening again.
• "How do you catch drift early?" With a scheduled plan in CI as drift detection, not by waiting for the next unrelated apply.
• "How do you stop drift at the source?" By restricting console write access to managed resources through IAM.

Every terraform plan shows the same change, even immediately after a successful apply — the plan never becomes a clean no-op. Noisy and dangerous, because it hides real diffs.

What is actually happening (the mental model).

A perpetual diff means Terraform's desired state and the provider's actual state never match for some attribute, so every plan wants to "fix" it. The usual causes: the provider normalises a value differently than your config (reordered IAM policy JSON, canonicalised strings), an attribute is computed/mutated by another system (autoscaling changing desired capacity, another tool adding tags), or a genuine bug.

How to work through it.

1. Identify which attribute flaps — read the plan diff carefully.
2. Diagnose the cause: provider normalisation (e.g. IAM policy JSON key ordering — use jsonencode / a canonical form), an externally-mutated attribute (ASG desired capacity, tags added by a policy/automation), or a computed value.
3. Fix: either match the provider's canonical form in your config, or use ignore_changes (lifecycle block) on the attribute that a different system legitimately owns, so Terraform stops fighting it.

Root causes, and how to tell them apart.

Provider normalisation (config value differs from provider's canonical form — match it); external mutation (ASG capacity, auto-added tags — ignore_changes); a computed attribute. The specific flapping attribute tells you which.

The trap that less-experienced engineers fall into.

Ignoring a perpetually-noisy plan ("it always shows that change, just apply it") — which is dangerous because a real diff hides in the noise and gets applied unnoticed.

🎯 Interviewer follow-up questions you should expect.

• "Every plan shows the same change even after apply — why?" Because the desired and actual state never match — this can come from provider normalisation, an externally-mutated attribute, or a computed value.
• "How do you fix it?" You match the canonical form, or use ignore_changes on attributes another system owns.
• "Why is a noisy plan dangerous?" Because it hides real diffs — people stop reading it.

Someone ran terraform destroy (or an apply that planned mass destruction) believing they were in dev, but were pointed at prod — and real infrastructure started coming down before it was caught.

What is actually happening (the mental model).

The root issue is insufficient blast-radius isolation — a single human error could reach prod at all. The senior response isn't "be more careful" (not a control); it's structural guardrails: separate accounts/state per environment so a dev mistake physically cannot touch prod, prevent_destroy on critical resources, and applying the saved plan so what runs is exactly what was reviewed.

How to work through it (prevention-focused).

1. Isolate environments into separate cloud accounts (and separate state) — a mistake in dev can't reach prod.
2. prevent_destroy lifecycle on critical resources (databases, buckets) — Terraform refuses to destroy them.
3. Plan-then-apply-the-saved-plan (terraform plan -out=tfplan → terraform apply tfplan) so there's no gap between what was reviewed and what runs — a mass-destroy would be visible in review.
4. Require review/approval before apply; never apply to prod from a laptop.

The root causes and trade-offs.

The root cause is usually no real environment isolation, so a single command can reach production, combined with no prevent_destroy lifecycle rule in place and a habit of applying without ever reviewing the saved plan first. The fix is proper isolation plus explicit guardrails, and the trade-off is a bit more structure in exchange for a hard safety boundary around production.

The trap that less-experienced engineers fall into.

Relying on "be careful" / naming conventions instead of hard isolation — sharing state or credentials across prod and non-prod, so a wrong-directory or wrong-workspace mistake can destroy prod.

🎯 Interviewer follow-up questions you should expect.

• "How do you prevent a wrong-environment destroy?" You separate accounts and state per environment, so a dev mistake can't reach prod, and set prevent_destroy on critical resources.
• "Why apply the saved plan?" So that what runs is exactly what was reviewed — a mass-destroy would be caught in review.
• "Is 'be more careful' a fix?" No — it's not a control, you need structural guardrails.

You bumped the AWS provider (or a module) version, and the next plan shows unexpected changes — or worse, wants to replace live resources like an RDS instance.

What is actually happening (the mental model).

Provider and module versions change behaviour, defaults, and sometimes resource schemas between releases. An unpinned or careless upgrade can silently plan a destroy-recreate of critical resources. The senior discipline: pin versions, commit the lock file, upgrade deliberately (read the changelog, test low first), and scrutinise the plan for every -/+ replace.

How to work through it.

1. Pin provider and module versions (required_providers constraints), and commit .terraform.lock.hcl so upgrades are intentional, never accidental.
2. Upgrade deliberately — read the changelog for breaking changes, bump in a lower environment first, and read the plan carefully for any -/+ (replace) — a provider recreating an RDS instance is an outage.
3. If a refactor changes resource addresses, use moved blocks / state mv so Terraform updates the pointer instead of destroying/recreating.

The root causes and trade-offs.

The root cause is usually unpinned provider or module versions, which lets an upgrade happen accidentally, combined with a habit of not actually reading which resources the plan says will be replaced. The fix is pinning versions, upgrading deliberately, and always reading the plan, and the trade-off is a slower, more careful upgrade process in exchange for real safety.

The trap that less-experienced engineers fall into.

Not committing the lock file (so terraform init silently pulls a new provider version), and applying an upgrade without reading the plan for destructive replacements.

🎯 Interviewer follow-up questions you should expect.

• "How do you make provider upgrades safe?" You pin versions, commit the lock file, upgrade deliberately, test in a lower environment, and read the plan for any -/+ replacements.
• "A provider upgrade wants to replace your database — what do you do?" You stop and read why, then use a moved block or a lifecycle rule to avoid the recreation, or hold off on the upgrade entirely.
• "Why commit the lock file?" So upgrades are intentional — without it, init can pull a new version silently.

An apply errored partway through — some resources were created/modified, others weren't. Now state partially reflects reality, and you're unsure what actually got applied.

What is actually happening (the mental model).

Terraform applies resources according to the dependency graph, and if one fails (an API error, a timeout, a permissions issue), it stops — resources already applied are recorded in state, the rest aren't. Terraform is designed to be re-runnable: state tracks what succeeded, so a corrected re-apply continues from where it left off. The key is to understand the current state vs reality before re-running.

How to work through it.

1. Read the error — which resource failed and why (API limit, timeout, permissions, a dependency that isn't ready)?
2. Run terraform plan — it shows what's left to do based on current state, telling you what succeeded and what didn't.
3. Fix the cause (permissions, a race, a quota) and re-apply — Terraform continues from where it stopped.
4. If a resource was created in the cloud but not recorded in state (a partial failure mid-resource), you may need to import it or terraform state reconcile to avoid a duplicate-create on re-apply.

The root causes and trade-offs.

This can come from a transient API error, a timeout, a permissions problem, a dependency-ordering race, or a resource that was genuinely created but never recorded in state. The plan itself is what reveals the gap, and importing or reconciling the state is what handles the case where something was created but never actually tracked.

The trap that less-experienced engineers fall into.

Panicking and re-running blindly, or manually deleting half-created resources — instead of reading the plan to see what state thinks exists, fixing the cause, and letting Terraform continue.

🎯 Interviewer follow-up questions you should expect.

• "An apply failed halfway — how do you recover?" You read the error, run plan to see what's left, fix the cause, and re-apply, since Terraform continues from where it left off.
• "A resource was created but isn't in state — what now?" You import it, or reconcile it, so a re-apply doesn't try to create a duplicate.

A change forces a resource to be replaced (the plan shows -/+), or you deliberately need to recreate one — but the naive replace destroys the old before creating the new, causing downtime.

What is actually happening (the mental model).

Some attribute changes are immutable and force replacement — Terraform must destroy and recreate. By default it destroys then creates, which means a gap of downtime. The create_before_destroy lifecycle flips that order — create the replacement first, cut over, then destroy the old — enabling zero-downtime replacement (with care around unique constraints like names/ports). And you can force a replacement deliberately with -replace (formerly taint).

How to work through it.

1. Understand why it's being replaced — which attribute forces replacement (the plan says "forces replacement").
2. If downtime matters, add lifecycle { create_before_destroy = true } so the new resource is created before the old is destroyed. Handle unique constraints (a name/port collision during the overlap — often needs a name change or a moving target).
3. To force a replace deliberately: terraform apply -replace=<address> (replaces terraform taint).
4. Combine with the deployment strategy (blue/green at the infra level) for truly zero-downtime cutover.

The root causes and trade-offs.

Changing an immutable attribute forces Terraform to replace the resource, and its default destroy-then-create order causes real downtime while that happens. Adding create_before_destroy avoids that downtime, at the cost of briefly running two copies of the resource at once, which means you also need to handle any unique-constraint collisions that causes.

The trap that less-experienced engineers fall into.

Applying a replacement without realising it destroys-then-creates (an outage), and not knowing create_before_destroy exists to reverse the order.

🎯 Interviewer follow-up questions you should expect.

• "A change forces a resource replacement with downtime — how do you avoid it?" You use the create_before_destroy lifecycle rule, so the new resource is created before the old one is destroyed.
• "How do you force a replacement?" With terraform apply -replace=<addr>, which is the modern equivalent of taint.
• "What's the catch with create_before_destroy?" Unique constraints, like a name or a port, can collide during the overlap, and you have to handle that.

Teams are copy-pasting Terraform, and you're asked to standardise with reusable modules — or you've inherited a mega-module with 40 variables that nobody understands.

What is actually happening (the mental model).

Reusable, versioned modules with clear interfaces are the goal — but the failure mode is over-abstraction: a single mega-module with dozens of toggles to handle every conceivable case becomes impossible to reason about and worse than duplication. The senior balance is focused, opinionated modules with tight interfaces and sane defaults, versioned like a product.

How to reason about it.

1. Reusable modules with clear inputs/outputs, sane defaults, published to a registry; consumers pin a version (v1.2.0), not a moving target.
2. Avoid premature/over-abstraction — a module with 40 variables to cover every case is worse than two focused modules. Prefer opinionated modules over infinitely-configurable ones.
3. Version and changelog modules like a product — a breaking change to a shared module can break every consuming team.

The root causes and trade-offs.

Copy-pasting configuration gives you no reuse and lets each copy drift independently, while an over-parameterised mega-module becomes unmaintainable in its own way. The sweet spot is a focused module with good defaults, and the trade-off is sometimes accepting a bit of duplication rather than building one monstrous, do-everything abstraction.

The trap that less-experienced engineers fall into.

Building a mega-module with 40 toggles to handle every scenario (unmaintainable), or not versioning modules so a change breaks all consumers at once.

🎯 Interviewer follow-up questions you should expect.

• "How do you design reusable modules?" With tight interfaces, sane defaults, versioning in a registry, and consumers pinning the versions they use.
• "What's the over-abstraction trap?" A mega-module with dozens of toggles, which ends up worse than two focused modules.
• "Why version modules?" Because a breaking change to a shared module can break every team consuming it.

You remove one item from a list of resources created with count, and the plan shows Terraform destroying and recreating several resources — not just the one you removed. A favourite interview question because it exposes real understanding.

What is actually happening (the mental model).

count addresses resources by positional index ([0], [1], [2]). Remove the middle element of a list, and everything after it shifts index — so [2] becomes [1], and Terraform sees the resource "at index 1" as changed and destroys/recreates it, cascading down the list. for_each addresses resources by a stable map key — remove one key and only that resource is affected. So for anything that changes over time, prefer for_each.

How to reason about it.

1. for_each (keyed by a stable identifier) for collections that evolve — removing one item touches only that item.
2. count only for truly positional/identical things that don't get items removed from the middle (e.g. "N identical instances" where you only scale the number at the end).
3. If you have existing count-based resources and need to migrate, use moved blocks to re-key without recreation.

The root causes and trade-offs.

count indexes its resources positionally, so removing one from the middle of the list shifts every index after it and cascades into recreating them all. for_each uses stable keys instead, so removing one item never touches the others. The trade-off is that for_each needs a genuinely stable key, from a map or a set, which is a small design cost for a big safety win.

The trap that less-experienced engineers fall into.

Using count over a list that changes over time — then removing a middle element re-indexes and destroys/recreates multiple live resources, a nasty surprise (potential outage).

🎯 Interviewer follow-up questions you should expect.

• "count vs for_each — why does it matter?" count is positional, so removing a middle item re-indexes and recreates everything after it, while for_each uses stable keys, so only the removed item is affected.
• "When would you use count?" For truly identical, positional resources that you only ever scale at the end — otherwise you'd use for_each.

Production was built by hand in the console, and you must bring it under Terraform management without disrupting it.

What is actually happening (the mental model).

You need Terraform's state and code to accurately represent resources that already exist. terraform import (or import blocks in 1.5+) brings an existing resource into state; then you write config to match it, and iterate until plan shows zero changes — a no-op plan is your proof the code correctly represents reality. Do it incrementally, low-risk resources first — rushing risks Terraform "fixing" prod to match imperfect code (an outage).

How to work through it.

1. For each resource: write the matching config, then terraform import <address> <id> (or an import block).
2. Iterate on the config until plan is a no-op — zero changes proves the code accurately captures the real resource. A diff means your code doesn't match reality yet.
3. Incrementally — start with low-risk resources to build confidence and tooling before touching the database or load balancer.
4. Manage forward once imported.

The root causes and trade-offs.

The root cause is simply existing infrastructure that was clicked together in the console with no code behind it at all. Importing it and then iterating on the configuration until the plan shows no changes is what brings it properly under management. The trade-off is careful, incremental work now, against the real risk of Terraform reconciling production to a config that isn't quite right yet.

The trap that less-experienced engineers fall into.

Importing a resource and applying while the config still has a diff — so Terraform "fixes" the live resource to match the imperfect code, causing an outage. Or trying to import everything big-bang.

🎯 Interviewer follow-up questions you should expect.

• "How do you bring existing infra under Terraform?" You import it, write matching configuration, and iterate until the plan is a no-op, working incrementally and starting with the lowest-risk resources.
• "How do you know the import is correct?" A zero-change plan proves the code matches reality.
• "Why not import everything at once?" Because it's too risky — a config diff would make Terraform reconcile production to imperfect code.

Design Terraform for an organisation with many accounts, regions, and environments — and the interviewer probes workspaces vs directory-per-env and how you isolate prod.

What is actually happening (the mental model).

The organising principle is isolation: separate state and separate accounts per environment so a mistake is contained. The key opinion: for prod-critical separation, prefer directory-per-environment over Terraform workspaces, because workspaces share one config and it's easy to forget which one you're in (the near-destroy scenario). Provider aliases handle multi-region.

How to reason about it.

1. Separate state + separate accounts per environment — isolation is the security and blast-radius benefit.
2. Directory-per-environment (with per-env .tfvars) over workspaces for prod-critical separation — workspaces share config and hide which environment you're targeting; directories make it explicit. (Workspaces are fine for ephemeral/similar envs.)
3. Provider aliases for multi-region within a config.
4. Landing-zone patterns (Control Tower) and CI/CD-driven applies with per-environment approvals — nobody applies to prod from a laptop.

The root causes and trade-offs.

Workspaces keep your configuration DRY, but they make it easy to accidentally target the wrong environment. A directory-per-environment layout means more duplication, but which environment you're touching is always explicit and safe. For production, that explicitness wins, and a tool like Terragrunt can reduce the duplication cost of the directory-per-environment approach.

The trap that less-experienced engineers fall into.

Using workspaces to separate prod from non-prod with shared config and credentials — making it easy to run the wrong environment (the near-destroy scenario).

🎯 Interviewer follow-up questions you should expect.

• "Workspaces or directory-per-env?" Directory-per-environment for prod-critical separation, since it's explicit and isolated; workspaces for ephemeral or similar environments.
• "How do you handle multi-region?" With provider aliases.
• "How do you isolate environments?" With separate accounts and state, and CI/CD applying through per-environment approvals.

Design the Terraform delivery pipeline — how changes get reviewed and applied safely, without people running apply from laptops.

What is actually happening (the mental model).

Infra changes go through the same rigor as application code, and the key discipline is plan-on-PR (the plan is the diff being reviewed) and apply-the-saved-plan on merge (no gap between reviewed and applied). Tools like Atlantis / Terraform Cloud / Spacelift orchestrate this with locking and a scoped role.

How to reason about it (the pipeline).

1. On the PR: fmt / validate / tflint / security scan (tfsec/checkov) / cost estimate (Infracost), and post the plan as a PR comment so reviewers see exactly what will change.
2. On merge: apply the saved plan (plan -out then apply that file) so what runs is exactly what was reviewed — no re-plan drift.
3. State locking during apply; a least-privilege CI role.
4. Per-environment approvals; nobody applies to prod from a laptop — the pipeline is the only path.
5. Atlantis / Terraform Cloud / Spacelift to automate this.

The root causes and trade-offs.

Applying from a laptop is unreviewed, un-audited, and prone to drift, since nobody else sees what actually happened. Applying through a pipeline means the change is reviewed, audited, and run from the exact saved plan. The trade-off is the upfront work of setting up that pipeline, in exchange for real safety and auditability.

The trap that less-experienced engineers fall into.

Applying from laptops with personal credentials (no review, no audit trail), and re-planning at apply time instead of applying the saved plan (so what runs may differ from what was reviewed).

🎯 Interviewer follow-up questions you should expect.

• "How do you deliver Terraform safely?" You run plan on the pull request as a comment, apply the saved plan on merge, use state locking, and give CI a least-privilege role.
• "Why apply the saved plan?" So that what runs is exactly what was reviewed, with no drift between review and apply.
• "What tools automate this?" Atlantis, Terraform Cloud, or Spacelift.

You need to stop people provisioning insecure or expensive infrastructure — public S3 buckets, unencrypted volumes, oversized instances, untagged resources — before it's applied.

What is actually happening (the mental model).

Guardrails belong in the pipeline, shifted left — catch bad infra in the PR, not in a security audit or a surprise bill. Policy-as-code (OPA/Sentinel/Conftest) blocks non-compliant plans, and cost estimation (Infracost) surfaces the dollar impact on the PR so it's a conversation before merge.

How to reason about it.

1. Policy-as-code gates in CI (OPA/Sentinel/Conftest) — block public S3, unencrypted volumes, 0.0.0.0/0 security groups, oversized instances, missing required tags.
2. Cost estimation (Infracost) on PRs — "this change adds $3k/month" is a great pre-merge conversation.
3. Shift left — fail in the PR, not in prod or on the invoice.
4. Mandatory tagging for cost allocation.

The root causes and trade-offs.

Ungoverned infrastructure lets an insecure or expensive change reach production with nobody catching it. Policy gates catch exactly that kind of change during review, before it ever applies. The trade-off is the upfront work of authoring those policies, in exchange for governance that happens automatically from then on.

The trap that less-experienced engineers fall into.

Relying on manual review or a post-hoc security audit to catch insecure/expensive infra — instead of automated gates that fail the PR.

🎯 Interviewer follow-up questions you should expect.

• "How do you stop insecure infra being provisioned?" With policy-as-code gates, using OPA or Sentinel, in CI, blocking things like public S3 buckets, unencrypted volumes, and open security groups.
• "How do you control cost?" With Infracost on the pull request, so the dollar impact is visible before merge, plus mandatory tagging.
• "What's the principle?" Shift governance left — catch it in review, not in an audit or on the bill.

"Would you always use Terraform?" A judgment question testing whether you know Terraform's limits and reach for the right tool per layer.

What is actually happening (the mental model).

Terraform excels at declarative, multi-cloud provisioning, but it's not the right tool for everything — it's weak at imperative sequencing, app configuration, and fast-changing app deploys. Senior means matching the tool to the layer — provisioning, configuration, and app deployment are different problems — rather than cramming everything into Terraform.

How to reason about it.

• Terraform — declarative provisioning of infrastructure, multi-cloud. Its sweet spot.
• Not great for: imperative sequencing, app-level configuration (use Ansible), app deployment on Kubernetes (use Helm/GitOps), fast-changing app deploys.
• Alternatives per context: CloudFormation/CDK for deep AWS-native shops; Pulumi for real programming languages; Crossplane for Kubernetes-native provisioning.
• Right tool per layer — provisioning vs config vs deploy.

The root causes and trade-offs.

Forcing everything into Terraform, including work it was never designed for, produces brittle, awkward code, since you end up writing imperative logic inside a declarative tool. Matching each tool to the layer it's actually good at produces cleaner code overall, at the cost of needing to know more tools.

The trap that less-experienced engineers fall into.

Using Terraform for app configuration or deployment (imperative, fast-changing work it's bad at), producing brittle, hard-to-maintain code — instead of Ansible/Helm for those layers.

🎯 Interviewer follow-up questions you should expect.

• "Would you always use Terraform?" No — it's for declarative provisioning; application configuration goes to Ansible, and application deployment goes to Helm or GitOps.
• "Terraform vs CDK vs Pulumi?" CDK or CloudFormation for deep AWS-native work; Pulumi if the team wants real programming languages; Terraform for declarative multi-cloud.
• "What's Terraform bad at?" Imperative sequencing, application configuration, and fast-changing application deploys.