TF-004 Remote State Storage Practice Question
Which THREE of the following are valid methods to manage Terraform state in a team environment? (Choose three.)
⚠ Common exam trap
HashiCorp often tests the misconception that version control systems like Git can safely manage Terraform state, but they lack the locking and atomicity required for concurrent team workflows.
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
✓
Using a remote backend like S3 with DynamoDB locking
Options B, C, and E are all valid methods for managing Terraform state in a team environment. Option B uses a remote backend like S3 with DynamoDB locking to centralize state and prevent concurrent modifications. Option C leverages Terraform workspaces with a remote backend to isolate state for different environments while maintaining a single backend configuration. Option E uses Terraform Cloud, which provides a managed state backend with built-in locking and versioning, simplifying team collaboration. Option A is incorrect because version control systems lack state locking and can lead to corruption. Option D is incorrect because storing state locally on a network drive introduces consistency and locking issues, making it unsuitable for concurrent team access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Storing state in a version control system
Why it's wrong here
Storing Terraform state in a version control system like Git is fundamentally flawed because state files often contain sensitive information and are dynamic. Version control systems are designed for code, not for managing mutable data with concurrent write access, leading to a high risk of state corruption from simultaneous modifications and exposing sensitive infrastructure details to anyone with repository access.
- ✓
Using a remote backend like S3 with DynamoDB locking
Why this is correct
Using a remote backend like Amazon S3 for state storage, combined with DynamoDB for state locking, is a highly recommended and standard practice for collaborative Terraform environments. S3 provides durable, highly available, and versioned storage for the state file, while DynamoDB ensures mutual exclusion, preventing multiple users or processes from concurrently modifying the state and thereby avoiding corruption during `terraform apply` operations.
- ✓
Using Terraform workspaces with a remote backend
Why this is correct
Terraform workspaces, when utilized with a remote backend, provide an effective method for isolating distinct states for a single configuration, commonly used to manage separate environments such as development, staging, and production. Each workspace maintains its own independent state file within the remote backend, ensuring that changes intended for one environment do not inadvertently affect another, while still leveraging the benefits of remote state like locking and durability.
- ✗
Storing state locally and sharing via network drive
Why it's wrong here
Storing Terraform state locally and attempting to share it via a network drive is highly problematic and not recommended for team collaboration or production environments. This method lacks any inherent locking mechanism, making it extremely vulnerable to race conditions and state corruption if multiple users try to execute Terraform commands simultaneously. Furthermore, network drive reliability and performance issues can lead to data loss or inconsistent state, hindering operational stability.
- ✓
Using Terraform Cloud to manage state
Why this is correct
Using Terraform Cloud to manage state offers a fully managed, secure, and collaborative solution that abstracts away the complexities of state management. Terraform Cloud automatically handles state storage, locking, versioning, and secure access control, integrating seamlessly with version control systems for remote operations. This service provides a robust platform for teams, enhancing security, auditability, and operational efficiency by centralizing state management.
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
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.