An engineer fixed a production outage by changing a resource directly in the cloud console overnight, and your infrastructure code no longer matches. Walk through how you decide what to do about it.

## Triage before remediation The instinct to "just run the tool and let the code win" is what makes this an interview question. Reverting is one valid outcome of three, and picking it without asking why the change exists risks re-creating the outage it fixed. Three questions come first: 1. **What changed, exactly?** Read the diff attribute by attribute, and cross-check the provider's audit log for who made the change and when. The audit trail is the only place the *intent* survives, since the change bypassed pull-request review by definition. 2. **Is production currently depending on it?** A widened timeout that is holding a payment flow together is very different from a debug flag someone forgot to remove. 3. **Is the resource managed at all?** A modified managed resource and a brand-new hand-created resource look similar on a dashboard and have completely different remedies. ## The three honest remediations ### Revert — the code is right, reality is wrong You decide the declared configuration is correct and let the tool converge reality back onto it. This is the default when the manual change was a temporary probe, an experiment, or something that violates policy — an over-permissive network rule, a disabled log destination. The discipline is *how*: do it as its own reviewed, announced change, during hours, with the person who made the manual edit in the loop. A revert is a production change with real blast radius, and some reverts are destructive — if the manual edit touched an immutable attribute, converging back may replace the resource rather than update it. Read the diff before approving. ### Codify — reality is right, the code is stale The incident taught you something true: the instance really did need more memory, the health-check threshold really was too tight. Write it into the repository, open a pull request, get it reviewed, and apply. The apply itself becomes a no-op because reality already matches — which is exactly the point. You have converted an undocumented emergency change into a reviewed, version-controlled decision, and the next disaster-recovery rebuild will now reproduce the working configuration. This is the outcome most teams under-use, because it feels like paperwork after the incident is over. It is the step that keeps the repository trustworthy. ### Adopt — the object exists but the tool has never heard of it If the engineer created a whole new resource by hand, there is no prior declaration to revert to. Writing a declaration and applying it naively creates a *second* object, and deleting the hand-made one to let the tool rebuild it is a self-inflicted outage. The correct move is to adopt it: write the configuration to match what exists, then bring the existing object into the tool's record so it is managed from now on without being recreated. Every mature IaC tool has a mechanism for this, and it is worth naming as the reason the mechanism exists. Adoption is fiddly in practice — you must reconstruct the declaration accurately enough that the first run after adoption reports no changes. Treat "the comparison is clean" as the acceptance criterion. ## The fourth outcome: scoping the attribute out There is a fourth path, applicable when the changing field genuinely belongs to another system rather than to a person: declare the attribute out of scope so your tool stops trying to own it. That is the right answer for autoscaled capacity or a field another controller writes. It is the *wrong* answer to a human console edit, because it removes the only control that would have caught the next one. Reach for it deliberately, never as a way to silence a noisy report. ## The non-choice The outcome to name as the failure mode is doing nothing. The difference stays, everyone forgets, and weeks later an unrelated deploy — a tag change, a new subnet — converges the whole configuration and silently undoes the fix. The person deploying had no reason to look at that resource, so the outage returns with no obvious cause. "Drift is remediated by the next apply whether you decided or not" is the sentence that shows you have lived it. ## Closing the loop A senior answer does not stop at the resource. Two follow-through items belong in the incident review: was console write access necessary, or could the fix have gone through the pipeline with an expedited approval; and if console access genuinely was necessary, is there a break-glass path that expires and automatically raises a ticket to codify the change afterwards. Drift is a symptom; recurring drift on the same team is a process defect.