TF-004 Implement and maintain state Practice Question
Which THREE of the following are best practices for Terraform state management in a team environment?
⚠ Common exam trap
TF-004 often tests the misconception that storing state in version control is acceptable, confusing it with infrastructure code versioning, while ignoring the security and locking limitations.
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 separate state files for different environments (dev, prod)
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use separate state files for different environments (dev, prod)
Why this is correct
Utilizing distinct state files for each environment, such as development and production, is a critical best practice. This isolation significantly reduces the "blast radius" of potential errors or accidental changes, preventing a misconfiguration in one environment from impacting another. It ensures that infrastructure changes are applied only to their intended target, enhancing stability and operational safety.
- ✗
Store state files in a version control repository
Why it's wrong here
Storing Terraform state files directly within a version control repository (VCS) is an anti-pattern. State files often contain sensitive information, such as secrets or resource IDs, which should not be exposed in plaintext history. Furthermore, their binary or large JSON nature can lead to frequent, difficult-to-resolve merge conflicts and bloat the repository size, hindering collaboration and performance.
- ✓
Enable state locking to prevent concurrent modifications
Why this is correct
Enabling state locking is essential for preventing data corruption when multiple users or automated processes attempt to modify the infrastructure simultaneously. This mechanism ensures that only one operation can acquire a lock on the state file at any given time, preventing race conditions. Without state locking, concurrent `terraform apply` or `terraform destroy` commands could lead to an inconsistent or corrupted state, misrepresenting the actual infrastructure.
- ✓
Store state files in a remote backend shared by the team
Why this is correct
Storing Terraform state files in a remote backend, such as Amazon S3, Azure Blob Storage, or HashiCorp Consul, is fundamental for team collaboration and operational consistency. A remote backend provides a single, authoritative source of truth for the infrastructure's current state, allowing all team members to operate on the same understanding. This centralized approach facilitates shared access, ensures state persistence, and often integrates with state locking mechanisms.
- ✗
Manually edit the state file to correct drift
Why it's wrong here
Manually editing the Terraform state file is highly discouraged due to its extreme error-proneness and potential for severe inconsistencies. The state file is a precise representation of managed infrastructure, and even minor syntax errors or incorrect resource references can lead to state corruption, making future `terraform plan` and `apply` operations unreliable or destructive. Instead, use `terraform refresh` to update the state from real-world infrastructure or `terraform import` for resources not yet managed by Terraform.
Quick reference
AAA Protocol Comparison
| Protocol | Port(s) | Encryption | Transport | Primary Use |
|---|---|---|---|---|
| RADIUS | 1812 / 1813 | Password only | UDP | Network access control |
| TACACS+ | 49 | Full packet | TCP | Device administration |
| Diameter | 3868 | Full session | TCP / SCTP | Carrier / mobile networks |
| 802.1X | — | EAP-based | Layer 2 | Port-based access control |
TACACS+ encrypts the entire packet; RADIUS only encrypts the password field — a key exam distinction.
Go deeper
Related to this question
About these practice questions
One of 434 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official HashiCorp exam blueprint
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.