Try 10 focused Terraform Associate (004) questions on Terraform State Management, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try Terraform Associate (004) on Web View full Terraform Associate (004) practice page
| Field | Detail |
|---|---|
| Exam route | Terraform Associate (004) |
| Topic area | Terraform State Management |
| Blueprint weight | 11% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Terraform State Management for Terraform Associate (004). Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 11% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Terraform State Management
A team renamed a resource block from aws_instance.web to aws_instance.app without changing the real cloud instance it manages. They want Terraform to keep tracking the same object and avoid a destroy/create caused only by the address change. What is the most appropriate Terraform action?
Options:
A. Run terraform apply -refresh-only to rename the resource.
B. Add a moved block mapping the old address to the new one.
C. Remove the state entry, then run terraform import.
D. Run terraform init to update resource addresses in state.
Best answer: B
Explanation: Use a moved block when the Terraform address changes but the underlying infrastructure object stays the same. This is the supported refactoring workflow for preserving state and avoiding an unnecessary destroy/create plan.
A moved block is designed for configuration refactoring. It tells Terraform that the object previously tracked at one resource address should now be tracked at a different address, such as after renaming a resource block or moving it into a module. Because the real infrastructure did not change, Terraform should update the state mapping rather than treat the new address as a brand-new resource.
terraform import is mainly for bringing existing infrastructure under Terraform management when it is not already in state. A refresh-only operation updates stored attributes from the remote system to detect drift, but it does not change resource addresses. terraform init prepares the working directory, backend, and providers; it does not rewrite state addresses.
The key takeaway is that address changes use moved blocks, while drift uses refresh behavior and unmanaged objects use import.
Topic: Terraform State Management
An HCP Terraform workspace is connected to VCS. A speculative plan from a pull request shows two in-place updates, even though the pull request claims to contain only terraform fmt changes. Another engineer also changed a workspace variable earlier that day. The team wants a safe explanation before any apply and must avoid risky changes to shared state. What is the best next action?
Options:
A. Queue a refresh-only apply to accept the drift.
B. Manually edit the workspace state to remove the updates.
C. Review the VCS diff and workspace variable history first.
D. Run a local terraform plan to confirm drift.
Best answer: C
Explanation: Start by checking whether anything besides formatting changed. terraform fmt only adjusts file layout, while a changed workspace variable can legitimately change planned actions, so unexpected updates do not automatically mean true drift.
True infrastructure drift means the real remote object changed outside Terraform, so the refreshed state no longer matches Terraform’s expected values. That is different from a normal plan caused by a meaningful configuration or input change. In this scenario, terraform fmt is non-semantic and cannot create resource updates, but a changed HCP Terraform workspace variable can change the desired state and produce valid planned actions.
Because the team wants safe review, collaboration, and state safety, the best first step is to inspect the pull request diff and the workspace variable history before applying anything or touching state. If the only change was formatting, then investigate possible drift next. If a variable value changed, the plan may be expected rather than drift.
The key takeaway is that formatting changes are harmless to behavior, while variable changes can alter plans without indicating unmanaged drift.
Topic: Terraform State Management
Your team uses a shared remote backend so engineers can review and apply changes safely from the same Terraform configuration. During terraform apply, an engineer sees:
Error: Error acquiring the state lock
Lock Info:
Operation: OperationTypeApply
Who: teammate@example.com
They want the safest next step without risking shared state. What should they do?
Options:
A. Treat the message as a configuration error and run terraform validate
B. Re-run terraform apply with -lock=false
C. Delete the existing state and run terraform init again
D. Check for the active run holding the lock, wait or coordinate, then retry
Best answer: D
Explanation: This is a shared-state coordination issue, not proof that the Terraform configuration is invalid. State locking exists to prevent concurrent changes, so the safest action is to verify another run is using the state, wait for it to complete, and then retry.
Terraform state locking protects shared state from concurrent writes. When Terraform cannot acquire the lock, the first interpretation should be that another user or run is already operating on that same state, not that the HCL itself is broken. In a collaborative workflow, the safe response is to confirm whether an active operation is holding the lock, let it finish, and retry.
terraform validate checks configuration correctness, but it does not resolve lock ownership. Disabling locking or deleting state bypasses the safety mechanism that prevents corruption. Only after confirming a lock is stale from an interrupted or crashed operation would you consider a controlled unlock procedure.
The key takeaway is that lock waits and lock failures are primarily state-coordination signals.
terraform validate checks configuration structure, not whether shared state is currently locked by another operation.-lock=false removes the protection against concurrent state updates and can corrupt shared state.Topic: Terraform State Management
Which statement best describes Terraform state locking?
Options:
A. It stores the state file in a shared remote location for team access.
B. It pins provider plugin versions so all runs use identical dependencies.
C. It prevents concurrent Terraform operations from writing incompatible changes to the same state.
D. It compares real infrastructure with configuration to identify drift before changes.
Best answer: C
Explanation: State locking is Terraform’s coordination mechanism for safe state updates. When one run holds the lock, another run cannot modify that same state until the lock is released, which prevents conflicting writes.
Terraform state is the record Terraform uses to map configuration to real infrastructure. State locking protects that record during operations that may update it. When locking is available, Terraform acquires a lock before changing state so a second user or run cannot write to the same state at the same time. This avoids race conditions, overwritten updates, and inconsistent state.
This is different from where state is stored, which plugins are selected, or whether drift is detected. The key idea is controlled access to state during active operations. A remote backend may support locking, and HCP Terraform manages this for workspace runs, but locking itself is specifically about preventing concurrent state modification.
Topic: Terraform State Management
A team stores Terraform code in Git, but each engineer currently runs it from a laptop. The configuration has no backend or cloud block, and the current provider setup already provisions the correct resources. They now need shared state, reviewed plans before apply, and protection against simultaneous updates. What is the best next action?
Options:
A. Configure an HCP Terraform workspace with a cloud block
B. Add provider aliases for each environment and keep local state
C. Refactor the configuration into modules and keep local runs
D. Change the provider version constraint and commit .terraform.lock.hcl
Best answer: A
Explanation: This is a state and collaboration problem, not a provider problem. Because no backend is configured, Terraform is using the local backend; moving to HCP Terraform with a cloud block provides shared remote state and reviewed runs while leaving resource APIs unchanged.
Terraform uses the local backend by default when no backend or cloud block is defined, so the state file stays on the machine running Terraform. The team’s issues—shared state, safe collaboration, and review before apply—are backend and workflow concerns. A provider controls which external API Terraform uses to manage resources, but it does not decide where state is stored or how teams coordinate changes.
cloud block addresses state location and run coordination.Provider pinning, aliases, and modules can all be useful, but they do not replace the local backend with a collaborative state solution.
Topic: Terraform State Management
A team uses one shared Terraform state for a production environment. Multiple engineers or automated runs might start terraform apply against that same state around the same time. Why is state locking especially important in this workflow?
Options:
A. It automatically splits the state into separate files per resource.
B. It stores provider plugins in the backend for consistent installs.
C. It guarantees the real infrastructure always matches the configuration.
D. It ensures only one operation can update the shared state at a time.
Best answer: D
Explanation: State locking protects Terraform state when multiple users or runs target the same deployment. It prevents simultaneous state updates, which helps avoid conflicting writes, failed runs, and corrupted shared state.
State locking is a safeguard for shared Terraform state during operations that may change it. In a collaborative workflow, two people or an automated run and a human operator could both start work from the same current state and then try to write back changes. Without locking, those concurrent updates can conflict and leave the state inaccurate or inconsistent. A backend that supports locking lets Terraform allow one state-changing operation at a time, preserving the integrity of the shared source of truth. Locking does not manage plugins, reorganize state files, or guarantee that infrastructure never drifts; it specifically protects state during concurrent access.
Topic: Terraform State Management
A team stores Terraform state in a shared backend so multiple engineers can work from different machines. They specifically want to prevent two people from updating the same state at the same time. Which statement is correct?
Options:
A. Any remote backend automatically prevents simultaneous state writes.
B. Choose a backend with locking; remote storage alone is not enough.
C. Configure locking in the provider, not the backend.
D. Run terraform plan first instead of using locking.
Best answer: B
Explanation: For team workflows, the key issue is concurrent state updates. Terraform needs a backend that supports state locking; simply storing state remotely does not always provide that protection.
Terraform state records information about managed infrastructure, and the backend controls where that state is stored. Some backends also support state locking, which lets Terraform prevent more than one write operation from changing the same state at the same time. That matters in collaborative workflows, because two overlapping runs can conflict with shared state. Remote or shared storage improves team access, but storage alone is not the same as locking. Provider configuration tells Terraform how to talk to an infrastructure API, and commands like terraform plan preview changes, but neither one replaces backend-supported locking. The key distinction is shared state location versus safe coordination of state writes.
terraform plan misses the problem; planning does not serialize concurrent state updates.Topic: Terraform State Management
A Terraform configuration has no backend block and no HCP Terraform cloud block. Which state-storage approach does Terraform use by default?
Options:
A. terraform.lock.hcl in the working directory
B. An HCP Terraform workspace created automatically
C. The remote backend without any extra configuration
D. The local backend on the machine running Terraform
Best answer: D
Explanation: Terraform uses the local backend by default when no other backend is configured. That means state is stored locally, typically in a terraform.tfstate file, until you explicitly configure a different backend or HCP Terraform.
A backend tells Terraform where to store state. If you do not configure a backend block and do not connect the configuration to HCP Terraform with a cloud block, Terraform falls back to the local backend. In that default mode, state is kept on the same machine that runs Terraform, usually in a local terraform.tfstate file.
Remote state storage is not automatic; it must be configured. HCP Terraform also requires explicit setup. The dependency lock file is a separate feature that records provider version selections and checksums, not infrastructure state. The key takeaway is simple: no backend configured means local state by default.
terraform.lock.hcl fails because that file tracks provider versions, not state.Topic: Terraform State Management
A cloud engineer reviews this root module before running terraform init:
terraform {
required_version = ">= 1.12.0"
}
resource "null_resource" "example" {}
No other backend settings are configured. What is the best interpretation?
Options:
A. Terraform will use HCP Terraform and keep state remotely.
B. Terraform will use the local backend and keep state on local disk.
C. Terraform will delay state storage until a backend block is added.
D. Terraform will ask the user to select a backend during initialization.
Best answer: B
Explanation: Terraform uses the local backend by default when a root module does not configure any other backend. That means state is stored on the machine running Terraform rather than in HCP Terraform or another remote backend.
A Terraform backend controls where state is stored. In this snippet, the terraform block sets only a version requirement and does not include any backend configuration, so Terraform falls back to its default backend: local.
With the local backend, state is written to local files on the system where Terraform runs. Remote backends such as HCP Terraform, S3, or others are not automatic; they must be explicitly configured in the root module and then initialized. The key takeaway is that Terraform does not require you to choose a backend before it can manage state, because local is the built-in default.
terraform init does not ask you to pick one when none is configured; it defaults to local.Topic: Terraform State Management
A team has one Terraform root configuration and currently runs it from a single laptop using the default local backend. They now need two engineers to collaborate on the same infrastructure, keep state in one central place, and review plans before any apply. What is the best next step?
Options:
A. Refactor the root configuration into child modules
B. Keep local state and have each engineer run Terraform locally
C. Use an HCP Terraform workspace with remote state and runs
D. Commit terraform.tfstate to Git and keep the local backend
Best answer: C
Explanation: The local backend is simple because it stores state on the machine running Terraform, which works well for solo or disposable use. Once multiple engineers need shared state and reviewed changes, an HCP Terraform workspace is a better fit because it centralizes state and the run workflow.
A local backend stores Terraform state in a local file, typically terraform.tfstate, on the machine where Terraform runs. That makes it easy to start and reasonable for one person or short-lived work, but it is limited for team collaboration because state is not centrally managed and runs are not inherently shared or reviewable. In this scenario, the key requirements are collaboration, centralized state, and plan review before apply. An HCP Terraform workspace matches those needs by storing state remotely and giving the team a shared run workflow.
Improving module structure can help reuse, but it does not solve the state and collaboration problem.
Use the Terraform Associate (004) Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try Terraform Associate (004) on Web View Terraform Associate (004) Practice Test
Read the Terraform Associate (004) Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.