Terraform state and Failures

P01 — Why keep team state in a remote backend?

So the team uses the same state rather than conflicting laptop copies. Configure access protection, recovery and supported locking.

P02 — What does a state lock prevent?

Two Terraform writers changing the same state at once. It does not lock every AWS resource against console changes.

P03 — An apply says the state is locked. What do you do first?

Identify the lock owner and active run. Wait or investigate that run; only clear your stale lock after proving its operation stopped.

P04 — How is S3 backend locking configured now?

On supported Terraform versions, use_lockfile = true enables S3 lock-file locking. Older DynamoDB-based locking is deprecated; check the project version before changing it.

P05 — What is infrastructure drift?

Real infrastructure changed outside the declared workflow, such as someone editing a security group in the console.

P06 — A console fix stopped an outage. What should happen in Terraform afterward?

Inspect the real change and its intent. Update configuration if the fix should remain, then review a fresh plan so a later apply does not undo it.

P07 — What does refresh-only mean?

Review or record observed changes in state and outputs without changing remote resources. It does not edit configuration to match the console.

P08 — An apply fails halfway through. Did Terraform undo everything?

No. Successful changes may remain and be recorded in state. Inspect what changed, fix the cause, and review a fresh plan before continuing.

P09 — A plan shows -/+ for a production database table. What does that mean?

Replacement: the existing resource is to be destroyed and another created. Stop to review the reason, data migration, dependencies and recovery path.

P10 — Can reverting a Git commit guarantee a safe infrastructure rollback?

No. The resulting plan might replace resources, and deleted data does not return with the code. Review the reverse change and its recovery implications.

P11 — Why protect state and saved plan files?

They can contain secrets and infrastructure details. Restrict access and protect storage; do not treat them as ordinary Git artifacts.

P12 — Does sensitive = true keep a value out of state?

No. It hides normal display output, but the value can still be stored. Omission from state requires a supported ephemeral or write-only approach.

P13 — Do Terraform workspaces alone separate dev and production securely?

No. They separate state instances, not credentials or account permissions. Design separate access, state and resource boundaries; accounts can provide stronger isolation.

P14 — A table already exists in AWS. How can Terraform take over managing it?

Import it into the intended resource address with matching configuration, then inspect the plan. Import is not proof that configuration matches or that applying is harmless.

P15 — Renaming a Terraform resource proposes destroy/create. What should you investigate?

Whether only its Terraform address changed. A reviewed moved block can preserve its binding to the same object; confirm the resulting plan avoids unintended replacement.

P16 — What makes a Terraform deployment safer in CI?

Use reviewed configuration, controlled credentials and versions, protected state and serialized applies. Review the saved plan that will be applied, then verify application behavior afterward.