S3 Backend with DynamoDB State Locking: Configuration and Best Practices
Which TWO statements are correct about Terraform state when using the S3 backend with DynamoDB for state locking?
Quick Answer
The correct answer is that state is encrypted at rest by default using SSE, and the DynamoDB table must be created manually before use. This is because the S3 backend automatically applies server-side encryption (SSE-S3) to state files stored in the bucket, ensuring data protection without additional configuration, while DynamoDB state locking requires a pre-existing table because Terraform does not create it automatically—you must define and provision it separately. On the HashiCorp Terraform Associate TF-003 exam, this question tests your understanding of backend prerequisites and default security behaviors, often appearing as a trap where candidates assume DynamoDB is auto-created or that encryption requires manual setup. A common memory tip is “S3 locks automatically, DynamoDB needs a hand”—remember that S3 handles encryption out of the box, but you must build the DynamoDB table yourself before Terraform can use it for state locking.
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
✓
The DynamoDB table must exist before running terraform init
The DynamoDB table must exist before running `terraform init`, because the table is required for state locking and Terraform does not create it automatically. Option B is correct: enabling S3 bucket versioning provides consistency checks and allows recovery from accidental state deletion or corruption. Option C is incorrect: the `key` argument in the backend configuration is mandatory to specify the path for the state file in the S3 bucket. Option D is incorrect: by default, the S3 backend does not encrypt state at rest; encryption must be explicitly enabled using the `encrypt` argument or an environment variable. Option E is incorrect: state locking prevents concurrent writes but does not block read operations; reading the state file is still allowed while it is locked.
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 DynamoDB table must exist before running terraform init
Why this is correct
Correct. The DynamoDB table must exist before 'terraform init' because the backend will attempt to use it for locking during subsequent operations, and Terraform does not create the table automatically.
- ✓
The S3 bucket should be versioned to provide consistency checks and recovery options
Why this is correct
Correct. Enabling S3 bucket versioning provides consistency checks and recovery options, as it allows you to track and restore previous versions of the state file.
- ✗
State can be stored without specifying a key in the backend configuration
Why it's wrong here
Incorrect. The 'key' argument is mandatory in the S3 backend configuration to specify the path to the state file within the bucket.
- ✗
State is encrypted at rest by default using SSE
Why it's wrong here
Incorrect. By default, the S3 backend does not encrypt state at rest. Encryption (SSE-S3 or SSE-KMS) must be explicitly configured via the 'encrypt' argument or environment variable.
- ✗
State locking prevents any read operations on the state file
Why it's wrong here
Incorrect. State locking prevents concurrent writes but does not block reads; other processes can still read the state file while it is locked.
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 →
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. A team uses an S3 backend with DynamoDB locking. They accidentally delete the DynamoDB table used for state locking. What is the immediate consequence?
medium- ✓ A.Terraform commands that require state locking will fail with a locking error.
- B.State operations will continue without locking, risking corruption.
- C.Terraform will automatically create a new DynamoDB table.
- D.The state file will be migrated to local storage.
Why A: When the DynamoDB table is deleted, Terraform cannot acquire or release locks, so any command needing locking (apply, plan, destroy) will fail. Option A is correct. Option B is incorrect because Terraform will not proceed without lock; it returns an error. Options C and D are not automatic behaviors.
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.