TF-004 Implement and maintain state Practice Question
Which TWO statements about Terraform state locking are correct?
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
✓
State locking prevents concurrent modifications to the same state file.
State locking prevents concurrent modifications to the same state file, ensuring consistency. Option E is correct because state locking relies on backend support; for example, S3 requires a DynamoDB table to enable locking. Option B is false because local state backends do not support locking; it is not enabled by default. Option C is false because Terraform Cloud fully supports state locking automatically. Option D is false because state locking is necessary for any operation that modifies state, even with a single user, to prevent corruption.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
State locking prevents concurrent modifications to the same state file.
Why this is correct
State locking is a critical mechanism that serializes access to the Terraform state file, ensuring that only one operation can modify it at any given time. This prevents race conditions and data corruption that could occur if multiple `terraform apply` or `terraform plan` operations attempted to write to the state simultaneously. By enforcing exclusive access, it maintains the integrity and consistency of the infrastructure's recorded state, which is essential for reliable infrastructure management.
- ✗
State locking is enabled by default when using a local state backend.
Why it's wrong here
The local state backend, which stores the `terraform.tfstate` file directly on the user's machine, inherently lacks any built-in mechanism for state locking. Since there is no shared, centralized coordination service for local files, concurrent operations from different processes or users cannot be prevented from modifying the state file simultaneously. Therefore, state locking is not enabled by default and is generally not available for local state, making it unsuitable for collaborative or production environments.
- ✗
State locking is not supported in Terraform Cloud.
Why it's wrong here
This statement is incorrect because Terraform Cloud provides robust, native support for state management, including automatic state locking. As a managed service, Terraform Cloud securely stores and manages the state file for all workspaces, automatically acquiring and releasing locks before and after operations. This integrated locking mechanism ensures state consistency and prevents concurrent modifications across all runs executed within the platform, making it a highly reliable solution.
- ✗
State locking is only necessary when multiple team members are running terraform apply simultaneously.
Why it's wrong here
State locking is not exclusively necessary for multi-team member scenarios; it is also crucial for single-user operations to prevent state corruption from interrupted runs. If a `terraform apply` or `terraform plan` command is terminated unexpectedly (e.g., due to a network issue, power outage, or user intervention), the state file could be left in an inconsistent or partially updated condition. A lock prevents subsequent operations from attempting to modify this potentially corrupted state, safeguarding its integrity.
- ✓
State locking requires a backend that supports locking, such as S3 with DynamoDB table.
Why this is correct
State locking is not an inherent feature of Terraform itself but rather a capability provided by specific remote backends configured to store the state file. These backends leverage external services to manage the locking mechanism, ensuring atomic access to the state. For instance, the AWS S3 backend utilizes an Amazon DynamoDB table to coordinate and manage locks, preventing concurrent writes to the state file stored in S3, while other backends use different underlying services.
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 →
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.