What State Stores

## The mechanics Terraform decides what to do for each resource by looking it up in state by address. The loop is: read the configuration, read the state, for each configured address find the matching state entry, refresh that entry from the provider, and diff. When state is empty, every address misses. A miss is not an error — it is the definition of "needs to be created." So `terraform plan` reports the whole configuration as adds, with a plan summary of the form `Plan: 42 to add, 0 to change, 0 to destroy`. ## What apply actually does Apply then does exactly what the plan said. Two things happen at once: **Duplicates.** Every resource that *can* be created twice is created twice. You end up with two VPCs, two clusters, two load balancers, and a bill to match. The new objects go into the new state; the old ones exist nowhere in Terraform's world. **Partial failure.** Every resource that *cannot* be created twice fails at the provider — an S3 bucket whose name is globally unique, an IAM role with a fixed name, a subnet CIDR that collides inside the existing VPC. Terraform applies in dependency order and stops the affected branches on error, so the realistic outcome is a partially-created parallel estate plus a stack of provider errors, which is messier to clean up than either a clean duplicate or a clean failure. ## The orphans The original objects are the sharper problem. They are still running and still serving traffic, but Terraform has no entry pointing at them, so: - it cannot show them in a plan; - it cannot change them, because a change is expressed as an update to a recorded object; - it **cannot destroy them**. This is the part candidates miss. Destroy is not "find everything matching the config and delete it" — it is "for each object recorded in state, call the provider's delete with the recorded ID." With no record, there is no delete. Those resources now have to be cleaned up by hand in the console or the cloud CLI, or re-adopted first. ## Recovery, in order of preference **Restore a snapshot.** If the state was stored somewhere with version history, the previous snapshot is the fastest route back. Restore it, then run a plan and read it very carefully: the snapshot is from before whatever writes happened since, so anything created after it is missing from the restored ledger and will look new all over again, and anything destroyed after it will appear in state but be gone in reality — the refresh drops those entries and the plan proposes recreating them. **Re-adopt object by object.** Failing a snapshot, you rebuild the ledger by pointing Terraform at each existing object's real ID so it records the binding without creating anything. This is per-resource, per-instance work: dozens of IDs looked up in the console, a plan run after each batch, and every plan read to confirm it says no changes rather than proposing a replacement. For a large estate this is days, not hours. **Rebuild from scratch.** Sometimes honest and fastest for a small, stateless environment: create the parallel estate deliberately, cut over, then delete the orphans manually. Never an option where the estate holds data. ## Reading the aftermath The tell that this has happened, before you apply, is a plan that proposes creating things you know already exist. Treat any plan whose add count matches the size of your configuration as a stop signal — it almost always means Terraform is looking at the wrong state or no state at all, not that your infrastructure vanished. ## Why interviewers ask it The question tests whether you understand that state is *identity*, not a cache. A candidate who thinks state is an optimisation says "Terraform would just re-read everything from the API." A candidate who understands the ledger says "Terraform has no way to know those objects are its own, so it makes new ones and abandons the old." That difference also explains why state storage gets versioning, backups and restricted access — it is the one artifact whose loss cannot be reconstructed from your repository.