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.
⚠ Common exam trap
TF-004 often tests whether candidates assume S3 encrypts state by default or that locking blocks reads — the trap is confusing default behaviours with required explicit configurations, and misunderstanding what locking actually prevents.
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
Option A is correct because Terraform's S3 backend with DynamoDB locking requires the DynamoDB table (with a partition key of LockID) to already exist before terraform init, since init validates and configures the backend and will fail if the table is missing. Option B is correct because enabling versioning on the S3 bucket is a recommended practice that supports state recovery and consistency, allowing you to roll back to a previous state version if corruption or accidental deletion occurs. Option C is incorrect because the S3 backend configuration requires a key parameter specifying the path to the state file within the bucket. Option D is incorrect because S3 server-side encryption is not enabled by default for Terraform state; you must explicitly configure encrypt = true or apply bucket-level encryption. Option E is incorrect because DynamoDB state locking prevents concurrent write operations that could corrupt state, not read operations.
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
Terraform's S3 backend verifies and acquires the lock via DynamoDB during init and subsequent operations, so the table must already exist with the correct key schema. Terraform does not create it automatically, making prior table creation a genuine prerequisite for the backend to initialise.
- ✓
The S3 bucket should be versioned to provide consistency checks and recovery options
Why this is correct
Versioning preserves every revision of the state object, so a corrupted or truncated write can be rolled back to a prior version. This satisfies the recovery and consistency requirement of the S3 backend, since Terraform's own state file integrity depends on retrieving an intact object rather than a partially overwritten one.
- ✗
State can be stored without specifying a key in the backend configuration
Why it's wrong here
The S3 backend requires a key argument identifying the state object's path within the bucket; omitting it fails configuration validation. It is tempting because bucket and region are also mandatory, so people assume the object path is derived automatically, which would hold only if a default key existed.
- ✗
State is encrypted at rest by default using SSE
Why it's wrong here
SSE encryption of state objects is not applied by default; you must configure server-side encryption explicitly in the S3 backend or bucket policy. It is tempting because S3 does support SSE, and enabling it would be the right step when compliance demands encryption at rest.
- ✗
State locking prevents any read operations on the state file
Why it's wrong here
DynamoDB locking serialises write operations only; read operations such as plan still read state freely. It is tempting because locking sounds exclusive, and it would be correct to say locking blocks concurrent writes that could corrupt state during simultaneous 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
One of 434 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: Terraform's S3 backend with DynamoDB locking requires the lock table to exist for any operation that acquires a state lock (plan with refresh, apply, destroy). If the table is deleted, Terraform returns an error such as 'Error acquiring the state lock' or a ResourceNotFoundException, and the operation aborts rather than proceeding without locking.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official HashiCorp exam blueprint
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.