After an incident you fixed production with `terraform apply -target=module.db`. The next untargeted `terraform plan` proposes changes to resources nobody edited. What explains that, and how do you handle the plan?

## Why the diff exists A targeted run reduces Terraform's graph to the addresses you named plus their dependencies. Three consequences follow, and together they account for essentially every surprise in the next full plan. **Dependents were excluded.** Targeting includes what your target depends on, never what depends on it. If the database was replaced or its endpoint changed, the application configuration, the DNS record, the security-group rule and the parameter-store entry that reference it were all outside the run. They still hold the old value in state, so the full plan proposes to update them now. **Refresh was narrowed.** Terraform read real-world attributes only for the objects in the reduced graph. Anything else in the state has not been compared against reality since the last full run — which, during a long incident with people in the console, can be a lot of accumulated drift arriving all at once. **Outputs may be stale.** Root module outputs that depend on untargeted resources are not necessarily updated by a targeted apply — Terraform's own post-run warning says as much. That matters beyond cosmetics: if another configuration reads those outputs through remote state, it has been consuming a stale value since the incident. ## Reading the plan instead of approving it The correct first move is to produce the plan and actually read it, never `-auto-approve`. Sort every proposed change into one of three buckets: 1. **Consequence of the targeted change.** Something references an attribute of the resource you fixed — a new identifier, a new endpoint, a new ARN. These are expected and are the whole point of running the full plan. 2. **Drift made by humans during the incident.** Somebody scaled an instance, opened a security-group rule, or flipped a flag in the console at 3am to stop the bleeding. Terraform is now offering to revert it. This is the dangerous bucket, because reverting a fix that is still load-bearing turns one incident into two. 3. **Configuration merged while you were firefighting.** Changes that arrived on the main branch and have simply never been applied. They are legitimate but they are not yours, and they should not ride along unnoticed in an incident cleanup. Only the first bucket is unambiguously safe to apply immediately. For the second, the decision is per resource: revert it if it was a stopgap, or write it into the configuration if it was the right answer. The third belongs to whoever merged it, applied in the normal flow. ## Sequencing the cleanup ```bash terraform plan -out=cleanup.tfplan # read it, all of it terraform apply cleanup.tfplan # apply exactly what was reviewed terraform plan # must come back empty ``` Saving the plan and applying that file matters here more than usual, because the estate is moving: a plan read at 03:20 and re-derived at 03:40 is not the same plan. The cleanup is finished when an untargeted plan reports no changes. ## What not to do The tempting mistake is another targeted apply — this time on the resources the diff surfaced — because it is smaller and feels safer at 3am. It is not safer; it defers the same reconciliation and adds a new stale slice. Occasionally it is still the right call *while the incident is live*, but then it is another entry in the same debt, not a resolution. Equally wrong is deciding Terraform is being erratic. Terraform is deterministic here: it is proposing exactly the work a deliberately partial run left behind. ## The process fix Treat a targeted apply as a break-glass action with an obligation attached. Record the exact command in the incident channel, note which addresses were targeted, and open a follow-up item to get the untargeted plan back to empty within the working day. Otherwise the debt lands on the next engineer who runs a routine apply and finds a diff nobody can explain — and that person, under time pressure, is far more likely to approve it blind than you are now.