5 exercises — choose the correct passive construction for technical writing contexts including changelogs, postmortems, API specifications, and architecture decision records.
0 / 5 completed
1 / 5
Choose the most appropriate passive construction for a technical release note.
Release notes, changelogs, and API documentation typically use the passive voice to focus on what was done rather than who did it. "The critical authentication bug has been fixed" is the standard passive construction. The present perfect passive ("has been fixed") is preferred over simple past passive ("was fixed") in changelogs because it connects the past action to the current state. Option A is grammatically fine but informal/active — acceptable in some teams' changelog styles. Options C and D have wrong agents or tense.
2 / 5
Passive voice is most appropriate in which of these technical writing contexts?
Postmortem reports and incident analysis documents typically favour passive constructions to describe system events objectively, without assigning individual blame: "A misconfiguration was deployed," "The alert was triggered at 14:03," "The database connection pool was exhausted." This is both a stylistic convention (blameless culture) and a grammatical choice. Tutorials and quickstarts (options A and C) use active imperative ("Run npm install," "Open the file"). Informal communication (option D) uses plain active voice.
3 / 5
The configuration file ___ by the provisioning script each time the service ___.
The configuration file is the object of generation (something generates it), so it takes the passive: "is generated." The service is the subject that starts (it starts itself, or it is designed to start), so the active "starts" is correct here — the service performs the action. Option C uses passive for both, which is awkward for the intransitive "start." Option D uses active for both — grammatically acceptable but less precise for documentation describing automatic provisioning.
4 / 5
Select the sentence that correctly uses a passive with a modal verb in an API specification.
A passive with a modal verb follows the pattern: modal + be + past participle. So: "must be included" (not "must include," which is active, or "must including," which is grammatically invalid). In API documentation and RFC-style specifications, modal passive constructions are standard: "MUST be included," "SHOULD be validated," "MAY be omitted," "SHALL NOT be cached." These express obligation or permission about the state of data or behaviour of systems.
5 / 5
Which sentence best demonstrates the appropriate use of passive voice in an ADR (Architecture Decision Record)?
ADRs (Architecture Decision Records) use formal passive constructions to present decisions as reasoned outcomes rather than personal preferences: "PostgreSQL was selected because..." This passive framing focuses on the rationale rather than the decision-makers, which is appropriate for documentation that will be read by future engineers. Option A is acceptable but informal. Option C is grammatically fine but vague. Option D uses continuous passive ("is being selected"), which implies an ongoing process, not a documented decision.