Technical Writing Practice Exam

Question 1 Technical Writing

Why should technical writing be revised aggressively?

A design doc explains a proposed technical change: the problem, options considered, the chosen approach, trade-offs, risks, and rollout plan. It means each paragraph advances a single claim or step, so a reader who skips a paragraph still does not miss a separate point buried inside it. First drafts often mirror the author’s thinking process rather than the reader’s path to understanding. Plain language uses familiar words, direct sentences, and clear structure without sacrificing accuracy.

Question 2 Technical Writing

What is a "complete, runnable example"?

Clear documents answer the reader’s real question instead of showcasing everything the author knows. It is a sample that runs as-is in a fresh environment (with documented prerequisites), demonstrating one concept end-to-end without ellipses or "...". It is a public style guide focused on plain language, accessibility, and a warm, direct voice, used across Microsoft Learn and adopted by other teams. An FAQ answers anticipated, generic questions. Troubleshooting diagnoses specific symptoms with concrete next steps; it is procedural, not informational.

Question 3 Technical Writing

What is a durable technical-writing habit?

Numbering helps readers follow sequence correctly and reduces skipped actions. Readers often arrive at docs because something went wrong, so clear error guidance saves time. Write for the reader’s task, test your examples, and cut anything that does not improve understanding. A "WHY" comment explains the reasoning behind a non-obvious line ("// Use 2 retries, not 3: 3 fails the SLO under packet loss"). It is the most valuable kind of code comment.

Question 4 Technical Writing

What is a "flowchart" used for?

A stub is a placeholder page that exists so a link does not 404, but contains only a heading and a TODO. Stubs are useful in a doc plan, harmful if they ship unflagged. A flowchart shows decision branches in a process. It is useful for runbooks and troubleshooting where the next step depends on the answer to a question. A diagram is a visual model of relationships or flow (sequence, architecture, ER). It is best when relationships are the point, not the individual facts. Information should live in exactly one place. Other pages link to it, never copy-paste it, so updates propagate automatically and never contradict each other.

Question 5 Technical Writing

What is the role of an "Overview" section?

A landing page is the entry point for a product area: it explains what the area is for, lists the most common tasks, and links to tutorials and reference. A feature flag is a runtime switch that enables a feature for some users. Docs should describe the flag, its default, and which audiences currently see the feature. An overview sets context: what the feature is, what problem it solves, who should use it, and the minimum the reader needs to know before going deeper. Most readers scan before they read deeply, especially when they are troubleshooting under time pressure.

Question 6 Technical Writing

What is "ASCII art" and when is it acceptable in docs?

ASCII art is text-drawn diagrams. It is acceptable in code comments, READMEs, and terminal contexts where rendered images are not an option, and when simplicity is the goal. A smoke test is running the example exactly as written, in a fresh environment, and confirming the documented output appears. Examples that fail the smoke test should not ship. Ambiguous references make technical steps harder to follow because readers are unsure what each instruction refers to. Use a colon to introduce a list, a code example, or a definition that directly elaborates the preceding clause ("Use these flags: --verbose, --dry-run").

Question 7 Technical Writing

How can technical writing improve team alignment?

An FAQ answers anticipated, generic questions. Troubleshooting diagnoses specific symptoms with concrete next steps; it is procedural, not informational. Shared docs make decisions, process, and system behavior easier to reference consistently across the team. "Click here" discards the information scent of the link. Better link text ("View the auth tokens reference") tells scanners where the link goes before they click. Tone is the style and level of formality that helps documentation feel clear, credible, and respectful.

Question 8 Technical Writing

What is a "doc lint" tool?

It lists exact software versions, accounts, permissions, or knowledge the reader must have before the rest of the doc will work, preventing wasted effort. Plain language uses familiar words, direct sentences, and clear structure without sacrificing accuracy. ASCII art is text-drawn diagrams. It is acceptable in code comments, READMEs, and terminal contexts where rendered images are not an option, and when simplicity is the goal. A doc lint tool (markdownlint, Vale, alex) automatically checks prose for style issues, banned words, broken links, and accessibility problems in CI.

Question 9 Technical Writing

What is a strong technical-writing principle?

A "WHY" comment explains the reasoning behind a non-obvious line ("// Use 2 retries, not 3: 3 fails the SLO under packet loss"). It is the most valuable kind of code comment. For most features, ship a short overview, a quickstart, and a reference for every public option. Other doc types come later, once support feedback shows gaps. A doc lint tool (markdownlint, Vale, alex) automatically checks prose for style issues, banned words, broken links, and accessibility problems in CI. Make the next right action obvious and the surrounding complexity easier to navigate.

Question 10 Technical Writing

Why should jargon be controlled carefully?

It is the shortest example that still demonstrates the documented behavior, with no unrelated features, no decorative config, and no copy-paste noise. Expert terms can be useful, but unnecessary jargon increases cognitive load and excludes readers. A code block presents runnable or copy-pasteable commands, configuration, or output with preserved whitespace, syntax, and no prose wrapping. Shared docs make decisions, process, and system behavior easier to reference consistently across the team.

Question 11 Technical Writing

What is the "Google Developer Documentation Style Guide"?

It lets a reader jump directly to the section that matches their task instead of scrolling, especially on mobile where scroll is expensive. Short paragraphs are easier to scan, especially when readers are under time pressure. It is a widely adopted public style guide covering word choice, formatting, voice, and inclusive language for technical content. Many teams adopt it as a baseline. It is the assumption that simpler always means better. Important nuances, constraints, and edge cases must be preserved; clarity is not the same as oversimplification.

Question 12 Technical Writing

What is the audience for an RFC versus a design doc?

Placeholder code is a sample using names like "my-host" or "TODO" that the reader must replace. It is dangerous when the placeholders are not flagged and the reader pastes literally. A Warning flags actions that can cause data loss, security holes, or irreversible damage; a Note flags useful context, tips, or clarifications that are helpful but not dangerous. Alt text should be concise (a sentence or less), describe what the image conveys rather than how it looks, and stay empty for purely decorative images. An RFC is written for a broad engineering audience to debate direction; a design doc is more concrete and aimed at reviewers who will approve implementation.

Question 13 Technical Writing

Why is it valuable to record rejected alternatives in an ADR?

A feature flag is a runtime switch that enables a feature for some users. Docs should describe the flag, its default, and which audiences currently see the feature. A known issue section lists active bugs or limitations the user should be aware of, with workarounds, the affected versions, and a link to tracking. Cognitive load is the mental effort a reader must spend to understand a passage. Docs minimize it with structure, examples, and consistent terminology. Rejected alternatives prevent the same debate from restarting every time a new joiner questions the choice, and they preserve the reasoning when context is lost.

Question 14 Technical Writing

What is technical writing?

Technical writing is the craft of explaining complex information clearly so readers can understand and act on it. A table aligns parallel facts across rows (e.g. parameter, type, default, description) so readers can scan a single column instead of reading prose. A breadcrumb shows the path from the docs home to the current page (Docs > API > Auth > Tokens), helping readers back up without losing context. Clear documents answer the reader’s real question instead of showcasing everything the author knows.

Question 15 Technical Writing

What is a "user journey" in docs?

Problem statement, goals and non-goals, proposed solution, alternatives considered, trade-offs, risks, rollout, and open questions. Make the next right action obvious and the surrounding complexity easier to navigate. The audience is the specific reader or user the document is trying to help, persuade, or guide. A user journey is the sequence of docs a typical reader traverses from "I just heard about this" to "I have a working advanced setup." Docs should make each step land.

Question 16 Technical Writing

What is "information architecture" (IA) in a docs site?

IA is the structure of categories, sections, and pages that determines how readers find content. Good IA matches the reader's tasks, not the org chart. Active voice puts the reader as the subject ("You can enable debug mode"); passive voice hides the actor ("Debug mode can be enabled"). Active is shorter and clearer in steps. ASCII art is text-drawn diagrams. It is acceptable in code comments, READMEs, and terminal contexts where rendered images are not an option, and when simplicity is the goal. Code comments explain non-obvious behavior to future readers of the source. Docs explain the same system to users who never read the source. Both are needed.

Question 17 Technical Writing

Why is technical writing valuable?

Clear documents answer the reader’s real question instead of showcasing everything the author knows. "TL;DR" ("Too Long; Didn't Read") is a short summary block at the top of a long page that gives the busy reader the key takeaway in one or two sentences. It reduces confusion, improves adoption, and helps teams scale knowledge beyond live conversations. A smoke test is running the example exactly as written, in a fresh environment, and confirming the documented output appears. Examples that fail the smoke test should not ship.

Question 18 Technical Writing

What is a "runbook" in technical writing?

A runbook is an operational document giving on-call responders exact steps to diagnose, mitigate, and resolve a specific production issue. A style guide records team-specific decisions (capitalization, date format, voice, terminology) so writers do not re-debate them per page and the site feels uniform. Voice is the personality the document projects: direct, helpful, neutral, sometimes warm. A consistent voice builds trust across pages. It is a widely adopted public style guide covering word choice, formatting, voice, and inclusive language for technical content. Many teams adopt it as a baseline.

Question 19 Technical Writing

Why are postmortems written blamelessly?

It reduces confusion, improves adoption, and helps teams scale knowledge beyond live conversations. Blameless framing focuses on systems, signals, and decisions under uncertainty, which encourages honest reporting and durable fixes over scapegoating. A stub is a placeholder page that exists so a link does not 404, but contains only a heading and a TODO. Stubs are useful in a doc plan, harmful if they ship unflagged. Progressive disclosure reveals the simplest useful guidance first and exposes deeper detail only when needed.

Question 20 Technical Writing

What is "voice" in technical writing?

Voice is the personality the document projects: direct, helpful, neutral, sometimes warm. A consistent voice builds trust across pages. When terms change unpredictably, readers waste energy deciding whether two labels mean the same thing. Versioning is the practice of maintaining a separate copy of the docs for each major release so users on older versions still see accurate guidance. Alt text describes the image content for screen readers and for readers whose browser cannot load images. It must convey the same information as the image itself.

Question 21 Technical Writing

Why must deprecation notices include a migration path?

Alt text should be concise (a sentence or less), describe what the image conveys rather than how it looks, and stay empty for purely decorative images. Telling users something is going away without telling them how to move creates churn, support tickets, and the perception of forced upgrades. A tutorial guides the reader through learning by doing, usually in a beginner-friendly sequence. Task success is the rate at which a reader with a goal completes it using the doc alone. The single most important metric for procedural content.

Question 22 Technical Writing

What is the "F-shape" reading pattern?

A design doc explains a proposed technical change: the problem, options considered, the chosen approach, trade-offs, risks, and rollout plan. A known issue section lists active bugs or limitations the user should be aware of, with workarounds, the affected versions, and a link to tracking. It describes how web readers scan: horizontally across the top, then a shorter horizontal sweep further down. Docs use headings, lists, and bold to feed this pattern. A technical reviewer is an engineer or subject-matter expert who verifies that the doc's claims about the system are correct, and that examples actually run.

Question 23 Technical Writing

What is a "feedback widget" on a docs page?

A stub is a placeholder page that exists so a link does not 404, but contains only a heading and a TODO. Stubs are useful in a doc plan, harmful if they ship unflagged. A redirect sends a reader from an old or renamed URL to the new canonical page, preserving SEO and external links while content moves. Docs as code stores documentation in the same repository as the product, in plain text (Markdown, AsciiDoc), reviewed via pull requests, and built by a static site generator. It is a small "Was this helpful?" prompt that lets readers flag bad pages. Aggregated feedback is a strong signal for what to rewrite first.

Question 24 Technical Writing

What is a "release note" in technical writing?

Anchor text is the visible words of a link. Effective anchor text is descriptive of the destination ("OAuth setup guide") and never "here", "this", or a raw URL. Fresh readers catch assumptions and ambiguity that the writer no longer notices. A README answers five questions fast: what this is, who it is for, how to install, how to run, and where to learn more. Anything else belongs in linked docs. A release note is a short, dated entry per version that calls out user-visible changes, with links to the relevant docs and to the changelog.

Question 25 Technical Writing

Why should changelogs and docs connect?

Users need to know not just that something changed, but how the change affects the way they work. Code comments explain non-obvious behavior to future readers of the source. Docs explain the same system to users who never read the source. Both are needed. Rejected alternatives prevent the same debate from restarting every time a new joiner questions the choice, and they preserve the reasoning when context is lost. Readers often arrive at docs because something went wrong, so clear error guidance saves time.

Question 26 Technical Writing

What is a "README" supposed to do?

Start with a Tutorial or Quickstart, then Concepts, then How-to guides, then Reference. This matches the journey of a learning reader. Inclusive language avoids alienating or stereotyping readers, widens the audience, and reflects the team's values; specific words ("allowlist", "primary/replica") are usually easy swaps. A README answers five questions fast: what this is, who it is for, how to install, how to run, and where to learn more. Anything else belongs in linked docs. Broken examples erode trust quickly and make readers doubt the rest of the document.

Question 27 Technical Writing

What is progressive disclosure in documentation?

It is an automated crawl that follows every link in the docs and reports any that 404 or redirect unexpectedly, often run on every pull request. Readers trust and adopt examples more readily when they resemble actual workflows instead of toy cases. A reference document provides precise facts such as options, parameters, fields, or behaviors for lookup. Progressive disclosure reveals the simplest useful guidance first and exposes deeper detail only when needed.

Question 28 Technical Writing

What is a "table" in technical documentation?

Use simple present for describing current behavior ("The API returns 200 on success") and simple past for reporting completed actions. Avoid future tense for documented behavior. A table aligns parallel facts across rows (e.g. parameter, type, default, description) so readers can scan a single column instead of reading prose. Versioning is the practice of maintaining a separate copy of the docs for each major release so users on older versions still see accurate guidance. A smoke test is running the example exactly as written, in a fresh environment, and confirming the documented output appears. Examples that fail the smoke test should not ship.

Question 29 Technical Writing

What is a maintenance-friendly writing habit?

A README answers five questions fast: what this is, who it is for, how to install, how to run, and where to learn more. Anything else belongs in linked docs. IA is the structure of categories, sections, and pages that determines how readers find content. Good IA matches the reader's tasks, not the org chart. Write for the reader’s task, test your examples, and cut anything that does not improve understanding. Prefer clear structure and reusable patterns so updates can be made quickly when the product changes.

Question 30 Technical Writing

Who is the audience in technical writing?

Information scent is the set of cues that help readers predict where useful content is located. The audience is the specific reader or user the document is trying to help, persuade, or guide. A breadcrumb shows the path from the docs home to the current page (Docs > API > Auth > Tokens), helping readers back up without losing context. IA is the structure of categories, sections, and pages that determines how readers find content. Good IA matches the reader's tasks, not the org chart.

Question 31 Technical Writing

What is the "mobile-first" consideration for docs?

On mobile, long paragraphs, wide tables, and side-by-side code blocks break. Write for narrow screens first; wide layouts are a progressive enhancement. ASCII art is text-drawn diagrams. It is acceptable in code comments, READMEs, and terminal contexts where rendered images are not an option, and when simplicity is the goal. The golden path is the shortest, most-supported route through the product to a useful result. Docs should make this path obvious and well-paved. It reduces confusion, improves adoption, and helps teams scale knowledge beyond live conversations.

Question 32 Technical Writing

What is the typical order of doc types in a product docs site?

The golden path is the shortest, most-supported route through the product to a useful result. Docs should make this path obvious and well-paved. It is a small "Was this helpful?" prompt that lets readers flag bad pages. Aggregated feedback is a strong signal for what to rewrite first. Start with a Tutorial or Quickstart, then Concepts, then How-to guides, then Reference. This matches the journey of a learning reader. A topic sentence is the first sentence of a paragraph that previews the paragraph's single main idea, so a scanner can decide whether to read on.

Question 33 Technical Writing

What is an "error code" reference?

A feature flag is a runtime switch that enables a feature for some users. Docs should describe the flag, its default, and which audiences currently see the feature. An FAQ answers anticipated, generic questions. Troubleshooting diagnoses specific symptoms with concrete next steps; it is procedural, not informational. A "WHY" comment explains the reasoning behind a non-obvious line ("// Use 2 retries, not 3: 3 fails the SLO under packet loss"). It is the most valuable kind of code comment. An error code reference lists every error the system can return, with a unique identifier, a plain-language meaning, common causes, and remediation steps.

Question 34 Technical Writing

Why are examples useful in technical writing?

Some readers always search instead of browsing navigation. Docs must work via search: titles should match the words readers actually type (error messages, parameter names). An RFC is written for a broad engineering audience to debate direction; a design doc is more concrete and aimed at reviewers who will approve implementation. SemVer uses MAJOR.MINOR.PATCH: breaking, feature, and fix. Doc sites typically pin references to a MAJOR version, while guides target the latest minor. Examples turn abstractions into concrete cases that readers can copy, compare, or adapt.

Question 35 Technical Writing

Why should examples mirror real usage?

Readers trust and adopt examples more readily when they resemble actual workflows instead of toy cases. A code block presents runnable or copy-pasteable commands, configuration, or output with preserved whitespace, syntax, and no prose wrapping. Prefer clear structure and reusable patterns so updates can be made quickly when the product changes. Imperative mood ("Click Save", "Run the script") puts the action on the reader without an ambiguous subject, making each step short, parallel, and easy to translate.

Question 36 Technical Writing

What is a "How-to" guide versus a "Tutorial"?

Use prose when the relationship between facts is sequential or causal, when there are only one or two rows, or when the table would force a single cell to be a paragraph. Versioned with the product, reviewed by engineers, branched per release, searchable as text, and CI-checkable for broken links and lint rules. What does this reader need to know, do, or decide immediately after reading this section? A How-to is a recipe for a specific goal aimed at an informed reader; a Tutorial is a guided learning experience aimed at someone still building the mental model.

Question 37 Technical Writing

Why should short paragraphs be favored in docs?

Short paragraphs are easier to scan, especially when readers are under time pressure. It is a widely adopted public style guide covering word choice, formatting, voice, and inclusive language for technical content. Many teams adopt it as a baseline. A deprecation notice tells users a feature will be removed, states the removal version, explains the migration path, and links to the replacement. It describes how web readers scan: horizontally across the top, then a shorter horizontal sweep further down. Docs use headings, lists, and bold to feed this pattern.

Question 38 Technical Writing

Why should imperative mood be used in procedural steps?

Procedural writing gives readers step-by-step instructions to complete a task successfully. Clear technical writing is specific, structured, concise, and easy to scan. Imperative mood ("Click Save", "Run the script") puts the action on the reader without an ambiguous subject, making each step short, parallel, and easy to translate. On mobile, long paragraphs, wide tables, and side-by-side code blocks break. Write for narrow screens first; wide layouts are a progressive enhancement.

Question 39 Technical Writing

Why is the "two-level" navigation pattern common in docs sites?

Versioning is the practice of maintaining a separate copy of the docs for each major release so users on older versions still see accurate guidance. Shared docs make decisions, process, and system behavior easier to reference consistently across the team. A two-level navigation (sidebar of sections, in-page TOC of subsections) supports both the reader scanning a category and the reader drilled into a specific page. A stub is a placeholder page that exists so a link does not 404, but contains only a heading and a TODO. Stubs are useful in a doc plan, harmful if they ship unflagged.

Question 40 Technical Writing

What is a "smoke test" for an example?

API documentation is the human- and machine-readable description of an API: endpoints, request and response shapes, error codes, auth, rate limits, and examples. A smoke test is running the example exactly as written, in a fresh environment, and confirming the documented output appears. Examples that fail the smoke test should not ship. Write the shortest path to correct action, then support it with just enough context to build confidence. Task success is the rate at which a reader with a goal completes it using the doc alone. The single most important metric for procedural content.

Question 41 Technical Writing

What is a "code block" used for in documentation?

The audience is the specific reader or user the document is trying to help, persuade, or guide. A code block presents runnable or copy-pasteable commands, configuration, or output with preserved whitespace, syntax, and no prose wrapping. Conceptual writing explains how something works or why it matters before asking the reader to act. Ordering the most important and most-frequently-used fields first helps readers find the answer faster, even if the underlying schema is alphabetical.

Question 42 Technical Writing

What is the "WHY" comment pattern?

Lead with the conclusion or main action of the paragraph, then add the conditions, edge cases, and background, so scanners get the point in the first sentence. A "WHY" comment explains the reasoning behind a non-obvious line ("// Use 2 retries, not 3: 3 fails the SLO under packet loss"). It is the most valuable kind of code comment. It is the tendency, once an author understands a topic, to forget which parts are hard, and to skip the steps and definitions a beginner actually needs. Cognitive load is the mental effort a reader must spend to understand a passage. Docs minimize it with structure, examples, and consistent terminology.

Question 43 Technical Writing

What is the "404 page" pattern in technical sites?

Vale is a syntax-aware prose linter that runs locally and in CI. Teams ship custom rule sets to enforce their style guide, including domain terminology. An FAQ answers anticipated, generic questions. Troubleshooting diagnoses specific symptoms with concrete next steps; it is procedural, not informational. A 404 page acknowledges the missing content, suggests where the reader might go next, and offers a search box instead of a dead end. A glossary defines domain terms in one place. It pays off in any product with a heavy domain (security, finance, ML) and reduces inline definitions.

Question 44 Technical Writing

What is tone in technical writing?

Tone is the style and level of formality that helps documentation feel clear, credible, and respectful. A table aligns parallel facts across rows (e.g. parameter, type, default, description) so readers can scan a single column instead of reading prose. Readers trust and adopt examples more readily when they resemble actual workflows instead of toy cases. Edge case documentation covers non-default inputs, error conditions, limits, and behaviors at boundaries. It is usually in reference or troubleshooting, not in tutorials.

Question 45 Technical Writing

Why should outputs be shown for example commands?

A deprecation notice tells users a feature will be removed, states the removal version, explains the migration path, and links to the replacement. A reader who copies a snippet and runs it should see the documented result. Trivial edits (placeholder names, missing flags) break trust quickly. Most readers scan before they read deeply, especially when they are troubleshooting under time pressure. Showing expected output lets the reader verify their own run, diagnose typos, and trust that the documented behavior matches reality.

Question 46 Technical Writing

What is the "single source of truth" principle for docs?

Information should live in exactly one place. Other pages link to it, never copy-paste it, so updates propagate automatically and never contradict each other. Inclusive language avoids alienating or stereotyping readers, widens the audience, and reflects the team's values; specific words ("allowlist", "primary/replica") are usually easy swaps. A feature flag is a runtime switch that enables a feature for some users. Docs should describe the flag, its default, and which audiences currently see the feature. A known issue section lists active bugs or limitations the user should be aware of, with workarounds, the affected versions, and a link to tracking.

Question 47 Technical Writing

Why is the order of fields in an API reference important?

A docs review is a structured pass that checks accuracy (does it match the product?), completeness (are edge cases covered?), and clarity (would a new reader get it?). Engineers, writers, and ideally a fresh reader all contribute. Ordering the most important and most-frequently-used fields first helps readers find the answer faster, even if the underlying schema is alphabetical. An error code reference lists every error the system can return, with a unique identifier, a plain-language meaning, common causes, and remediation steps. Docs as code stores documentation in the same repository as the product, in plain text (Markdown, AsciiDoc), reviewed via pull requests, and built by a static site generator.

Question 48 Technical Writing

What is a tutorial?

A tutorial guides the reader through learning by doing, usually in a beginner-friendly sequence. A design doc explains a proposed technical change: the problem, options considered, the chosen approach, trade-offs, risks, and rollout plan. Conceptual writing explains how something works or why it matters before asking the reader to act. An Architecture Decision Record captures one significant decision: the context, the choice made, the consequences, and the alternatives rejected, signed by date and author.

Question 49 Technical Writing

What is a "redirect" used for in docs?

Clear documents answer the reader’s real question instead of showcasing everything the author knows. A redirect sends a reader from an old or renamed URL to the new canonical page, preserving SEO and external links while content moves. It is the first sentence after the page title that previews what the page is for and the concrete task it accomplishes, so scanners can confirm they are in the right place. A docs review is a structured pass that checks accuracy (does it match the product?), completeness (are edge cases covered?), and clarity (would a new reader get it?). Engineers, writers, and ideally a fresh reader all contribute.

Question 50 Technical Writing

What is a "decision record" (ADR)?

Task success is the rate at which a reader with a goal completes it using the doc alone. The single most important metric for procedural content. Information should live in exactly one place. Other pages link to it, never copy-paste it, so updates propagate automatically and never contradict each other. Versioned with the product, reviewed by engineers, branched per release, searchable as text, and CI-checkable for broken links and lint rules. An Architecture Decision Record captures one significant decision: the context, the choice made, the consequences, and the alternatives rejected, signed by date and author.