Learn the vocabulary and phrases used to communicate chaos experiment results clearly: "the system degraded gracefully", "we observed unexpected behaviour", "action items from the game day", and more.
0 / 14 completed
1 / 14
An engineer writes in the experiment report: 'The system degraded gracefully.' What does this communicate?
Graceful degradation is a positive finding — it means the system's resilience mechanisms worked. Common examples: 'The recommendation service was injected with latency; the product page loaded without recommendations rather than timing out — graceful degradation confirmed.' Or: 'When we exhausted database connections, the API returned cached responses for read requests — a graceful degradation path.' Contrast with: 'the system failed completely' or 'error rate spiked to 40%' — those indicate ungraceful failure.
2 / 14
How should you communicate 'unexpected behaviour' in a chaos experiment result?
Communicating unexpected behaviour requires specificity: what was injected, what was affected (including unexpected components), what metrics showed the anomaly, and a preliminary root cause hypothesis. Vague reports ('something weird happened') are not actionable. Good unexpected behaviour reports become the most valuable experiment findings — they reveal hidden dependencies, cascading failure paths, and architectural assumptions that were never explicitly tested.
3 / 14
What makes an 'action item from the game day' well-formed and actionable?
Well-formed action items have: a specific technical change (circuit breaker, not 'resilience improvement'), the exact component to be modified, the owner (a named team, not 'someone'), and a deadline (a sprint or date, not 'later'). Vague action items like 'improve resilience' are never completed because no one knows what done looks like. The best game day action items read like engineering tickets — because they should become engineering tickets.
4 / 14
How do you correctly state that a chaos hypothesis was rejected?
Hypothesis rejection is not a failure — it is a finding. The communication must include: the injected condition, the metric that was violated, the specific threshold exceeded, and the preliminary root cause. Saying 'the experiment failed' confuses the experiment outcome (which succeeded in revealing a gap) with system failure. A rejected hypothesis with a clear finding and action item is a highly valuable outcome.
5 / 14
A report states: 'The system recovered within 47 seconds of removing the fault.' Why is this phrasing important?
Measuring and reporting recovery time is a key chaos engineering output. 'The system recovered within 47 seconds' establishes a baseline: if your RTO (Recovery Time Objective) is 30 seconds, this is a gap. If the next experiment after adding a circuit breaker shows recovery in 12 seconds, you have measured improvement. Always specify what 'recovered' means: 'error rate returned to below 0.5% and latency returned to below 300ms within 47 seconds of removing the fault.'
6 / 14
Sarah: 'The service latency spiked to 150ms during the fault injection, but we saw a consistent recovery rate of 98% over the next five minutes.'
During a code review of this update, your team lead asks you to refine this statement for clarity and impact. Which phrasing best communicates the key findings of the chaos experiment to the rest of the team?
The original statement provides valuable technical data but needs framing for a broader audience. Option 1 accurately highlights the significance of the latency spike (150ms) alongside the positive recovery rate, demonstrating that while there was an issue, it was effectively resolved. Options B and C are misleading; 'recovery rate' doesn't replace the need to quantify the issue. Option D is too vague – stating only a recovery rate without context about the baseline latency makes it difficult for others to assess the severity of the experiment.
7 / 14
Sarah: 'The service latency spiked to 150ms during the fault injection, but we saw a consistent recovery rate of 98% over the next five minutes.'
During a code review of this update, your team lead asks you to refine this statement for clarity and impact. Which phrasing best communicates the key findings of the chaos experiment to the rest of the team?
The original statement provides valuable technical data but needs framing for a broader audience. Option 1 accurately highlights the significance of the latency spike (150ms) alongside the positive recovery rate, demonstrating that while there was an issue, it was effectively resolved. Options B and C are misleading; 'recovery rate' doesn't replace the need to quantify the issue. Option D is too vague – stating only a recovery rate without context about the baseline latency makes it difficult for others to assess the severity of the experiment.
8 / 14
Sarah: 'The service latency spiked to 150ms during the fault injection, but we saw a consistent recovery rate of 98% over the next five minutes.'
During a code review of this update, your team lead asks you to refine this statement for clarity and impact. Which phrasing best communicates the key findings of the chaos experiment to the rest of the team?
The original statement provides valuable technical data but needs framing for a broader audience. Option 1 accurately highlights the significance of the latency spike (150ms) alongside the positive recovery rate, demonstrating that while there was an issue, it was effectively resolved. Options B and C are misleading; 'recovery rate' doesn't replace the need to quantify the issue. Option D is too vague – stating only a recovery rate without context about the baseline latency makes it difficult for others to assess the severity of the experiment.
9 / 14
Sarah: 'The service latency spiked to 150ms during the fault injection, but we saw a consistent recovery rate of 98% over the next five minutes.'
During a code review of this update, your team lead asks you to refine this statement for clarity and impact. Which phrasing best communicates the key findings of the chaos experiment to the rest of the team?
The original statement provides valuable technical data but needs framing for a broader audience. Option 1 accurately highlights the significance of the latency spike (150ms) alongside the positive recovery rate, demonstrating that while there was an issue, it was effectively resolved. Options B and C are misleading; 'recovery rate' doesn't replace the need to quantify the issue. Option D is too vague – stating only a recovery rate without context about the baseline latency makes it difficult for others to assess the severity of the experiment.
10 / 14
During a Slack discussion about the results of a chaos experiment targeting the payment service, Alex writes: 'Looks like the circuit breaker tripped and then auto-recovered. Nothing to worry about.' Which of the following best describes the tone Alex is conveying?
Alex's statement is technically accurate – the circuit breaker functioned as expected. However, it lacks crucial information regarding *why* the trip occurred (the root cause) and doesn't adequately convey the level of risk involved in auto-recovery scenarios. The phrase 'nothing to worry about' can be misinterpreted, potentially masking a deeper problem within the system's design or configuration. A better approach would acknowledge the event and initiate investigation.
11 / 14
You are drafting a PR description for a change that introduces chaos experiments into your monitoring pipeline. Which of the following sentences is most effective in communicating the potential impact of an experiment's findings?
Option 1 clearly states the *purpose* of the changes – to proactively identify weaknesses. Options 2, 3, and 4 simply describe actions taken or outcomes expected without directly addressing the potential consequences or importance of the experiment's results. Framing the change as focused on resilience is key when discussing chaos experiments.
12 / 14
During a standup meeting, David says: 'We ran a chaos experiment that introduced latency to the user authentication service. The recovery time was significantly longer than expected – around 30 seconds.' What does David need to add to his statement to make it more useful for the team?
David's initial statement only describes *what* happened (latency and slow recovery). Adding information about the increased error rates provides crucial context for understanding the severity of the problem. Simply stating the experiment's purpose isn't enough; the team needs to know the impact on user experience or system stability. The other options are relevant details, but not the immediate next step.
13 / 14
In a code review comment for a chaos experiment report, your colleague writes: 'This data is confusing; it shows a spike in latency followed by a recovery, but the metrics are inconsistent.' What's the most appropriate response to this comment?
Acknowledging that inconsistency *is* expected in chaos experiments demonstrates an understanding of the process. However, simply dismissing it without further investigation isn't productive. The best response is to request concrete examples – this allows for targeted analysis and identification of potential issues with data collection or interpretation. Option 3 is a deflection, and option 4 shifts focus away from addressing the problem.
14 / 14
A chaos experiment report states: 'The system exhibited intermittent high latency during the fault injection. While the service eventually stabilized within 60 seconds, the instability caused a noticeable degradation in user experience.' What is the primary purpose of including this phrasing rather than simply stating 'latency spiked'?
The added phrasing – 'intermittent high latency,' 'noticeable degradation' – provides a far more realistic and informative picture than just stating 'latency spiked.' It communicates not only the *technical* event but also its *operational* impact on users. This level of detail is crucial for decision-making about mitigation strategies or system improvements.
What will I practice in "Communicating Chaos Experiment Results — Vocabulary and Language"?
This is a Chaos Engineering exercise set. It walks through 14 scenario-based multiple-choice questions built around real usage of Chaos Engineering 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 14 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 Chaos Engineering 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 Chaos Engineering exercises?
See the Chaos Engineering 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 — Chaos Engineering vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.