5 exercises — using must, can't, must have, should have, and can for epistemic deduction in debugging sessions, code reviews, and incident post-mortems.
0 / 5 completed
1 / 5
During a debugging session, a developer says: "The memory usage spiked at exactly 3 AM every night — it _____ be the scheduled batch job." Which modal expresses a confident logical deduction?
Must expresses near-certain logical deduction based on evidence. When you say "It must be the batch job," you are reasoning from strong evidence (the timing pattern) to a conclusion. This is epistemic modality — using modal verbs to express degrees of certainty rather than permission or obligation. Might and could express weak possibility — appropriate when the evidence is thin. Should expresses expectation or prediction ("It should work"), not deduction from evidence. In debugging and incident analysis, choosing the right modal signals exactly how confident you are in your conclusion.
2 / 5
A code reviewer comments: "The test suite passed, but the production error persists — the bug _____ be in the test environment configuration, not the application code." Which modal is correct?
Cannot (or can't) is used for negative logical deduction — concluding that something is impossible based on evidence. The reasoning: if the test suite passed but production still fails, the bug logically cannot be in the application code alone. Must not is used for prohibition or strong advice: "You must not commit secrets." It is NOT used for negative deduction. Should not expresses expectation: "This should not happen."May not expresses weak possibility: "It may not be the cause" — this is a possibility, not a deduction. The deduction pair is: positive = must, negative = cannot / can't.
3 / 5
An incident report reads: "The database was unresponsive for 45 minutes. The on-call engineer _____ missed the PagerDuty alert." Which modal best expresses a past deduction?
Must have + past participle is the structure for deduction about a past event. "The engineer must have missed the alert" means: based on the evidence (45-minute outage with no response), I conclude this almost certainly happened. Should have expresses past obligation or criticism: "The engineer should have responded faster" (they had a duty to, but did not). Would have expresses a hypothetical result in a conditional: "If they had seen the alert, they would have responded."Could have expresses past ability or possibility: "The engineer could have missed it" (it is a possibility, less certain than "must have"). In post-mortems, modal perfect forms are essential.
4 / 5
A DevOps engineer writes in an SRE postmortem: "The deployment pipeline _____ been configured incorrectly — three separate services failed in the same sequence." Which form is correct?
Must have been configured is the correct past deduction form. The pattern is: modal + have + past participle. The evidence (three services failing in the same sequence) strongly supports a single root cause — a misconfiguration. This high-confidence deduction requires "must have." Might is a present-tense possibility modal and cannot directly express past deduction in this context without "have" ("might have been" would be possible but weaker). Should have implies the configuration ought to have been done correctly — a criticism, not a deduction. Could alone is present tense ability, not a past deduction.
5 / 5
A developer is uncertain about a race condition: "Two threads accessing the same variable simultaneously _____ cause unpredictable behaviour, depending on the scheduler." Which modal is most appropriate?
Can is the correct modal for expressing theoretical possibility or capability — something that has the potential to happen under certain conditions. "Two threads can cause unpredictable behaviour" means: this is a known possible outcome, not a guaranteed one. The phrase "depending on the scheduler" confirms it is conditional. Must would imply it always happens with certainty. Will would state it as a definite outcome every time. Shall is archaic in technical English except in formal contracts and is inappropriate here. In technical documentation about race conditions, concurrency bugs, and edge cases, can is the go-to modal for expressing potential without overstating certainty.