You delete a resource block from your Terraform configuration and run apply. The config no longer says anything about what that resource depended on, yet Terraform still destroys it in a safe order. How?

## The problem the recorded edges solve Dependency ordering during a normal apply comes from the configuration: Terraform reads your references and `depends_on` entries and builds a graph. Destroying a resource that is *still declared* — a replacement, say — is covered by that graph. The hard case is the orphan. You delete the block entirely. Now the configuration says nothing at all about that resource: not its type, not its provider, and not what it depended on. Terraform still has to delete the real object, and deleting things in the wrong order fails loudly in every cloud — a subnet with an attached network interface, a security group referenced by a running instance, an IAM role still attached to a service. The answer is that the state entry is self-sufficient. It contains everything needed to destroy the object without consulting the config: ```json { "mode": "managed", "type": "aws_instance", "name": "web", "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]", "instances": [ { "attributes": { "id": "i-0abc123def456" }, "dependencies": ["aws_security_group.web", "aws_subnet.private"] } ] } ``` The entry names the provider to call, the object ID to delete, and the addresses this object depended on the last time it was applied. ## Reversal is the whole trick Create order follows the edges; destroy order reverses them. If `aws_instance.web` recorded a dependency on `aws_security_group.web`, then on the way out the instance must be deleted **first**, and only then the security group. Terraform gets that from the recorded list, not from re-deriving anything, so deleting both blocks in one commit still produces the correct sequence. This also means a destroy of an orphan is a genuinely different code path from an update. Terraform is not diffing anything — there is nothing to diff against. It is walking recorded entries with no configuration counterpart and deleting them in reverse-recorded order. ## When the recorded list is stale Because the edges are written at apply time, they describe the *last applied* relationship, not the current one. Two situations make them wrong: **Never applied.** You added a reference in the config but the change was never applied, so the recorded entry still reflects the older, edge-free relationship. Delete both resources now and Terraform may order the destroy by an obsolete graph. **Removed from state manually.** If the entry a resource depended on is no longer in state, the edge points at nothing and contributes no ordering. The symptom is always the same: an apply that fails partway through a destroy with a provider error saying the object is still in use, still attached, or has dependent objects. The remedy is equally boring — apply the reference-adding change first so the edges get recorded, then remove the resources; or destroy in two steps, dependent first. ## Implicit versus explicit, as it lands in state Both kinds of dependency end up in the same list. An implicit dependency — one resource's argument referencing another's attribute — and an explicit one both get recorded as an address in `dependencies`. Once written, state does not distinguish where the edge came from, which is convenient: destroy ordering works identically for either. ## What this tells you about state's role This is the clearest demonstration that state is not a cache of the configuration. If it were, deleting the config would delete the knowledge, and there would be nothing left to destroy or order. Instead, state is a self-contained description of the managed estate — enough on its own to identify every object, call the right provider, and take it all down in a safe sequence. The configuration describes what you *want*; state describes what *is*, including the shape of the relationships between the things that are. ## In an interview Say it in one line — "the dependency edges are recorded in the state entry, and destroy walks them in reverse" — then add the staleness caveat, because that is what turns a fact into experience. Candidates who assume Terraform re-reads the config, or that it asks the cloud provider what depends on what, are describing a system that could not delete an orphan at all.