Terraform State Management Best Practices
Which THREE of the following are best practices for managing Terraform state?
Quick Answer
The answer is to use state locking to prevent concurrent modifications, store state remotely in a backend like S3 or Terraform Cloud, and enable encryption for sensitive data. These three practices form the foundation of Terraform state management best practices because remote backends provide durability, collaboration, and built-in locking mechanisms that prevent corruption when multiple team members run Terraform simultaneously. On the HashiCorp Terraform Associate TF-003 exam, this topic appears frequently in scenario-based questions where a candidate must identify which actions protect state integrity versus those that merely improve convenience. A common trap is confusing local state with remote state—the exam expects you to know that local state lacks locking and is a single point of failure. Remember the mnemonic "Lock, Store, Encrypt" to recall the three pillars: state locking prevents conflicts, remote storage enables teamwork, and encryption secures secrets.
⚠ Common exam trap
HashiCorp often tests the misconception that local state is simpler and thus better for small teams, but the exam expects you to recognize that remote backends with locking and versioning are mandatory best practices for any collaborative or production Terraform workflow.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use remote backends to store state files
Option B is correct because remote backends (e.g., S3, GCS, Azure Blob, or Terraform Cloud) store state centrally so teams share a single source of truth, keep sensitive state off local disks, and enable collaboration and locking. Option C is correct because enabling versioning on the state storage backend (such as S3 bucket versioning) preserves prior state revisions, allowing recovery from corruption or accidental deletion and providing an audit trail. Option E is correct because state locking (e.g., DynamoDB for S3 backends or native locking in Terraform Cloud) prevents concurrent runs from simultaneously writing state, which would otherwise corrupt it or cause lost updates. Option A is not a best practice: directly editing state files bypasses Terraform's integrity checks and can corrupt the state; drift should be reconciled with 'terraform plan/apply' or 'terraform import'/'state rm' commands. Option D is not a best practice: local state storage risks loss, blocks team collaboration, and prevents locking, so network latency is an acceptable trade-off for a remote backend.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Edit state files directly to fix drift
Why it's wrong here
Hand-editing state corrupts its serialised structure and checksums, and Terraform will not detect drift from it. Drift is corrected by refreshing and applying configuration, or via terraform state commands. Direct editing is tempting as a quick fix, but it bypasses the dependency graph and can desynchronise resources.
- ✓
Use remote backends to store state files
Why this is correct
Remote backends store state outside the local working directory, enabling shared access, encryption at rest and centralised control. This prevents state divergence between team members and satisfies the best-practise requirement for collaborative, durable state management.
- ✓
Enable versioning on the state storage backend
Why this is correct
Versioning on the state storage backend preserves every prior state file revision, so you can roll back to a known-good state after corruption, accidental deletion or a failed apply. This satisfies the stem's durability requirement, letting you recover state without rebuilding infrastructure from scratch.
- ✗
Store state files locally to avoid network latency
Why it's wrong here
Local state files risk loss, concurrent modification and no locking, and cannot be shared across a team or CI pipeline. Remote backends provide locking and versioning. Local storage is tempting for single-developer sandboxes where latency and simplicity matter, but it breaks collaborative or automated workflows.
- ✓
Use state locking to prevent concurrent modifications
Why this is correct
State locking prevents two Terraform runs from writing to the same state file simultaneously, avoiding corruption and lost updates. This directly satisfies the stem's best-practise requirement for managing state, since concurrent modifications are a primary cause of state drift and inconsistent infrastructure records.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 434-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on TF-004
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which THREE of the following are best practices for Terraform state management in a team environment?
medium- ✓ A.Use separate state files for different environments (dev, prod)
- B.Store state files in a version control repository
- ✓ C.Enable state locking to prevent concurrent modifications
- ✓ D.Store state files in a remote backend shared by the team
- E.Manually edit the state file to correct drift
Why A: Option A is correct because using separate state files per environment (dev, prod) isolates blast radius and prevents a change in one environment from corrupting or locking another, which is a core Terraform team best practice. Option C is correct because enabling state locking (e.g., via S3 + DynamoDB, Terraform Cloud, or Consul) prevents concurrent runs from simultaneously writing to the same state, avoiding corruption and race conditions. Option D is correct because a remote backend shared by the team (such as S3, GCS, Azure Blob, or Terraform Cloud) centralizes state, enables locking, versioning, and access control, and avoids each engineer holding a divergent local copy. Option B is not recommended because state files often contain secrets in plaintext and committing them to version control risks credential exposure and merge conflicts; state should live in a secured remote backend instead. Option E is not recommended because manually editing state is error-prone and unsupported; drift should be corrected with terraform import, terraform state mv/rm, or by reapplying configuration.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.