A post-apply policy scan flags an end-of-support database engine in production — how do you choose what the finding triggers?

## Start with what is and is not possible A finding raised after the apply cannot be refused. There is no pending change, no pipeline waiting, nobody blocked. Whatever the rule says, the resource is running and will keep running until a human does something. That reframes the question: you are not choosing an enforcement level, you are choosing which human workflow to start and how to make sure it finishes. ## The four things a finding can trigger **Annotate — record it as accepted.** Legitimate, and often correct: an end-of-support engine on a system scheduled for decommission next quarter is not worth a risky upgrade. But an annotation without an owner, a reason and an **expiry date** does not accept a risk, it deletes the signal. The next person to read the scan sees a clean result and has no way to tell an accepted risk from a forgotten one. Expiry is the whole difference between an accepted risk and a hole. **Ticket — schedule the fix.** For a major engine upgrade this is usually the honest answer. The work is not a one-line edit: it may need a maintenance window, an application compatibility check, and in some cases the resource is replaced rather than modified. A ticket with a named owner and a date is a real response. A ticket with neither is a way of moving the finding to a queue where it will not be looked at. **Revert.** Ask what you would be reverting to. Revert fits when a recent, identifiable change introduced the violation and undoing it restores a known-good state. It does not fit here: the engine version went end-of-support while nobody was touching the resource, so there is no earlier state that satisfies the rule. That is a forward fix, not a revert. Note also that a revert is itself a change — it goes through the same pipeline, produces its own plan and passes the same gates. It is not a special escape hatch. **Fix and re-run.** The actual remediation, whichever form it takes, belongs in the code. Editing the resource by hand in the provider console makes the finding go away on the next scan while leaving the declaration saying the old thing, so the next apply from that codebase can undo your fix. Change the declaration, apply it, then re-run the rule. ## How you decide between them Three questions, in order: 1. **What is the actual risk, and what is the cost of the fix?** An end-of-support engine means no more security patches — a slow-burning risk rather than an active compromise. That justifies a scheduled upgrade with a date, not an emergency window at 2am. Be honest about this in an interview: a candidate who wants to page someone for every post-apply finding has not operated anything. 2. **Who owns it?** The scan has no requester — it ran on a schedule, not inside anybody's change — so the owner has to come from resource metadata: ownership tags, or a mapping from the resource address back to the module and repository that declares it. If nothing identifies an owner, that is the first thing to fix; unrouted findings rot in a shared queue. 3. **What closes it?** Only a re-run of the rule returning nothing for that resource. A ticket transitions to Done when a human says so; the rule re-runs against the world. Wire the scan so that closure is evidenced by the run, and the ticket references it. ## Failure modes worth naming - **Blanket suppression** of a rule that produced too many findings on its first run over the estate. That is a real pressure, and the answer is triage with expiries rather than switching the rule off. - **Auto-remediation without judgment.** Automatically changing a live production resource because a rule said so is a change with a blast radius and no review; for an engine upgrade it can mean an unplanned restart. - **Console fixes.** Fast, invisible, and they leave the code and reality disagreeing. - **Closing on the ticket.** The most common one. The ticket says fixed; nobody re-ran the rule; the resource is still wrong. ## The shape of a good answer Say that the finding starts a workflow rather than blocks anything; name the four possible triggers and pick the one this scenario deserves with a reason; insist on an owner and a date or an expiry on whichever you pick; route it using resource metadata because the scan has no author; and define closure as the rule re-running clean, not as a ticket status.