Practise vocabulary for facilitating root cause discussions: 5 Whys, proximate vs. root causes, systemic analysis, and causal chain language.
0 / 10 completed
1 / 10
The 5 Whys technique involves repeatedly asking 'Why?' to trace a chain of causation from the ___ cause to deeper systemic causes.
The 5 Whys starts with the proximate (immediate) cause — the last event before the incident — and traces back through the causal chain. Each 'Why?' reveals a deeper cause, ideally reaching systemic process or design failures.
2 / 10
A ___ cause is the immediate, visible trigger of an incident — for example, 'a config change was deployed without review'.
The proximate cause is the most immediate cause — the last event in the causal chain. However, stopping at the proximate cause misses systemic improvements. '5 Whys' and fishbone diagrams help trace from proximate to root causes.
3 / 10
'The ___ cause of the incident was insufficient observability — we couldn't see the error rate rising until users started reporting issues.'
A root cause is the fundamental, underlying condition that allowed the incident to occur. 'Insufficient observability' is a root cause — fixing it (by adding metrics and alerts) prevents a whole class of future incidents, not just this one.
4 / 10
In a postmortem, describing a causal chain means explaining how ___ condition led to another in sequence, culminating in the incident.
A causal chain explains how one condition enabled or triggered the next — 'the deployment removed the rate limit, which allowed the traffic spike to overwhelm the database, which caused timeouts, which triggered the cascade failure.' Clear causal chains identify the best intervention points.
5 / 10
The facilitator's job when someone says 'X caused the outage' is to respond with ___.
The facilitator redirects from blame to system analysis: 'What conditions allowed X to happen?' opens a discussion about the environment, processes, and tooling that enabled the error — shifting from accountability to learning.
6 / 10
Alex from QA just posted this comment on a code review: 'The API returned 500 errors. This is causing users to see broken pages.' What's the most effective way for you to respond to encourage a root cause discussion, rather than simply accepting Alex's statement as fact?
Alex's statement describes a symptom (500 errors) but doesn't address the underlying reason. Option 2 prompts for more specific information – the 'why' behind the error – which is crucial for starting a root cause analysis. Options 1 and 3 are too vague, while option 4 jumps to a solution without understanding the problem.
7 / 10
During a Slack discussion about a recent deployment failure, Ben says: 'The database connection pool was exhausted.' What does Ben's statement primarily indicate as a potential root cause?
Ben's statement points to a problem with the *application's* interaction with the database. A depleted connection pool signifies that the application was requesting more connections than the pool could provide, likely due to inefficient queries or excessive requests. Options 1 and 3 describe potential configurations issues, while option 4 describes a hardware failure.
8 / 10
You're writing the description for a PR that introduced a fix for intermittent performance issues. You want to frame the change in terms of root cause discussion. Which of the following statements best reflects this approach?
Option 1 demonstrates a root cause-focused approach by acknowledging the *problem* (intermittent latency) and highlighting the investigation and optimization efforts. It shows you're not just stating what was fixed but explaining *why* it was fixed – essential for understanding the underlying issue and preventing recurrence. Options 2 and 3 are too vague, while option 4 simply describes a technical change without context.
9 / 10
Chloe, during a standup meeting, reports: 'We had an outage in the payment processing service.' What's the *most* important follow-up question to ask her to begin a root cause discussion?
Option 3 is crucial because it seeks a narrative – 'what happened' – that will allow you to start mapping out the sequence of events. Understanding the immediate impact provides context and directs further investigation. The other options are useful for gathering data but don't directly facilitate the causal chain analysis needed for root cause identification.
10 / 10
A junior developer says: 'The server crashed because the new feature wasn't deployed.' What is the most appropriate response to guide a deeper discussion about the root cause?
Option 1 dismisses the core issue. Option 2 directly addresses the problem – the failed deployment – by prompting for investigation into *why* it failed. Options 3 and 4 avoid addressing the underlying cause of the crash; a broken deployment is a symptom, not the root cause itself.
What will I practice in "Root Cause Discussion Language"?
This is a Post Incident Facilitation exercise set. It walks through 10 scenario-based multiple-choice questions built around real usage of post incident facilitation terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 10 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the post incident facilitation vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Post Incident Facilitation exercises?
See the Post Incident Facilitation exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — post incident facilitation vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.