TF-004 Implement and maintain state Practice Question
A company uses Terraform to manage infrastructure across multiple AWS accounts. They want to use a single S3 bucket to store state files for all accounts, but ensure that state files are isolated per account. What is the best approach?
⚠ Common exam trap
Test-takers frequently confuse Terraform workspaces with true state isolation across accounts, not realizing that workspaces only provide logical separation within a single backend path and do not prevent cross-account state conflicts when using a shared S3 bucket.
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 with unique S3 key prefixes per account
Using separate state files with unique S3 key prefixes per account ensures that each AWS account's Terraform state is stored in the same S3 bucket but logically isolated. This approach leverages S3's hierarchical key structure to prevent cross-account state contamination, while still allowing centralized management. Terraform's backend configuration supports dynamic key prefixes (e.g., `key = "account-${var.account_id}/terraform.tfstate"`), enabling per-account isolation without requiring separate buckets or workspaces.
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 Terraform workspaces with a single state file
Why it's wrong here
Terraform workspaces create separate state files within the same backend configuration, typically identified by a suffix (e.g., `terraform.tfstate.d/dev/terraform.tfstate`). While useful for isolating different environments (like dev, staging, prod) for a single infrastructure configuration, they are not designed to manage entirely distinct infrastructure deployments across separate AWS accounts. Each account requires its own independent backend configuration and state, which workspaces do not provide.
- ✓
Use separate state files with unique S3 key prefixes per account
Why this is correct
This approach correctly isolates Terraform state for each distinct AWS account. By configuring the S3 backend with unique `key` prefixes (e.g., `account-a/terraform.tfstate`, `account-b/terraform.tfstate`), each account's infrastructure state is stored in its own dedicated path within the S3 bucket. This prevents state file collisions, ensures independent management, and maintains clear separation of concerns across different environments or accounts.
- ✗
Store all state in the same S3 key
Why it's wrong here
Storing all Terraform state files under the exact same S3 key for multiple distinct AWS accounts would lead to immediate and catastrophic data loss. Each `terraform apply` operation from a different account would overwrite the previous state, causing Terraform to lose track of resources managed by other accounts. This would result in orphaned infrastructure, incorrect plan outputs, and potential resource destruction.
- ✗
Use a DynamoDB table with different lock IDs per account
Why it's wrong here
DynamoDB is primarily used by Terraform for state locking, which prevents concurrent operations from corrupting a single state file. While different lock IDs can be used, this mechanism does not provide any isolation for the *actual state data*. If multiple accounts are configured to store their state in the same S3 key, DynamoDB locking will only ensure that only one operation can write to that shared state at a time, but it will still result in continuous overwriting and data loss for all accounts.
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 428-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 →
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.