A runbook step reads: "The database backup is initiated by the cron job at 02:00 UTC." A technical writer suggests making it active voice. Which rewrite is correct, and is the change an improvement?
Option A is correct. When the agent is known and relevant, active voice is preferred in procedural documentation. Here, the cron job is a specific, nameable component — knowing it is responsible matters for debugging ("if the backup is missing, check the cron job"). Active voice also eliminates the by-phrase, making the sentence more concise. Option B removes the agent entirely (ergative form) — acceptable for alerts but loses the cron job reference. Option C would be valid if the runbook were about backup monitoring and the cron job were irrelevant background detail. Passive is not wrong here, but active is the better choice given the context.
2 / 5
Which sentence is a case where passive voice is the better choice in technical documentation?
Option B is correct. Passive voice is preferred when the agent is unknown, unimportant, or deliberately omitted. "The config.yaml file is loaded at application startup" describes a system behaviour — the agent (the framework, the runtime) is background infrastructure, not something readers need to track. This is the canonical passive use case in technical documentation: system events, background processes, and state changes where the actor is irrelevant to the reader's task. Options A, C, and D all have clear, relevant agents (engineer, we, user) that should stay in active voice. The rule: omit the agent with passive only when the agent adds no actionable information.
3 / 5
An incident report reads: "Errors were introduced into the production database during the migration." A manager requests a rewrite that identifies responsibility. Which version is correct?
Option B is correct. When accountability needs to be clear — as in post-mortems and incident reports — active voice identifies the causal agent. "The migration introduced errors" names the migration as the direct cause, which is essential for the root-cause analysis section of an incident report. Option A keeps the object ("production database") as subject, still obscuring the agent. Option C improves on the original but uses a clunky by-phrase. Option D ("ended up") is evasive — it sounds accidental and hides causality entirely. In post-mortems, active voice with a named agent is the professional and accountable choice.
4 / 5
A senior engineer comments on this API documentation sentence: "Requests must be authenticated before they can access protected endpoints." Should this be rewritten in active voice?
Option B is correct. This is a good use of passive voice in documentation. The sentence describes an architectural constraint — the requirement that requests must be authenticated. The agent (who authenticates them — the client, the SDK, the user?) varies by integration and is not the point. The passive construction naturally emphasises what must happen ("must be authenticated"), not who does it. Rewriting to "users must authenticate requests" assumes a specific integration pattern. Options C and D both state absolute rules that do not hold — passive and active each have their appropriate uses. The skill is choosing deliberately, not defaulting.
5 / 5
Which paragraph uses active and passive voice most deliberately and effectively for a deployment guide?
Option B is correct. This paragraph uses voice deliberately: the user-facing instruction ("Push to main") uses the imperative, which is the active-voice gold standard for procedural steps. The GitHub Actions steps use active voice with a named agent. The final step ("is then started automatically by systemd") uses passive — correctly, because "systemd" is background infrastructure and "automatically" is the key information, not who does it. Option A uses passive throughout, burying agents unnecessarily. Option C is too casual and loses precision. Option D mixes tenses inconsistently. Option B demonstrates the core principle: choose active when the agent matters, passive when the action or outcome matters.