- Model answer
- Treat it as tampering until proven otherwise. Preserve state before investigating — take a copy of the affected rows and the surrounding chain, and do not run anything that rewrites them. Notify whoever owns incident response, and establish whether the maintenance script had write access to that table, which is the fact that decides between the two hypotheses. Tell the customer that an integrity check has reported a discrepancy, that the cause is under investigation, and give a time for the next update. Do not tell them it is probably nothing.
- Why, and what the wrong answers get wrong
- The colleague's hypothesis is genuinely plausible: a representation mismatch — key ordering, numeric normalisation, timestamp precision, fixed-width padding — produces a
content result identical to real tampering, and maintenance scripts are a realistic cause. It is still the wrong action, for two reasons. The default must be the worse hypothesis when both are consistent with the evidence, and 'probably a false positive' is a sentence you cannot walk back if it turns out to be an intrusion. The productive investigative step is narrow and specific: whether that script could write to that table. Candidates who lead with the false-positive explanation fail the item even where their technical reasoning is correct, because the failure here is one of sequencing and communication rather than of knowledge. - The judgement being assessed
- Whether the candidate can hold a plausible benign explanation and still act on the adverse one, and whether they know that preservation precedes investigation.