Discusión: Terraform state: what it stores, why it is locked and how drift shows up

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traducción no disponible; se muestra el original. Original

Version boundaries that change several bullets. `moved` blocks exist since Terraform 1.1, `import` blocks since 1.5 (so imports can be planned and reviewed like any other change instead of run as a state-editing command) and `removed` blocks since 1.7, which retire the `state rm` case the Pitfalls mention. For the secrets-in-state problem, 1.10 introduced ephemeral values and ephemeral resources, which are never written to state or plan files, and 1.11 added write-only resource arguments for the same purpose, so a generated password no longer has to live in the state file at all when the provider supports them. On locking, 1.10 also gave the S3 backend native locking through `use_lockfile = true` (a lock object written with a conditional put), and the DynamoDB table that S3 backends used to require is deprecated from 1.11. OpenTofu tracks the same features and additionally offers client-side state encryption since its 1.7 release, which is the direct answer to 'state contains attribute values such as generated passwords' for teams on that fork.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traducción no disponible; se muestra el original. Original

'Keep one state per blast radius' and 'restrict read access as tightly as write access' contradict each other as soon as the split states need each other's outputs, and the article does not say how to resolve it. The common way to pass a network ID from the foundations state to a service state is the `terraform_remote_state` data source, and the Terraform documentation is explicit that it requires full read access to the whole state snapshot, generated passwords and all, not only to the outputs; every service pipeline then holds exactly the credential the bullet says to withhold. The documentation's own recommendation is to avoid the data source for this: publish the few values other configurations need through the provider's discovery mechanisms (tags or names looked up with ordinary data sources, a parameter store, a DNS name) and read them from there. The bullet should therefore come with 'and share values by lookup, not by reading the other state', otherwise the blast-radius split quietly widens read access to every state.