In Terraform, what do `terraform state list` and `terraform state show` tell you, and how do they differ from the other `terraform state` subcommands?

## Addresses are the vocabulary Everything in this command family is keyed by a **resource address** — the identifier Terraform uses for one object it manages. An address is the resource type and local name (`aws_s3_bucket.assets`), optionally prefixed by module path (`module.network.aws_vpc.main`) and suffixed by an index key when the resource was declared with multiple instances (`module.network.aws_subnet.private[0]`, `aws_instance.web["blue"]`). Nothing else in state surgery works until you have the address exactly right, and that is what `terraform state list` is for. ## terraform state list Run with no arguments, it prints every address in the current workspace's state, one per line: ```bash $ terraform state list aws_s3_bucket.assets aws_s3_bucket_versioning.assets module.network.aws_vpc.main module.network.aws_subnet.private[0] module.network.aws_subnet.private[1] ``` Pass one or more addresses to filter — `terraform state list module.network` prints only the addresses under that module. On a large estate this is the fastest way to answer "is that thing actually managed by this configuration, or did someone build it by hand?", which is the question that precedes every import. Note that it lists what Terraform **tracks**, not what exists in the cloud. An object created in the console does not appear here, and an object that was deleted out of band still appears here until a refresh notices it is gone. ## terraform state show `terraform state show <address>` dumps the recorded attributes of exactly one resource: ```bash $ terraform state show module.network.aws_vpc.main # module.network.aws_vpc.main: resource "aws_vpc" "main" { id = "vpc-0abc123" cidr_block = "10.0.0.0/16" } ``` The output looks like configuration but is not configuration — it includes computed attributes that you never write, and pasting it into a `.tf` file will not work as-is. Its practical value is the recorded `id`: that is the string Terraform believes maps to a real object, and comparing it against the console is how you confirm an import landed on the right thing or that a resource is pointing where you expect. `terraform state show` does not call the provider. It renders stored values from the last apply or refresh, so if someone changed the object an hour ago you will not see it here — you would see it in a plan, which refreshes first. ## The read/write split The `terraform state` family splits cleanly in two: - **Read-only**: `list`, `show`, and `pull` (which streams the raw state JSON to stdout, useful for piping into `jq`). - **Mutating**: `mv` (change an address), `rm` (stop tracking an object), `push` (overwrite state wholesale), `replace-provider`. The mutating ones acquire the state lock and write new state; with local state they leave a backup file behind. They are the ones that can ruin an afternoon: `rm` can orphan a live production database, `push` can clobber a colleague's work. Modern Terraform gives you declarative equivalents for the common cases — `moved` blocks instead of `state mv`, `removed` blocks instead of `state rm`, `import` blocks instead of `terraform import` — and those go through code review, run in CI, and are idempotent. The CLI subcommands remain for the situations no block covers. There is also plain `terraform show`, which renders the whole state, or a saved plan file, rather than a single resource. Do not confuse it with `terraform state show`. ## Why not just open the state file Because state is a JSON document with a `serial` counter and internal structure that Terraform maintains, and hand-editing it is the one thing every piece of Terraform documentation tells you not to do. `state list` and `state show` exist precisely so you never need to. On a remote backend, opening the file is also not free — you would be pulling and re-uploading an object other people are locking. ## Typical session A real state repair almost always starts the same way: `terraform state list` filtered down to find the address, `terraform state show <address>` to confirm the recorded ID matches the object you mean, and only then a `moved`, `removed`, or `import` block — written into the configuration, opened as a pull request, and applied by the pipeline like any other change.