TF-004 Use Terraform outside the core workflow Practice Question
A small startup uses Terraform to manage infrastructure on AWS. They store the state file directly in a Git repository (gitignored but accidentally committed) and have no remote backend. The team has two engineers: Alice and Bob. They both run Terraform from their local machines. Recently, they experienced state conflicts where Alice's apply would succeed but subsequently Bob's apply would fail due to state drift. They want a simple solution without adding too much complexity. What should they do?
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
✓
Configure an S3 backend with DynamoDB locking and have both engineers use the remote state.
Configuring an S3 backend with DynamoDB locking provides a remote state file that both engineers can access, along with state locking to prevent concurrent modifications. This directly solves the state conflicts without adding excessive complexity. Option A (adding .gitignore) does not address the conflict issue since the state is still local and not shared. Option C (coordination via Slack) is unreliable and does not prevent race conditions. Option D (Terraform Cloud) is a valid solution but adds more complexity than the simple S3+DynamoDB setup, which is the recommended approach for small teams.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add the state file to .gitignore and stop versioning it.
Why it's wrong here
Adding the `terraform.tfstate` file to `.gitignore` only prevents *future* accidental commits but does not remove it from Git history, nor does it address the fundamental problem of a shared state. If the state is not moved to a remote backend, each engineer will operate with their own local, uncoordinated state file, leading to divergent views of the infrastructure and significant configuration drift as changes are applied independently. This approach would exacerbate consistency issues rather than resolve them.
- ✓
Configure an S3 backend with DynamoDB locking and have both engineers use the remote state.
Why this is correct
Configuring an S3 backend centralizes the Terraform state file, establishing a single, authoritative source of truth accessible to all team members, which is crucial for collaborative infrastructure management. Integrating DynamoDB for state locking ensures that only one `terraform apply` operation can modify the state at any given time, effectively preventing concurrent changes from causing state corruption or overwriting each other's work. This combination is the industry standard for maintaining state consistency and preventing race conditions in shared environments.
- ✗
Continue with the current setup but ask Alice and Bob to coordinate via Slack before running apply.
Why it's wrong here
Relying solely on manual coordination via Slack is an unreliable and error-prone strategy that lacks any technical enforcement mechanism to prevent concurrent operations. Human error, miscommunication, or simply forgetting to coordinate can easily lead to multiple engineers running `terraform apply` simultaneously, resulting in state file corruption, resource conflicts, or an inconsistent infrastructure. This approach offers no robust protection against race conditions and does not scale effectively for team collaboration.
- ✗
Switch to Terraform Cloud with remote execution for automated locking.
Why it's wrong here
While Terraform Cloud with remote execution provides state locking and prevents concurrent apply conflicts, the scenario’s core problem is that the state file was accidentally committed to Git and no remote backend exists; switching to Terraform Cloud does not retroactively remove the committed state from Git history, nor does it address the existing drift caused by that committed state. This option is tempting because Terraform Cloud’s remote execution and locking are precisely designed to solve team-based state conflicts in production, and it would be the correct choice if the team had already migrated the state to a remote backend and needed to enforce serial applies.
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 →
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 valid methods to manage Terraform state in a team environment? (Choose three.)
easy- A.Storing state in a version control system
- ✓ B.Using a remote backend like S3 with DynamoDB locking
- ✓ C.Using Terraform workspaces with a remote backend
- D.Storing state locally and sharing via network drive
- ✓ E.Using Terraform Cloud to manage state
Why B: 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.
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.