Intermediate
Documentation Types
#post-mortem
#sre
#blameless
#incident
Blameless Post-Mortem Writing
5 exercises — impact statements, blameless timelines, Five Whys root cause, action items with owners, and lessons learned. The SRE culture vocabulary.
0 / 26 completed
1 / 26
A post-mortem impact statement reads: "The payment system was down and lots of users were affected." A tech lead says it needs to be rewritten. Which version is better?
A strong impact statement answers four questions with specific, measurable data:
1. When? "2026-04-05 from 14:32 to 16:15 UTC" — exact timestamps, always in UTC
2. How long? "103 minutes" — duration, not just start/end
3. Who was affected and how? "14,800 checkout attempts failed" — not "lots of users"
4. What was the business impact? "Estimated revenue $87,000; 230 support tickets" — quantifies the cost
Why specificity matters:
Post-mortems are used to:
• Prioritise which systems to improve first (high impact → high priority)
• Report to stakeholders who need numbers, not impressions
• Set a baseline for future incidents ("was this worse than last time?")
• Drive SLO and error budget conversations
Post-mortem impact vocabulary:
"The outage lasted [N minutes/hours] from [start UTC] to [end UTC]."
"Approximately [N] users / transactions / requests were affected."
"Estimated revenue impact: [amount]."
"[N] support tickets / customer complaints were received."
"[Service X] was fully unavailable / degraded at [N]% reduced capacity."
1. When? "2026-04-05 from 14:32 to 16:15 UTC" — exact timestamps, always in UTC
2. How long? "103 minutes" — duration, not just start/end
3. Who was affected and how? "14,800 checkout attempts failed" — not "lots of users"
4. What was the business impact? "Estimated revenue $87,000; 230 support tickets" — quantifies the cost
Why specificity matters:
Post-mortems are used to:
• Prioritise which systems to improve first (high impact → high priority)
• Report to stakeholders who need numbers, not impressions
• Set a baseline for future incidents ("was this worse than last time?")
• Drive SLO and error budget conversations
Post-mortem impact vocabulary:
"The outage lasted [N minutes/hours] from [start UTC] to [end UTC]."
"Approximately [N] users / transactions / requests were affected."
"Estimated revenue impact: [amount]."
"[N] support tickets / customer complaints were received."
"[Service X] was fully unavailable / degraded at [N]% reduced capacity."
2 / 26
A post-mortem timeline entry reads: "14:47 — John noticed the error rate going up and eventually decided to check the database." A reviewer says this is not blameless enough. The improved version is _____.
Blameless post-mortems focus on systems, signals, and decisions — not on people and their shortcomings. This is one of the most important concepts in SRE culture (pioneered by Google).
What makes the corrected version blameless:
• Names a system-level observable: "Error rate at 12% (up from baseline 0.1%)"
• Uses a role rather than a name: "On-call engineer" — the individual isn't blamed; the system's response is tracked
• Describes an action, not a judgment: "initiated database health check"
• Could not be added to a performance review as evidence of failure
Blameless writing vocabulary:
"[Role/system] observed [metric] at [value] in [tool]."
"The monitoring alert for [condition] did not fire." (system gap, not person gap)
"The runbook did not cover this failure mode." (documentation gap)
"At the time, the available information suggested [explanation] — leading to [decision]."
Blameful vs. blameless rewrites:
❌ "Bob deployed without testing." → ✅ "The deployment pipeline did not require a staging test pass."
❌ "Alice missed the alert." → ✅ "The alert was not configured for the affected service."
❌ "The team took too long." → ✅ "Detection time was 34 minutes; alert threshold was set to 15 minutes delay."
What makes the corrected version blameless:
• Names a system-level observable: "Error rate at 12% (up from baseline 0.1%)"
• Uses a role rather than a name: "On-call engineer" — the individual isn't blamed; the system's response is tracked
• Describes an action, not a judgment: "initiated database health check"
• Could not be added to a performance review as evidence of failure
Blameless writing vocabulary:
"[Role/system] observed [metric] at [value] in [tool]."
"The monitoring alert for [condition] did not fire." (system gap, not person gap)
"The runbook did not cover this failure mode." (documentation gap)
"At the time, the available information suggested [explanation] — leading to [decision]."
Blameful vs. blameless rewrites:
❌ "Bob deployed without testing." → ✅ "The deployment pipeline did not require a staging test pass."
❌ "Alice missed the alert." → ✅ "The alert was not configured for the affected service."
❌ "The team took too long." → ✅ "Detection time was 34 minutes; alert threshold was set to 15 minutes delay."
3 / 26
A post-mortem lists "Root Cause" as: "A bug in the payment service caused the outage." A senior SRE says this is incomplete. What is missing?
"A bug caused the outage" is never the root cause in a blameless post-mortem. It's the proximate cause — the immediate trigger. The root cause is the systemic condition that allowed the bug to reach production and cause an outage.
The Five Whys applied:
1. Why did the outage happen? → The payment service crashed.
2. Why did it crash? → A null pointer exception on a required field.
3. Why did code with a null pointer exception reach production? → Unit tests didn't cover nil input on that path.
4. Why didn't tests cover that path? → Test coverage was below 60% for that module.
5. Why was coverage that low? → The service was migrated from Python 2 three years ago and tests were never backfilled.
Root cause: "Insufficient test coverage on the payment service, a legacy of the Python 2 migration, allowed a nil-input regression to ship undetected."
Post-mortem root cause vocabulary:
"The proximate cause was X. The root cause was Y."
"Five Whys analysis revealed that the underlying systemic issue was…"
"Contributing factors included: …"
"This failure mode was possible because [systemic gap]."
The Five Whys applied:
1. Why did the outage happen? → The payment service crashed.
2. Why did it crash? → A null pointer exception on a required field.
3. Why did code with a null pointer exception reach production? → Unit tests didn't cover nil input on that path.
4. Why didn't tests cover that path? → Test coverage was below 60% for that module.
5. Why was coverage that low? → The service was migrated from Python 2 three years ago and tests were never backfilled.
Root cause: "Insufficient test coverage on the payment service, a legacy of the Python 2 migration, allowed a nil-input regression to ship undetected."
Post-mortem root cause vocabulary:
"The proximate cause was X. The root cause was Y."
"Five Whys analysis revealed that the underlying systemic issue was…"
"Contributing factors included: …"
"This failure mode was possible because [systemic gap]."
4 / 26
The "Action Items" section of a post-mortem lists: "Fix the bug. Improve monitoring. Update documentation." A tech lead says these are unacceptable. Why?
Vague post-mortem action items are one of the most common reasons incidents repeat. "Fix the bug" assigns no one, sets no deadline, and has no success criterion.
What a complete action item requires:
• Owner: one named person or team — not "the team" or "DevOps"
• Due date: specific date, not "soon" or "next sprint"
• What exactly: specific, measurable change
• Priority: P1/P2 or equivalent — links to the incident's severity
Rewritten action items:
❌ "Fix the bug." → ✅ "Add nil-safety checks to payment processor inputs. Owner: Maria G. Due: 2026-04-12."
❌ "Improve monitoring." → ✅ "Add Datadog alert for payment service error rate > 1% sustained for 2 minutes. Owner: SRE team. Due: 2026-04-10."
❌ "Update documentation." → ✅ "Update payments runbook with nil-input failure mode and recovery steps. Owner: Alex T. Due: 2026-04-15."
Post-mortem action item vocabulary:
"Action item: [specific task]. Owner: [name]. Priority: P[N]. Due: [date]. Success criterion: [measurable outcome]."
"This is a preventive action." / "This is a detective action." / "This is a corrective action."
What a complete action item requires:
• Owner: one named person or team — not "the team" or "DevOps"
• Due date: specific date, not "soon" or "next sprint"
• What exactly: specific, measurable change
• Priority: P1/P2 or equivalent — links to the incident's severity
Rewritten action items:
❌ "Fix the bug." → ✅ "Add nil-safety checks to payment processor inputs. Owner: Maria G. Due: 2026-04-12."
❌ "Improve monitoring." → ✅ "Add Datadog alert for payment service error rate > 1% sustained for 2 minutes. Owner: SRE team. Due: 2026-04-10."
❌ "Update documentation." → ✅ "Update payments runbook with nil-input failure mode and recovery steps. Owner: Alex T. Due: 2026-04-15."
Post-mortem action item vocabulary:
"Action item: [specific task]. Owner: [name]. Priority: P[N]. Due: [date]. Success criterion: [measurable outcome]."
"This is a preventive action." / "This is a detective action." / "This is a corrective action."
5 / 26
A post-mortem document ends with: "We apologise to our users for the inconvenience caused." A senior engineer objects to this in an internal post-mortem. Why?
Different document types serve different purposes and audiences — and tone/content should match.
Internal post-mortem:
• Audience: engineers, SREs, tech leads
• Purpose: understand what happened, prevent recurrence
• Ending: lessons learned + action items with owners
• Tone: analytical, neutral, forward-looking
• No apologies, marketing language, or customer service tone
Customer-facing incident communication:
• Audience: users, customers
• Purpose: acknowledge impact, explain what happened in non-technical terms, restore confidence
• Includes: apology, impact acknowledgment, what was fixed, what prevents recurrence
• Tone: empathetic, professional, clear
Standard internal post-mortem closing sections:
• "Lessons Learned / What Went Well / What Could Be Improved" — three lists
• "Action Items" — the decisions made
• "Review date" — when this post-mortem will be reviewed for progress
Lessons Learned vocabulary:
"What went well: Our oncall rotation detected the issue within [time]."
"What could be improved: Our runbook did not cover this failure mode."
"Key lesson: [systemic insight that applies beyond this incident]."
Internal post-mortem:
• Audience: engineers, SREs, tech leads
• Purpose: understand what happened, prevent recurrence
• Ending: lessons learned + action items with owners
• Tone: analytical, neutral, forward-looking
• No apologies, marketing language, or customer service tone
Customer-facing incident communication:
• Audience: users, customers
• Purpose: acknowledge impact, explain what happened in non-technical terms, restore confidence
• Includes: apology, impact acknowledgment, what was fixed, what prevents recurrence
• Tone: empathetic, professional, clear
Standard internal post-mortem closing sections:
• "Lessons Learned / What Went Well / What Could Be Improved" — three lists
• "Action Items" — the decisions made
• "Review date" — when this post-mortem will be reviewed for progress
Lessons Learned vocabulary:
"What went well: Our oncall rotation detected the issue within [time]."
"What could be improved: Our runbook did not cover this failure mode."
"Key lesson: [systemic insight that applies beyond this incident]."
6 / 26
PR#1234 has just been merged. During the code review of this PR, a junior developer, Maria, commented: 'This function is really complex and hard to understand. I think we need to add more comments.' The tech lead, David, responds with: 'That's good feedback, Maria. Let's document this clearly for future developers.' Which of the following best describes David's approach to post-mortem documentation related to this code? David's response demonstrates a blameless post-mortem mindset by recognizing the feedback while framing it within a larger context of improving future development. Option A is too granular and misses the point of a post-mortem; focusing solely on implementation details isn't the goal. Option B emphasizes adding comments *within* the code, which isn't always the most effective approach – clear documentation outside the code often provides better maintainability. Option C aligns with the purpose of a post-mortem: to identify areas for improvement and prevent future issues by documenting not just *what* the code does but *why* it was designed that way, contributing to overall understanding and reducing the risk of errors.
7 / 26
During a post-mortem for an API outage caused by incorrect rate limiting, the team discusses documenting the changes made. Liam suggests: 'Let's write a detailed description of how the rate limits were adjusted and why.' Meanwhile, Chloe proposes: 'We should focus on recording the impact – how many requests were blocked, what services were affected, and the user experience metrics.' Which approach best aligns with the principles of blameless post-mortems?
Liam's approach emphasizes documenting the *technical* changes, which is vital for future understanding and preventing recurrence. Chloe's response, while important to note the impact, doesn't address the underlying reasons for the rate limiting issue or the decisions made – a key element of blameless post-mortems. The goal is to understand *why* something happened, not just *what* happened and its consequences.
8 / 26
A team is conducting a post-mortem on a recent deployment that resulted in intermittent performance issues. During the discussion, Emily suggests documenting the specific configuration changes made to the server as part of the post-mortem. Ben counters with: 'Let's focus on *what* happened – specifically, the spike in CPU usage and the corresponding impact on response times.' Which statement best reflects a blameless post-mortem approach?
Blameless post-mortems prioritize understanding *what* happened and its impact over assigning responsibility for individual actions. While documenting configuration changes is important for future deployments, it's not the primary focus during an immediate problem investigation. The core goal is to learn from the event and prevent similar issues, which requires a clear description of the observed symptoms and their consequences – option 2 accurately captures this.
9 / 26
A team is investigating a recent incident where a new feature introduced intermittent errors in the user dashboard. During the post-mortem, Alex suggests documenting the specific code changes made to implement the feature, including commit hashes and associated tests. Ben argues that the focus should be on understanding *why* the errors occurred – specifically, the interactions between the new feature and existing components. Which of the following best represents a blameless post-mortem approach in this situation?
The core principle of blameless post-mortems is not just about documenting *what* happened but *why*. While tracking code changes (A) and immediate rollback (D) are valid actions, they don't address the underlying systemic issues. Option C correctly balances both aspects – a comprehensive understanding necessitates recording the implementation details alongside a deep dive into the root cause and how the feature interacted with the existing system. This allows for preventative measures to be put in place.
10 / 26
PR#1234 has just been merged. During the code review of this PR, a junior developer, Maria, commented: 'This function is really complex and hard to understand. I think we need to add more comments.' The tech lead, David, responds with: 'That's good feedback, Maria. Let's document this clearly for future developers.' Which of the following best describes David's approach to post-mortem documentation related to this code? David's response demonstrates a blameless post-mortem mindset by recognizing the feedback while framing it within a larger context of improving future development. Option A is too granular and misses the point of a post-mortem; focusing solely on implementation details isn't the goal. Option B emphasizes adding comments *within* the code, which isn't always the most effective approach – clear documentation outside the code often provides better maintainability. Option C aligns with the purpose of a post-mortem: to identify areas for improvement and prevent future issues by documenting not just *what* the code does but *why* it was designed that way, contributing to overall understanding and reducing the risk of errors.
11 / 26
During a post-mortem for an API outage caused by incorrect rate limiting, the team discusses documenting the changes made. Liam suggests: 'Let's write a detailed description of how the rate limits were adjusted and why.' Meanwhile, Chloe proposes: 'We should focus on recording the impact – how many requests were blocked, what services were affected, and the user experience metrics.' Which approach best aligns with the principles of blameless post-mortems?
Liam's approach emphasizes documenting the *technical* changes, which is vital for future understanding and preventing recurrence. Chloe's response, while important to note the impact, doesn't address the underlying reasons for the rate limiting issue or the decisions made – a key element of blameless post-mortems. The goal is to understand *why* something happened, not just *what* happened and its consequences.
12 / 26
A team is conducting a post-mortem on a recent deployment that resulted in intermittent performance issues. During the discussion, Emily suggests documenting the specific configuration changes made to the server as part of the post-mortem. Ben counters with: 'Let's focus on *what* happened – specifically, the spike in CPU usage and the corresponding impact on response times.' Which statement best reflects a blameless post-mortem approach?
Blameless post-mortems prioritize understanding *what* happened and its impact over assigning responsibility for individual actions. While documenting configuration changes is important for future deployments, it's not the primary focus during an immediate problem investigation. The core goal is to learn from the event and prevent similar issues, which requires a clear description of the observed symptoms and their consequences – option 2 accurately captures this.
13 / 26
A team is investigating a recent incident where a new feature introduced intermittent errors in the user dashboard. During the post-mortem, Alex suggests documenting the specific code changes made to implement the feature, including commit hashes and associated tests. Ben argues that the focus should be on understanding *why* the errors occurred – specifically, the interactions between the new feature and existing components. Which of the following best represents a blameless post-mortem approach in this situation?
The core principle of blameless post-mortems is not just about documenting *what* happened but *why*. While tracking code changes (A) and immediate rollback (D) are valid actions, they don't address the underlying systemic issues. Option C correctly balances both aspects – a comprehensive understanding necessitates recording the implementation details alongside a deep dive into the root cause and how the feature interacted with the existing system. This allows for preventative measures to be put in place.
14 / 26
PR#1234 has just been merged. During the code review of this PR, a junior developer, Maria, commented: 'This function is really complex and hard to understand. I think we need to add more comments.' The tech lead, David, responds with: 'That's good feedback, Maria. Let's document this clearly for future developers.' Which of the following best describes David's approach to post-mortem documentation related to this code? David's response demonstrates a blameless post-mortem mindset by recognizing the feedback while framing it within a larger context of improving future development. Option A is too granular and misses the point of a post-mortem; focusing solely on implementation details isn't the goal. Option B emphasizes adding comments *within* the code, which isn't always the most effective approach – clear documentation outside the code often provides better maintainability. Option C aligns with the purpose of a post-mortem: to identify areas for improvement and prevent future issues by documenting not just *what* the code does but *why* it was designed that way, contributing to overall understanding and reducing the risk of errors.
15 / 26
During a post-mortem for an API outage caused by incorrect rate limiting, the team discusses documenting the changes made. Liam suggests: 'Let's write a detailed description of how the rate limits were adjusted and why.' Meanwhile, Chloe proposes: 'We should focus on recording the impact – how many requests were blocked, what services were affected, and the user experience metrics.' Which approach best aligns with the principles of blameless post-mortems?
Liam's approach emphasizes documenting the *technical* changes, which is vital for future understanding and preventing recurrence. Chloe's response, while important to note the impact, doesn't address the underlying reasons for the rate limiting issue or the decisions made – a key element of blameless post-mortems. The goal is to understand *why* something happened, not just *what* happened and its consequences.
16 / 26
A team is conducting a post-mortem on a recent deployment that resulted in intermittent performance issues. During the discussion, Emily suggests documenting the specific configuration changes made to the server as part of the post-mortem. Ben counters with: 'Let's focus on *what* happened – specifically, the spike in CPU usage and the corresponding impact on response times.' Which statement best reflects a blameless post-mortem approach?
Blameless post-mortems prioritize understanding *what* happened and its impact over assigning responsibility for individual actions. While documenting configuration changes is important for future deployments, it's not the primary focus during an immediate problem investigation. The core goal is to learn from the event and prevent similar issues, which requires a clear description of the observed symptoms and their consequences – option 2 accurately captures this.
17 / 26
A team is investigating a recent incident where a new feature introduced intermittent errors in the user dashboard. During the post-mortem, Alex suggests documenting the specific code changes made to implement the feature, including commit hashes and associated tests. Ben argues that the focus should be on understanding *why* the errors occurred – specifically, the interactions between the new feature and existing components. Which of the following best represents a blameless post-mortem approach in this situation?
The core principle of blameless post-mortems is not just about documenting *what* happened but *why*. While tracking code changes (A) and immediate rollback (D) are valid actions, they don't address the underlying systemic issues. Option C correctly balances both aspects – a comprehensive understanding necessitates recording the implementation details alongside a deep dive into the root cause and how the feature interacted with the existing system. This allows for preventative measures to be put in place.
18 / 26
PR#1234 has just been merged. During the code review of this PR, a junior developer, Maria, commented: 'This function is really complex and hard to understand. I think we need to add more comments.' The tech lead, David, responds with: 'That's good feedback, Maria. Let's document this clearly for future developers.' Which of the following best describes David's approach to post-mortem documentation related to this code? David's response demonstrates a blameless post-mortem mindset by recognizing the feedback while framing it within a larger context of improving future development. Option A is too granular and misses the point of a post-mortem; focusing solely on implementation details isn't the goal. Option B emphasizes adding comments *within* the code, which isn't always the most effective approach – clear documentation outside the code often provides better maintainability. Option C aligns with the purpose of a post-mortem: to identify areas for improvement and prevent future issues by documenting not just *what* the code does but *why* it was designed that way, contributing to overall understanding and reducing the risk of errors.
19 / 26
During a post-mortem for an API outage caused by incorrect rate limiting, the team discusses documenting the changes made. Liam suggests: 'Let's write a detailed description of how the rate limits were adjusted and why.' Meanwhile, Chloe proposes: 'We should focus on recording the impact – how many requests were blocked, what services were affected, and the user experience metrics.' Which approach best aligns with the principles of blameless post-mortems?
Liam's approach emphasizes documenting the *technical* changes, which is vital for future understanding and preventing recurrence. Chloe's response, while important to note the impact, doesn't address the underlying reasons for the rate limiting issue or the decisions made – a key element of blameless post-mortems. The goal is to understand *why* something happened, not just *what* happened and its consequences.
20 / 26
A team is conducting a post-mortem on a recent deployment that resulted in intermittent performance issues. During the discussion, Emily suggests documenting the specific configuration changes made to the server as part of the post-mortem. Ben counters with: 'Let's focus on *what* happened – specifically, the spike in CPU usage and the corresponding impact on response times.' Which statement best reflects a blameless post-mortem approach?
Blameless post-mortems prioritize understanding *what* happened and its impact over assigning responsibility for individual actions. While documenting configuration changes is important for future deployments, it's not the primary focus during an immediate problem investigation. The core goal is to learn from the event and prevent similar issues, which requires a clear description of the observed symptoms and their consequences – option 2 accurately captures this.
21 / 26
A team is investigating a recent incident where a new feature introduced intermittent errors in the user dashboard. During the post-mortem, Alex suggests documenting the specific code changes made to implement the feature, including commit hashes and associated tests. Ben argues that the focus should be on understanding *why* the errors occurred – specifically, the interactions between the new feature and existing components. Which of the following best represents a blameless post-mortem approach in this situation?
The core principle of blameless post-mortems is not just about documenting *what* happened but *why*. While tracking code changes (A) and immediate rollback (D) are valid actions, they don't address the underlying systemic issues. Option C correctly balances both aspects – a comprehensive understanding necessitates recording the implementation details alongside a deep dive into the root cause and how the feature interacted with the existing system. This allows for preventative measures to be put in place.
22 / 26
During a post-mortem for a database query performance issue, Sarah states: 'We need to document the specific SQL query that was slow and any optimizations we applied.' Which of the following best describes the most appropriate documentation type in this situation?
This scenario focuses on documenting technical details related to performance improvements. The correct answer highlights the need for a comprehensive description of the problematic query and the changes made to optimize it. Options A & C are incorrect because they omit key information; option D is too simplistic and doesn't address the root cause.
23 / 26
The team is investigating a bug in a newly deployed microservice. David, during a Slack discussion, suggests: 'Let's create a thread summarizing the steps to reproduce the error and any relevant log snippets.' What type of documentation does David's suggestion primarily represent?
David's suggestion is centered around documenting an *incident*. Incident reports are crucial for tracking bugs, recording troubleshooting steps, and ultimately determining the root cause. While the other options represent different documentation types with distinct purposes, this scenario directly relates to capturing an incident's details.
24 / 26
After resolving a critical issue in a web application's authentication module, Maria adds a comment to the PR description: 'Updated the OAuth2 flow to handle JWT validation more robustly.' What is the primary purpose of this comment within the context of blameless post-mortems and documentation?
Maria's comment focuses on *specific code changes* – this is core to documenting technical improvements. The PR description should clearly articulate what was altered and *why*, as this information is vital for future developers understanding the fix. Options A & B are too broad; option D misrepresents the scope of the change.
25 / 26
During a standup meeting, Ben notes: 'We deployed version 2.3 today and experienced intermittent timeouts when processing large image uploads.' He suggests creating a document outlining the changes between versions 2.2 and 2.3. What is the most effective way to use this documentation in a blameless post-mortem?
The key here is tracing potential problems back to *configuration changes*. A post-mortem focuses on identifying root causes, and documenting those specific configuration differences between versions allows for a targeted investigation. Options A & B are irrelevant; option D doesn't address the technical cause of the issue.
26 / 26
A team is analyzing a recent incident where a server crashed after a code update. The lead engineer asks the development team to document 'the impact of the changes on system stability'. What type of information should be included in this documentation?
When assessing 'system stability', it's crucial to examine *performance impact*. The documentation should capture data on resource usage (CPU, memory, network) and performance metrics before and after the change. This provides concrete evidence to link the code update to the instability. Option A is too exhaustive; options B & D are tangential.
Frequently Asked Questions
What does the "Blameless Post-Mortem Writing — Documentation Types Exercises" exercise cover?
Practice writing blameless post-mortems in English: impact statements, timelines, root cause analysis (Five Whys), action items with owners, and lessons learned. 5 exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Blameless Post-Mortem Writing — Documentation Types Exercises"?
This exercise has 26 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Documentation Types exercises?
Browse the full Documentation Types hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.