Terraform state management

Terraform keeps a state file, the ledger that records which real object each resource in your configuration is bound to; every plan reads that ledger against reality and every apply updates it. The single mistake this domain punishes is reading a state operation as an action on infrastructure: terraform state rm makes Terraform forget a server that keeps running, and terraform apply -refresh-only copies a hand-made change into the ledger without touching the resource. Hold one picture the whole way through, that these commands edit the record and not the world, and the most common wrong answers fall away. The one deliberate exception is a bare removed block, which destroys the object by default unless you add lifecycle { destroy = false }, and the exam likes to probe exactly that seam.

Work the subtopics in order and each one settles a single question. Where does state live by default? The local backend stores it as a plaintext terraform.tfstate file on your own machine, which is fine for a single operator. How is it kept safe when two people run at once? State locking takes one lock before any state-writing operation, automatically, so two runs cannot interleave and corrupt the file. Where should a team's state live instead? A backend block, or a cloud block for HCP Terraform (HashiCorp's managed service, formerly Terraform Cloud), moves the ledger to one shared, locked store and off individual laptops. How do you keep the ledger honest afterward? You reconcile it with reality when infrastructure drifts, and you re-map or drop addresses when you refactor the code.

Across this domain the exam rewards the safer path whenever more than one option would technically succeed. Prefer remote state with locking over passing a local file around, since a shared, locked ledger is the whole reason to configure a backend. Prefer the declarative moved and removed blocks over the one-off terraform state mv and terraform state rm commands, since the blocks run through the normal plan and apply, appear in review, and are tracked in version control (a bare removed block destroys by default, so add lifecycle { destroy = false } when you want it to forget the object like state rm rather than delete it). And treat -lock=false and terraform force-unlock as last-resort escape hatches, never routine speed-ups: -lock=false skips locking for a command, while force-unlock clears a stuck lock you own.