5 exercises — must/should/could/might/may for RFC-style requirements, API docs, code review comments, and architecture proposals.
0 / 5 completed
1 / 5
An API specification states a security requirement. Choose the correct modal: "All API requests _____ include a valid Bearer token in the Authorization header."
"Must" expresses an absolute mandatory requirement with no exceptions permitted. In RFC 2119 terminology (used by IETF standards and most API specs), MUST means the requirement is unconditional. "Should" allows exceptions in specific circumstances; "might" and "could" are far too weak for a security requirement. When writing API specs, use MUST/MUST NOT for non-negotiable security constraints.
2 / 5
A code review comment reads: "This function _____ validate input before passing it to the database layer." What modal best expresses a strong recommendation (not a hard rule)?
"Should" expresses a strong recommendation while acknowledging that specific circumstances might justify an exception. In code reviews, "should" signals a real concern without claiming the current code is definitively wrong. "Must" would be appropriate if this were a security-critical requirement with no exceptions. RFC 2119: "SHOULD means there may exist valid reasons in particular circumstances to ignore this requirement."
3 / 5
An incident retrospective identifies a potential contributing factor. Which sentence uses the correct modal?
"Might be caused by" expresses a hypothesis with low certainty — appropriate when a root cause has not been confirmed. Post-mortems use this hedging modal during the investigation phase. "Must" implies near-certainty from logical deduction. "Should" implies expectation, which is semantically wrong here. "Will" incorrectly implies future tense.
4 / 5
A deployment guide recommends a caching duration. Choose the best sentence:
"Should" establishes the recommended default (strong advice, implementable without exceptions for most cases). "May" then permits a specific extension under a defined condition — this is RFC 2119-compliant writing. Option A is too rigid for a caching recommendation. Option B is too tentative and informal. Option D is over-hedged to the point of uselessness.
5 / 5
An infrastructure team is discussing scaling options. Choose the sentence that uses modals most precisely for a technical proposal:
Three modals used precisely: "could" (capability — horizontal scaling is able to handle the load), "should" (strong recommendation — evaluating connection limits is important), "might" (low certainty — vertical scaling is possibly sufficient but not certain). This layered modal usage signals engineering rigour. Options A and D are too vague or overconfident; B uses "must" and "will" inappropriately for a proposal that should acknowledge uncertainty.