Parallel Structure in Technical Lists

Option D is correct — both B and C are parallel. Option B uses third-person singular present tense verbs throughout ("Authenticates, Rate-limits, Logs, Manages") — a common pattern for feature lists that describe what a tool does. Option C uses noun phrases throughout ("User authentication, Rate limiting, Automatic error logging, Cache management") — a common pattern for bullet-point feature summaries. Option A breaks parallel structure by mixing gerunds ("Authenticating", "Rate limiting"), an infinitive ("To log"), and a noun ("Cache management"). The rule: every item in a list must belong to the same grammatical category. Never mix verb phrases, noun phrases, and infinitives in the same list.

Option B is the correct parallel structure. All four items use the same pattern: imperative verb + object (Run, Build, Push, Deploy). This is the standard structure for checklists, runbooks, and step-by-step guides — imperative verbs make each item an action the reader should perform. Option A mixes a complex clause ("Run all tests and they must pass"), an imperative ("Build"), a gerund ("Pushing"), and another imperative ("Deploy") — four different structures. Option C uses passive voice inconsistently and mixes passive with gerunds. Option D mixes gerunds ("Running", "Deploying") with noun phrases ("Image build") and an imperative ("Push"). Checklist rule: imperative verb + direct object, every item, every time.

Option B is the best for prose documentation — every item is a noun phrase starting with an article ("A", "An", "The", "An"): consistent grammatical category throughout. Option D is also parallel (all key-value pairs), and is actually the preferred format in API reference documentation — it is more compact and machine-readable. Both B and D are correct for their contexts; B for prose-style API docs, D for reference tables. Option A is broken: "A JSON object" (noun phrase), "It includes" (clause), "Status" (bare noun), "Errors are returned" (passive clause) — four different patterns. Option C mixes passive clauses, a clause, a bare noun, and a reduced clause. Key rule: choose noun phrases or key-value pairs for API returns — never mix in clauses.

Option D is correct — both B and C are parallel. Option B uses past tense verb phrases ("Added, Refactored, Updated, Fixed") — the standard for PR descriptions, which document what was done. Option C uses gerund noun phrases ("Null check addition, Config loader refactoring…") — concise noun phrases are used in commit messages and changelogs. Option A breaks parallel structure: "Added" (past tense), "Refactored" (past tense), "Tests have been updated" (passive clause — not a bullet phrase), "Fix" (present tense imperative). The rule for PR descriptions: use past tense verbs throughout ("Added", "Fixed", "Updated", "Removed") — they document completed actions. Changelog convention: noun phrases or past tense, consistently one or the other.

Option D is correct — both B and C use consistent grammatical patterns throughout. Option B uses third-person singular present verbs ("Validates, Authenticates, Issues, Rate-limits") — the standard for service capability descriptions in architecture documents. Option C uses gerund noun phrases ("JWT token validation, LDAP-based authentication…") after "is responsible for" — also a strong, consistent pattern. Both are correct for different contexts: B is better inline in prose; C is better after a setup phrase ("is responsible for"). Option A mixes verb ("Validates"), passive clause ("The user is authenticated"), gerund ("Issuing"), and noun ("Rate limiting") — four different patterns. Whenever you write a list describing what a system does, commit to one grammatical pattern before you start.