4 exercises — write complete blameless post-mortems: root cause analysis, impact, action items, and what went well.
0 / 17 completed
1 / 17
Which section of a post-mortem describes what failed and why without assigning blame to individuals?
The Root Cause Analysis (RCA) section explains the technical and process failures that caused the incident. It answers: What specifically failed? Why did it fail? What conditions allowed it to fail?
Standard post-mortem sections: • Executive Summary — 1–2 sentences for leadership • Impact — duration, users affected, business effect • Timeline — chronological events • Root Cause Analysis — what failed and why • Contributing Factors — conditions that made failure worse • What Went Well — response actions that helped • What Went Poorly — gaps in response or process • Action Items — concrete follow-up with owner + due date
The RCA should identify root causes (the fundamental reason) not just proximate causes (the immediate trigger). Example: the proximate cause was "a config file had an error". The root cause might be "there was no automated config validation in the deployment pipeline".
2 / 17
Which "Impact" section entry is most complete and useful for a post-mortem?
Option C is the professional standard. A complete Impact section quantifies:
• Duration — exact start and end times in UTC • Users affected — count and percentage • Business impact — transactions, revenue, or equivalent • Scope — which regions, services, features were affected • SLO/SLA impact — did this breach your availability target?
Vague impact statements ("many users", "for a while") make it impossible to prioritise fixes, communicate with customers accurately, or calculate the cost of prevention vs. remediation. Numbers are non-negotiable for post-mortems that leadership will read.
3 / 17
Write the best "Action Item" entry for fixing missing config validation. Which format is correct?
Option C follows the required format for action items: What + Owner + Due Date + Priority. Each element is essential:
• What — specific, actionable ("add automated config schema validation to the deployment pipeline" — not "fix config") • Owner — a named person, not a team (teams don't complete tasks, individuals do) • Due date — a specific date, not "soon" or "next sprint" • Priority — P1 (prevent recurrence) vs P2 (improve) vs P3 (monitoring)
Action items without owners and dates are aspirations, not commitments. In a blameless culture, assigning ownership to an action item is not blame — it's accountability for a future improvement, which is healthy.
4 / 17
Complete the post-mortem "What Went Well" section. Scenario: the incident team identified the root cause in 15 minutes. Which entry is most useful?
Option C is the professional standard for a "What Went Well" entry. It: (1) names the specific positive behaviour (rapid root cause identification in 15 minutes); (2) explains the mechanism that made it possible (deployment logs + correlated dashboards); (3) connects to a metric (MTTR reduction).
The "What Went Well" section is often written hastily — but it's valuable. It captures which investments paid off (the logging, the dashboards) and provides evidence that good practices are worth maintaining. Generic entries like "the team was fast" provide no institutional knowledge or replicable lesson.
5 / 17
Alice, a senior developer, posted this comment on a code review: 'This function is returning null when it should be an object. Fix it.' In the context of a post-mortem for this incident, which phrase best captures the *technical* issue Alice identified?
This question tests understanding of translating a technical observation into post-mortem language. Option 2 accurately describes the specific problem – the API returning unexpected data – which is a core element to investigate during an incident response. Options A and B are too high-level, while option D focuses on a general principle rather than the immediate issue.
6 / 17
Ben, a junior engineer, sends this Slack message after investigating a recent outage: 'I think it was the database connection pool that died. I've added more connections.' Draft a concise and professional response to Ben in a post-mortem discussion, summarizing his findings and suggesting further steps. Aim for approximately 30-50 words.
This question assesses the ability to synthesize information and formulate a constructive response within the post-mortem context. Option 3 encourages further investigation into the *cause* of the problem, which is crucial for preventing recurrence – a key element of post-mortems. Options A and B are too focused on procedural details, while option D lacks actionable insights.
7 / 17
Complete the following 'Action Item' entry for fixing missing config validation: 'To prevent similar issues in the future, we need to _____ config_validation.py and ensure that all required parameters are present before deploying changes.'
This question tests the correct phrasing for a practical action item. 'Review' is the most appropriate verb here – it implies careful examination and correction of the existing process. The other options are either irrelevant or suggest a more drastic solution than simply checking the configuration.
8 / 17
Alice, a senior developer, posted this comment on a code review: 'This function is returning null when it should be an object. Fix it.' In the context of a post-mortem for this incident, which phrase best captures the *technical* issue Alice identified?
This question tests understanding of translating a technical observation into post-mortem language. Option 2 accurately describes the specific problem – the API returning unexpected data – which is a core element to investigate during an incident response. Options A and B are too high-level, while option D focuses on a general principle rather than the immediate issue.
9 / 17
Ben, a junior engineer, sends this Slack message after investigating a recent outage: 'I think it was the database connection pool that died. I've added more connections.' Draft a concise and professional response to Ben in a post-mortem discussion, summarizing his findings and suggesting further steps. Aim for approximately 30-50 words.
This question assesses the ability to synthesize information and formulate a constructive response within the post-mortem context. Option 3 encourages further investigation into the *cause* of the problem, which is crucial for preventing recurrence – a key element of post-mortems. Options A and B are too focused on procedural details, while option D lacks actionable insights.
10 / 17
Complete the following 'Action Item' entry for fixing missing config validation: 'To prevent similar issues in the future, we need to _____ config_validation.py and ensure that all required parameters are present before deploying changes.'
This question tests the correct phrasing for a practical action item. 'Review' is the most appropriate verb here – it implies careful examination and correction of the existing process. The other options are either irrelevant or suggest a more drastic solution than simply checking the configuration.
11 / 17
David, a DevOps engineer, sent this message to the incident Slack channel after a brief service disruption:
'Looks like an old deployment process triggered a cascading failure. We rolled back the changes.'
Which of the following phrases should Sarah, a developer involved in the post-mortem, include in her notes regarding David's message to accurately capture the situation?
The correct answer highlights that David's message directly identifies the root cause (old deployment process) and the immediate response (rollback). This is crucial for accurately documenting the timeline and sequence of events. Options A, C, and D are inaccurate because they misinterpret or over-emphasize aspects not present in David's statement – namely, a lack of detail about the technical failure.
12 / 17
Maria is drafting the 'Impact' section of a post-mortem for a service that experienced intermittent errors. Which of the following statements best describes how to quantify the impact effectively?
The best answer provides a specific, measurable impact. Quantifying the error rate (5%) and linking it to a tangible consequence (delay in order processing) demonstrates a clear understanding of how the incident affected users and business operations. Options A is too vague, B is descriptive but lacks quantification, and C & D focus on investigation rather than impact assessment.
13 / 17
Sarah, a lead developer, is writing the 'Root Cause' section of a post-mortem for an unexpected spike in API latency. She writes: 'The application server was overloaded due to a sudden increase in user requests.' Which phrase best describes how to improve this statement for clarity and actionable insights?
The original statement is too vague. A good root cause analysis should include quantifiable data (e.g., request volume, response times) and potentially suggest a hypothesis about the reason for the overload. Option 1 correctly identifies this gap; options 2 & 3 are simply stating that it's sufficient, while option 4 lacks any useful information.
14 / 17
Imagine you're drafting a Slack message to inform the team about a recent incident. The incident involved a misconfigured DNS record causing intermittent service unavailability. What concise and professional phrasing would you use to quickly convey this information to your colleagues?
Example: 'Urgent - DNS misconfiguration impacting [Service Name]. Investigation ongoing.'
The best response is a clear and direct statement of the problem, its impact, and ongoing actions. Options 1 & 2 are too informal; option 3 implies resolution without confirming it, while option 4 uses overly dramatic language that isn't appropriate for professional communication.
15 / 17
During a post-mortem discussion, the team is evaluating the 'Detection Time' section. The initial alert triggered by the monitoring system was delayed by 5 minutes. Which of the following options best describes how to accurately capture this delay in the post-mortem?
It's crucial to be precise about the delay in detection times. Option 2 is misleading; option 1 denies the issue, while option 3 provides a factual description with a brief explanation for the delay (which should be supported by data). Option 4 uses vague language that doesn't convey the actual metric.
16 / 17
David, a developer, is contributing to the 'Action Items' section of a post-mortem. Which phrasing best describes an action item for improving automated testing?
The best phrasing clearly outlines *what* needs to be done and *why*. Option 1 is too simplistic. Option 3 is more detailed and explains the purpose of improving test coverage – ensuring sufficient automation. Options 1 & 4 are just commands without context.
17 / 17
A post-mortem for a failed deployment reveals that the automated rollback process wasn't triggered. Which statement best summarizes how to document this in the 'Root Cause' section?
This statement precisely describes the problem – that the rollback *didn't* happen. Option 1 is the opposite of reality; option 3 provides a more detailed explanation, and option 4 suggests a solution rather than documenting the root cause.
What will I practise in "Writing Post-Mortems — Incident Response English Exercise"?
Practice writing complete blameless post-mortems: root cause analysis, impact statements, action items, and 'what went well' sections. 4 advanced exercises.
How many exercises are in this module?
This module has 17 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
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.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Incident Response exercises?
Browse the full Incident Response hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.