When Terraform destroys a set of resources, what order does it use, and how does it work that order out?

## One graph, walked in two directions Terraform does not maintain a separate teardown plan. It builds the dependency graph from references exactly as it does for a create, and for destroy it inverts the edges. The rule that falls out is simple and worth being able to state in one line: **a resource is destroyed only after everything that depends on it has been destroyed.** So for: ```hcl resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" } resource "aws_subnet" "app" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" } ``` create order is VPC then subnet, and destroy order is subnet then VPC. This matches how the cloud provider behaves: AWS will not delete a VPC that still contains subnets, and refuses with an error rather than cascading. Terraform's reversed walk is what keeps you from ever making that call. Explicit edges reverse identically. `depends_on = [aws_iam_role_policy.app]` on an instance means the instance is created after the policy — and destroyed *before* it, so the instance is gone before its permissions are withdrawn. ## Why state stores dependencies The subtlety candidates miss is where the edges come from when the configuration no longer has them. If you delete a resource block entirely and run apply, there is no HCL left to read references from — yet Terraform still orders the removal correctly. It can do that because each resource instance in state carries a record of what it depended on when it was last applied. That recorded list is what orders a destroy of things the configuration has forgotten. This is one of the concrete reasons a stale or hand-edited state produces strange teardown behaviour: the ordering information lives there, not only in the code. ## The failure mode: an edge that was never declared Because ordering is derived entirely from declared relationships, a real-world dependency that was never expressed simply does not exist as far as Terraform is concerned. The usual way this happens is a hardcoded identifier: ```hcl resource "aws_instance" "app" { subnet_id = "subnet-0a1b2c3d4e5f67890" # no edge! } ``` On create this is often harmless — the subnet already exists, so nothing races. On destroy it bites: Terraform sees an instance and a subnet with no relationship, starts both deletions concurrently, and the provider returns `DependencyViolation` because the network interface is still attached. The apply half-completes, and you are left cleaning up by hand or re-running until it happens to succeed. The same shape appears with genuinely out-of-band relationships — something outside Terraform attached to a resource Terraform owns — which no reference can express. That is the legitimate case for `depends_on`, or for accepting that the teardown needs a manual step. ## Replacement is a create and a destroy in the same graph When a change forces a resource to be replaced, both operations appear in one walk, and by default the order is destroy-then-create for that resource. `create_before_destroy` inverts it, which also changes the ordering constraints on neighbouring nodes — Terraform requires the inversion to be consistent across the dependency chain, which is why turning it on in one place sometimes surfaces errors elsewhere. The point for this discussion is just that destroy ordering is not only a `terraform destroy` concern; it is live in every apply that replaces something. ## What to say in an interview Lead with the rule — reverse dependency order, same graph, inverted edges — give the VPC and subnet example because it is instantly recognisable, then show depth by naming the two things most people leave out: that state carries the dependency records so removed blocks still order correctly, and that a hardcoded id deletes an edge and turns a clean teardown into a `DependencyViolation`. That combination reads as someone who has actually torn down an environment rather than only built one.