TF-004 Understand Terraform's purpose Practice Question
Which THREE statements accurately describe Terraform state? (Select THREE.)
⚠ Common exam trap
A common misconception tested in this domain is that state locking is an automatic feature of Terraform, when in fact it requires explicit backend configuration, and that state inherently contains secrets, whereas it only holds resource attributes that may incidentally include sensitive values.
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 is used to map real-world resources to configuration.
Option A is correct because Terraform state maintains the binding between resource instances declared in configuration and the actual remote objects, storing attributes and resource addresses so Terraform knows what exists and what to update or destroy. Option B is correct because remote backends such as S3 with DynamoDB, Terraform Cloud, or Consul allow the state file to be stored centrally and shared across team members, enabling collaboration and consistent operations. Option E is correct because, absent an explicit backend configuration, Terraform writes state to a local file named terraform.tfstate in the working directory. Option C is not correct as a general statement because while state can contain sensitive values in plaintext, it does not inherently 'contain sensitive data by default' for every configuration. Option D is not correct because locking is not automatic in all cases; it depends on the backend, and the default local backend does not provide locking, while remote backends like S3 require explicit DynamoDB locking configuration.
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 is used to map real-world resources to configuration.
Why this is correct
Terraform state is a critical component that maintains a mapping between the resources defined in your configuration files (e.g., main.tf) and the actual infrastructure objects provisioned in the cloud or on-premises. It records metadata such as resource IDs, attributes, and dependencies, allowing Terraform to understand the current state of your managed infrastructure. This mapping enables Terraform to perform accurate plans and apply changes, ensuring it only modifies or creates resources as intended.
- ✓
State can be shared among team members using remote backends.
Why this is correct
For collaborative environments, Terraform state can be stored in remote backends, such as Amazon S3, Azure Blob Storage, Google Cloud Storage, or HashiCorp Terraform Cloud. This allows multiple team members to access and modify the same infrastructure, ensuring everyone operates with the most current understanding of the environment. Remote backends are essential for preventing state drift and enabling consistent operations across a team.
- ✗
State contains sensitive data by default.
Why it's wrong here
Terraform state does not inherently contain sensitive data by default. While it can store resource attributes that might be considered sensitive (e.g., database passwords, API keys) if those attributes are explicitly exposed by the resource provider and captured in the state, Terraform itself does not intentionally populate state with sensitive information unless it's a necessary part of the resource's configuration or output. Best practices recommend avoiding storing highly sensitive data directly in state and using external secrets management systems instead.
- ✗
State is automatically locked to prevent concurrent modifications.
Why it's wrong here
Terraform state is not automatically locked by default to prevent concurrent modifications. While state locking is a crucial feature for team collaboration and preventing corruption, it relies on the chosen backend's capabilities and often requires explicit configuration. Backends like Amazon S3 with DynamoDB, Azure Blob Storage, or Terraform Cloud provide mechanisms for state locking, but this functionality is not inherent to Terraform's local state management.
- ✓
State is stored locally by default.
Why this is correct
By default, Terraform stores its state locally on the filesystem where the `terraform apply` command is executed. This local state is saved in a file named `terraform.tfstate` within the working directory. This default behavior is suitable for individual development or testing but is generally not recommended for team collaboration or production environments due to the risk of state corruption or loss.
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.