TF-004 Use Terraform outside the core workflow Practice Question
Which TWO Terraform backends support remote state locking?
⚠ Common exam trap
The Terraform certification exam often tests the misconception that all remote backends support locking, but only a subset (S3, Consul, and a few others like AzureRM and GCS) implement native locking mechanisms.
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
✓
s3
The S3 backend (A) supports remote state locking by using a DynamoDB table to acquire and release a lock, which prevents concurrent Terraform runs from corrupting state; this is configured via the dynamodb_table argument. The Consul backend (C) also supports remote state locking natively, since Consul's key-value store provides a locking mechanism (sessions and acquire/release operations) that Terraform uses to lock the state path. The local backend (B) stores state on the local filesystem and does not provide remote locking, only local file-based locking. The inmem backend (D) keeps state in memory for testing purposes and offers no locking. The http backend (E) is a read-only backend for retrieving state over HTTP and does not support state locking.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
s3
Why this is correct
The S3 backend leverages Amazon DynamoDB to provide robust remote state locking. When a Terraform operation requires a lock, it attempts to acquire it by writing a lock entry to a designated DynamoDB table. DynamoDB's strong consistency guarantees ensure that only one operation can successfully acquire the lock at any given time, preventing concurrent modifications to the remote state file stored in S3 and safeguarding against state corruption.
- ✗
local
Why it's wrong here
The local backend stores Terraform state directly on the filesystem of the machine executing the `terraform` commands. While it employs basic file-based locking mechanisms to prevent concurrent operations by the *same* user on that *specific* machine, this does not extend to remote state locking. Consequently, it offers no protection against multiple users or automated pipelines concurrently attempting to modify the infrastructure from different hosts, making it unsuitable for collaborative environments.
- ✓
consul
Why this is correct
The Consul backend provides remote state locking capabilities by utilizing Consul's distributed key-value store and session management features. When a Terraform operation needs to acquire a lock, it creates a session and attempts to acquire a lock on a specific key within Consul's K/V store, linking the lock to the active session. If the session expires or the client disconnects, the lock is automatically released, ensuring robust and fault-tolerant distributed locking for collaborative state management.
- ✗
inmem
Why it's wrong here
The inmem backend, by its very nature, stores the Terraform state exclusively in the volatile memory of the process running Terraform. This ephemeral storage means the state is lost as soon as the Terraform process terminates, and it cannot be shared or accessed by other processes or users. Therefore, an in-memory backend fundamentally lacks any mechanism for persistent, shared state, making remote state locking an impossible and irrelevant concept for its design.
- ✗
http
Why it's wrong here
The HTTP backend is designed to interact with a generic HTTP/S endpoint for storing and retrieving Terraform state files. It acts primarily as a transport layer, sending and receiving state data via standard HTTP methods like PUT and GET. This backend itself does not implement any native locking mechanism; instead, it relies entirely on the remote HTTP service to handle any concurrency control or locking logic, which is not guaranteed or standardized by the backend itself.
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 — 434 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 →
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.