TF-004 Understand Terraform basics Practice Question
Which three of the following are true regarding Terraform state?
⚠ Common exam trap
A common pitfall is thinking that state is optional or that the filename is fixed; however, state is mandatory for Terraform to track resources and the filename is fully configurable via the backend configuration.
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 can be stored in a local file or remotely.
Terraform state is the mechanism by which Terraform maps real-world resources to your configuration, and it can be stored either in a local file (e.g., terraform.tfstate) or remotely in a backend such as S3, Azure Storage, or Terraform Cloud. This flexibility allows teams to share state and enable collaboration, while local storage is suitable for single-user or testing scenarios.
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 can be stored in a local file or remotely.
Why this is correct
Terraform state can be stored locally in a `terraform.tfstate` file, which is suitable for individual development and testing. For collaborative environments and production deployments, remote state storage is highly recommended. Terraform backends, such as Amazon S3, Azure Storage, or HashiCorp Consul, enable durable, shared, and versioned state management, often including state locking to prevent concurrent modifications and ensure consistency across teams.
- ✗
State can be manually edited with a text editor without risk.
Why it's wrong here
Manually editing the Terraform state file with a text editor is extremely risky and strongly discouraged. The state file contains sensitive resource IDs, internal checksums, and a specific JSON structure that can be easily corrupted by manual changes. Such corruption can lead to inconsistencies between the state and real-world infrastructure, causing Terraform to misidentify resources, destroy unintended components, or fail during subsequent operations. Instead, use `terraform state` commands for safe state manipulation.
- ✓
State is required for Terraform to function.
Why this is correct
Terraform state is absolutely fundamental for the tool's operation, serving as the authoritative record of the infrastructure it manages. It maps real-world cloud resources to the configuration defined in your `.tf` files, storing their unique identifiers and attributes. Without state, Terraform would be unable to track which resources it created, compare the current configuration against the deployed infrastructure, or determine the necessary changes during `terraform plan` and `terraform apply` operations.
- ✗
State must be stored in a file named terraform.tfstate.
Why it's wrong here
While `terraform.tfstate` is the default filename for local state, it is not a mandatory requirement for all Terraform deployments. Users can configure a different local state filename using the `terraform init -state=path/to/my.tfstate` command or by specifying a backend configuration. Furthermore, when using remote backends like S3 or Azure Storage, the state is stored externally and may not even reside in a local file with any specific name after initialization, making the default local filename irrelevant.
- ✓
State contains resource metadata and dependencies.
Why this is correct
The Terraform state file meticulously records comprehensive metadata about each managed resource, including its unique identifier, current attributes, and the provider responsible for its management. This metadata is crucial for Terraform to interact with the correct API endpoints and perform operations like updates or deletions. Additionally, the state implicitly tracks resource dependencies, allowing Terraform to correctly determine the order of creation, modification, and destruction operations to maintain infrastructure integrity.
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.