TF-004 Use the core Terraform workflow Practice Question
A team is using Terraform for infrastructure as code. They want to ensure that the state file is stored securely and can be accessed by multiple team members. Which backend type should they use?
⚠ Common exam trap
HashiCorp often tests the misconception that version-controlling the state file or using a simple network share is sufficient for team collaboration, when in fact proper state locking and remote storage are required to prevent corruption and ensure consistency.
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
✓
Remote backend such as Amazon S3 with DynamoDB state locking
A remote backend like Amazon S3 with DynamoDB state locking provides secure, centralized storage for the Terraform state file and enables state locking to prevent concurrent modifications. This setup ensures that multiple team members can safely access and update the state without conflicts, while S3 offers encryption and access control. Local backends or network shares lack these locking and security features, making them unsuitable for team collaboration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The -state flag pointing to a network share
Why it's wrong here
The -state flag is designed to override the default local state file path for a single operation, not to implement a shared backend solution for a team. Pointing it to a network share would lack crucial features like state locking, versioning, and atomic operations, making concurrent modifications highly prone to data corruption and race conditions among team members. This approach is fundamentally insecure and unreliable for collaborative infrastructure management.
- ✗
Using the -lock=false flag
Why it's wrong here
Using the -lock=false flag explicitly disables Terraform's state locking mechanism, which is a critical safety feature for collaborative environments. Without state locking, multiple team members could simultaneously attempt to apply changes, leading to race conditions, state file corruption, and ultimately, an inconsistent or broken infrastructure. This flag should only be used with extreme caution in single-user, non-production scenarios, never as a solution for team state management.
- ✗
Local backend with .terraform directory version-controlled
Why it's wrong here
A local backend stores the Terraform state file on the individual user's machine, making it unsuitable for team collaboration as it cannot be shared or accessed by others. Furthermore, version-controlling the .terraform directory, which contains the state file, in Git is highly problematic. State files often contain sensitive information, are binary, and change frequently, leading to merge conflicts, security vulnerabilities, and an unmanageable Git history, while still lacking proper state locking.
- ✓
Remote backend such as Amazon S3 with DynamoDB state locking
Why this is correct
A remote backend, such as Amazon S3, provides a centralized, highly available, and durable location for storing the Terraform state file, making it securely accessible to all team members. Coupling S3 with DynamoDB for state locking is crucial, as it ensures that only one user can acquire a lock and modify the state at any given time. This mechanism effectively prevents race conditions, state file corruption, and ensures infrastructure consistency across a collaborative team environment.
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
One of 428 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 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.