Terraform State: The Part of Infrastructure as Code You Must Protect

Infrastructure as code makes resource definitions reviewable, but the configuration files are not the whole system. Terraform also maintains state that maps those definitions to real resources and records attributes needed to manage them. Treating state as an ordinary generated file creates avoidable risks. Losing it can complicate management of existing infrastructure. Exposing it can disclose sensitive information. Allowing competing writers can cause conflicting operations. ## State is operational data A configuration may describe a database, while state records the specific resource Terraform manages. Removing a local state file does not remove the database; it removes part of Terraform's knowledge about it. State can contain sensitive values returned by providers or supplied through configuration. Marking an output as sensitive controls some display behavior, but it does not automatically eliminate that value from state. Do not commit state files to the source repository. Use a suitable remote backend with appropriate access controls, encryption, and versioning. Restrict who can read state as carefully as who can apply changes. ## Coordinate changes and review the plan A remote backend can support shared state and locking, depending on its capabilities. Locking helps prevent simultaneous operations from writing incompatible state, but it does not replace human coordination. Keep plans and applies tied to the same reviewed change. A plan generated before someone else modified infrastructure may no longer represent the operation you expect. Understand how your workflow detects stale plans and protects against concurrent applies. Separate environments and ownership boundaries thoughtfully. One enormous state can make unrelated changes interfere, while excessive fragmentation creates dependency-management overhead. Choose boundaries that match operational responsibility and the impact of a mistake. ## Recovery requires more than a backup file Enable state history where supported and document how to restore or recover it. Restoring an old state is not the same as rolling back infrastructure. Real resources may have changed since that snapshot. Use documented import and state-management procedures when reconciling existing resources. Manual state edits can be dangerous because an incorrect mapping may cause later operations to replace or destroy the wrong resource. Detect drift: changes made outside the infrastructure workflow can invalidate assumptions in configuration. Decide how urgent operational changes are recorded and reconciled after an incident. Review provider upgrades and version constraints deliberately. Changes in provider behavior can affect plans even when the resource configuration looks unchanged. Infrastructure as code is valuable because it makes intended changes explicit. Protecting state preserves the link between that intention and the resources actually running. Without that link, a clean repository can still describe a very uncertain production environment. ## Further reading - [HashiCorp: Terraform state](https://developer.hashicorp.com/terraform/language/state) - [HashiCorp: Sensitive data in state](https://developer.hashicorp.com/terraform/language/state/sensitive-data)