Terraform Associate 004 #5 State Management: Backends, Locking, State Commands, and Sensitive Data

Infrastructure Terraform IaC Certification
4 min read

State is one of the heaviest-weighted areas on the Associate exam. Basics #5, #9, and Ops #2 built this material hands-on; here we rearrange it into the shape the exam asks about — “what does this command change” and “what is the correct response in this situation”.

The purpose and location of state #

Start with the definition the exam expects. State is the mapping between the resources in your configuration and real infrastructure objects — the basis that lets plan compute a diff, and the record of dependencies between resources and of attribute values. By default it is stored in the working directory as a terraform.tfstate file (the local backend), and a backend configuration can move it to remote storage. Any option to the effect of “Terraform works without state” is wrong: without state, Terraform has no idea what it is managing.

Local vs remote backends #

The three problems a remote backend (S3, HCP Terraform, and so on) solves are exam points straight out of Basics #9.

  1. Team sharing: everyone sees the same state.
  2. Locking: prevents concurrent runs from corrupting state. When the backend supports locking, plan and apply take the lock automatically — no separate command is needed.
  3. Durable storage: no more risk of a lost or deleted local disk.

Two lock questions come up constantly. The first answer to “you hit a lock error — now what?” is wait: it is the normal signal that another run is in progress. force-unlock is the last resort, used only after confirming no run is actually active. And force-unlock only releases the lock; it does not change state contents — another distinction the exam likes.

State commands: what they change and what they leave #

CommandWhat it doesAffects real infrastructure
state listLists addresses of managed resourcesNo (read-only)
state show <address>Prints the attributes of one resourceNo (read-only)
state mv A BChanges an address within stateNo (only the record moves)
state rm <address>Removes from state (gives up management)No (the resource remains)

The right-hand column is what the exam targets. state rm does not delete the resource — it only removes it from Terraform’s management. Deletion is the job of destroy (or of removing the block from code and applying). state mv is the tool that prevents recreation when a refactor renames a resource or moves it between modules. Bundle it with its declarative counterpart, the moved block (Practice #9), with the counterpart of state rm, the removed block, and with the import block that adopts existing resources (Ops #2) — memorize the imperative-to-declarative mapping and you can handle every related question.

Imperative to declarative mapping 
Imperative           Declarative (code, reviewable)
terraform import  →  import block
state mv          →  moved block
state rm          →  removed block

refresh: now part of plan #

The standalone terraform refresh command that appears in older study material is on its way out. The current answers are that plan and apply perform a refresh automatically at run time, and that when you only want to check for a mismatch you use plan -refresh-only — the option we sorted out in #4. It shows up bundled with the concept of drift.

Sensitive data in state #

State stores every attribute of managed resources in plaintext. Marking a value sensitive only hides it from screen output, not from state — a fact we verified directly in Basics #5, and the exam asks it exactly like that. The correct-answer statements therefore run as follows.

  • Do not commit state files to version control
  • Keep state in a remote backend, with encryption at rest and access control applied
  • Treat access to state itself as access to secrets

And the thread continues to write-only arguments, a new axis in 004: they are the more fundamental answer, where the value is never stored in state at all. The details come in #8.

Recap #

What we covered in this post:

  • State is the mapping between configuration and real infrastructure, and the basis for plan. The default location is a local terraform.tfstate, and backends move it remote
  • The value of a remote backend is sharing, automatic locking, and durable storage. The first answer to a lock error is waiting; force-unlock is the last resort and does not touch state contents
  • state mv and rm do not change real infrastructure. rm is removal from management, not deletion
  • The declarative counterparts of import, mv, and rm are the import, moved, and removed blocks
  • refresh is built into plan, and checking uses -refresh-only. State is plaintext, so no commits, encryption, and access control are the correct-answer direction — and the fundamental answer, write-only, continues in #8

In the next post (#6 Modules) we cover module source addresses, versions, and input/output syntax — a short area with a high question density.

X