State is what lets an infrastructure tool know that the resource block in your configuration corresponds to a specific existing thing in your cloud account. Without it the tool cannot tell the difference between a resource it should update and one it should create, so it creates duplicates.
That makes state both critical and dangerous — critical because losing it breaks management of everything it tracked, dangerous because it contains every value your configuration touched, including secrets, in readable form.
What changed in 2026
- Managed state backends became the default. Hosted state with locking, versioning, and encryption included displaced hand-rolled bucket configurations.
- State splitting became standard advice. Guidance converged firmly on many small states over one large one, driven by blast radius and apply time.
- Drift detection matured. Scheduled comparison between state and reality moved into standard pipelines, as covered in infrastructure drift detection.
- Secret handling improved marginally. Ephemeral values reduced some secret persistence, and state remained sensitive by nature.
Storing it safely
| Requirement |
Why |
| Remote backend, never local |
Local state is lost with the machine and unusable by a team |
| Encryption at rest |
State contains secrets |
| Access control |
Read access to state is read access to secrets |
| Versioning |
Recovery from corruption or a bad apply |
| Locking |
Prevents concurrent applies corrupting state |
| Audit logging |
Who read and modified state |
| Never in version control |
The most common way credentials leak |
The secrets point is the one teams underestimate. Any sensitive value your configuration handles — a generated password, a connection string, a key — is written to state in readable form. Whoever can read the state backend can read all of it, regardless of what your configuration does to mark values as sensitive, since that only affects console output.
Locking prevents a specific and nasty failure. Two applies running simultaneously against the same state can each write a version reflecting only their own changes, losing the other's. The result is state that does not match reality, discovered later when a subsequent apply tries to create something that already exists.
Splitting by blast radius
A single state containing all infrastructure means every apply touches a plan covering everything, every run takes a long time, and a mistake can affect anything. It also means one lock, so only one change at a time across the whole organization.
Split along boundaries where changes are independent: by environment, by service or team, by lifecycle. Networking that changes rarely does not belong in the same state as application resources that change daily.
Reference across states by reading outputs, and keep those references few. A dense web of cross-state dependencies recreates the coupling you split to avoid.
The tradeoff is more states to manage and more places to look. The balance most teams land on is per-environment, per-major-component, which keeps individual applies fast and failures contained.
When state goes wrong
Drift — state and reality disagreeing — happens when someone changes infrastructure outside the tool. Detect it on a schedule rather than at apply time, so it is a scheduled conversation rather than a surprise during a deploy.
Recovery from a corrupted or lost state means importing existing resources back into a new state, which is tedious and possible. Versioning on the backend makes this rare, which is why it is a hard requirement rather than a nice-to-have.
Manual state manipulation should be a last resort performed with a backup taken first. It is the operation most likely to make a bad situation worse.
Common mistakes
- State in version control. Leaks every secret it contains.
- Local state. Lost with the machine, unusable by a team.
- No locking. Concurrent applies corrupt state.
- One giant state. Slow applies, wide blast radius, single lock.
- Assuming sensitive marking encrypts. It affects output display only.
- Manual state edits without a backup. Turns a problem into an incident.
FAQ
Can I encrypt secrets within state?
The backend should encrypt at rest. Within the state file, values are stored as the provider returned them. Treat the backend as a secrets store and control access accordingly.
How small should states be?
Small enough that an apply is fast and a mistake is contained. Per environment per component is a common working split.
What about importing existing infrastructure?
Supported and tedious for large estates. Generating configuration from existing resources helps; verify carefully before applying.
Should CI have write access to state?
Yes, and that makes your CI system a high-value target with production infrastructure access. Scope it per environment.
Where to go next
For drift, read infrastructure drift detection. For the credentials involved, secrets rotation guide and least privilege IAM.