7.2.1. Inspecting State with the CLI
💡 First Principle: Because the plan is "config minus state," being able to read and surgically edit state is how you diagnose and fix mismatches — but every state subcommand acts on the record, never the real resource, which is what makes them safe to explore.
The state subcommands the exam expects you to recognize:
| Command | What it does | Touches real infra? |
|---|---|---|
terraform state list | Lists resource addresses in state | No |
terraform state show <addr> | Shows a resource's recorded attributes | No |
terraform state mv <a> <b> | Renames/moves an address in state | No |
terraform state rm <addr> | Removes a resource from state (stops managing) | No |
terraform show | Human-readable view of state or a saved plan | No |
state list and state show are pure inspection; state mv and state rm modify the record (the declarative moved/removed blocks from Phase 6 are now the preferred way to do those). terraform output reads root output values from state.
⚠️ Exam Trap: terraform state rm makes Terraform forget a resource (it's no longer managed) but leaves the real resource running — it is not a destroy. Likewise state mv changes only the address in state. Don't confuse record edits with infrastructure changes.
Reflection Question: You run terraform state rm aws_instance.old. What happens to the real instance, and what will the next apply do regarding it?
