TF-004 Understand Terraform basics Practice Question
Which THREE of the following are characteristics of Terraform state? (Choose three.)
⚠ Common exam trap
The Terraform exam often tests the misconception that state stores the entire configuration or provider code, but state only holds the mapping of resources to real-world objects and metadata like dependencies, not the configuration itself or provider binaries.
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
✓
It can be stored remotely to enable team collaboration
Terraform state is a critical artifact that maps the resources defined in your configuration to the real-world objects they represent, which is exactly what option C describes and is why it is correct. Option D is also correct because the state file stores metadata about resources, including dependency relationships between them, which Terraform uses to determine the correct order of operations during plan and apply. Option A is correct because state can be configured with a remote backend (such as S3, Terraform Cloud, or Consul) to enable team collaboration, locking, and shared access to the same state. Option B is incorrect because the state file does not contain the entire Terraform configuration; the configuration lives in .tf files, while state only records the mapping and metadata of managed resources. Option E is incorrect because provider source code is not stored in state; providers are downloaded and installed separately via terraform init into the plugin cache or .terraform directory.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
It can be stored remotely to enable team collaboration
Why this is correct
Terraform state can be stored remotely using various backend configurations, such as Amazon S3, Azure Blob Storage, Google Cloud Storage, or HashiCorp Terraform Cloud. This remote storage is crucial for team collaboration, allowing multiple users to safely work on the same infrastructure by providing a shared source of truth. Remote state backends often include state locking mechanisms to prevent concurrent operations from corrupting the state file, ensuring consistency and preventing race conditions.
- ✗
It contains the entire Terraform configuration
Why it's wrong here
The Terraform state file does not contain the entire Terraform configuration (your HCL code files). Instead, it records the current actual state of the infrastructure resources that Terraform manages, including their unique identifiers, attributes, and relationships. Your configuration files define the *desired* state, while the state file reflects the *observed* state of the real-world resources, acting as a bridge between the two.
- ✓
It maps real-world resources to your configuration
Why this is correct
The Terraform state file serves as a critical mapping between the resources defined in your Terraform configuration files and their corresponding real-world instances in your cloud provider or on-premises environment. This mapping allows Terraform to track which specific cloud resources (e.g., an EC2 instance with a particular ID, an S3 bucket with a specific name) are managed by a given resource block in your configuration. It is fundamental for Terraform to understand what exists and how it relates to your code.
- ✓
It includes metadata such as resource dependencies
Why this is correct
Terraform state includes vital metadata, such as implicit and explicit resource dependencies, which are crucial for Terraform to correctly plan and apply changes. This metadata allows Terraform to build a dependency graph, determining the precise order in which resources must be created, updated, or destroyed. It also stores resource attributes that are not directly specified in the configuration but are generated by the provider, like IP addresses or ARN values.
- ✗
It stores the provider source code
Why it's wrong here
The Terraform state file does not store the provider source code itself. Provider binaries (executables for interacting with cloud APIs) are downloaded and cached locally by the `terraform init` command, separate from the state file. The state file only records which specific provider *version* was used to manage a particular resource, ensuring that future operations can use the correct provider for consistency, but it does not contain the executable code.
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.