Terraform state is the most under-discussed file in an infrastructure codebase. It is not configuration and it is not a log — it is the mapping between your code and the real resources, and losing it or corrupting it is considerably worse than losing the code itself.

Moving state to S3 with DynamoDB locking is the standard answer, but the reasoning behind it is easy to repeat without understanding. The lock does not protect you from a bad plan; it protects you from two applies racing against the same state file and leaving it describing infrastructure that no longer matches reality.

These are my notes from setting it up for a small team: how I split state files per environment, what versioning and encryption on the bucket buy you, and the failure modes — stale locks, a colleague's interrupted apply, drift between state and reality — that are worth understanding before they happen at an inconvenient moment.