Learn the vocabulary for planning, running, and reporting chaos engineering game days: "we will simulate", "expected vs actual behaviour", "rollback procedure", and game day report writing.
0 / 18 completed
1 / 18
In a game day planning document, an engineer writes: 'We will simulate a regional failure by blocking all traffic to us-east-1.' What is the correct interpretation?
'We will simulate' is the core game day planning verb: it signals a deliberate, controlled fault injection designed to reproduce a specific failure scenario. The phrase distinguishes a chaos experiment from a real incident, from a tabletop exercise (discussion only), and from testing in a simulated environment. Simulation in chaos engineering means real fault injection in a real (or near-production) environment, not a theoretical discussion or staging-only test.
2 / 18
A game day report shows: 'Expected behaviour: circuit breaker opens within 5 failed requests. Actual behaviour: circuit breaker opened after 47 failed requests.' How should a facilitator frame this finding?
Expected vs. actual behaviour comparison is the core analytical step in game day reporting. A mismatch is a finding — not a failure of the experiment, but a discovery of a gap between design intent and actual system behavior. The good report names the mismatch precisely, identifies the probable root cause (misconfigured threshold), quantifies the impact (42 extra cascading errors), and produces a specific action item.
3 / 18
What must a rollback procedure include to be considered complete before a game day?
Rollback procedures are a game day safety prerequisite. Requirements: (1) specific, not abstract — actual commands or UI steps; (2) verified to work before the game day — never test the rollback for the first time during the actual experiment; (3) fast — the rollback should take seconds or low single-digit minutes; (4) known to multiple people — not just the experiment author. If the rollback procedure is unclear or untested, the game day should not proceed.
4 / 18
What is the facilitator's primary responsibility during a game day, and what should they NOT do?
The facilitator's separation from the responders is a key game day design principle: if the facilitator joins the debugging effort, no one is watching safety conditions, keeping the session on track, capturing observations, or ready to trigger the kill switch. The facilitator role is equivalent to an exercise controller in a military drill — they set up the scenario and observe, they do not fight the fire. Post-game, the facilitator also runs the retrospective.
5 / 18
Which of the following is a well-structured game day report summary?
A well-structured game day report includes all key fields: the scenario (specific fault injected), the hypothesis (measurable steady-state assertion), actual behavior (metrics observed), the outcome (confirmed/rejected), finding (specific gap discovered), and action items (specific change, named owner, deadline). The vague alternatives — 'the team did a good job,' 'some resilience issues,' 'discuss at sprint planning' — do not create accountability or organizational memory.
6 / 18
Sarah: 'Okay team, let's run a full chaos experiment. I'm going to trigger a synthetic transaction failure—essentially, I'll simulate a dead endpoint returning a 503 error for the user authentication service. We should monitor everything closely and expect a cascading failure across dependent services.'
Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
Sarah's statement demonstrates an understanding of chaos engineering by proposing a controlled disruption. However, the explanation highlights that 'appropriate' is the best fit because it accurately reflects her approach: she's outlining a test with monitoring expectations. The other options misinterpret her intention; simply stating a failure doesn't account for potential rollback needs or scope limitations—these are critical aspects of a well-planned game day. A good facilitator would build on this by adding details about the recovery process and impact assessment.
7 / 18
Sarah is preparing for a game day focused on testing the resilience of her team's microservices. During a Slack discussion, a junior developer asks, 'So, we're just deliberately making things fail to see how they react?' Sarah responds: 'Exactly! We need to provoke failures – think intermittent network issues, service timeouts, even simulating a sudden spike in traffic – to identify weaknesses and ensure our monitoring and alerting are actually effective. It's about finding the *unexpected* ways our system might break.' Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
This question assesses understanding of a core tenet of chaos engineering: actively seeking out failure. Option A is incorrect because precise playbooks stifle the exploratory nature of game days. Option B misrepresents the goal; while production-like conditions are desirable, 'perfect control' isn't the aim – it's about observing *uncontrolled* behavior. Option D focuses on post-incident analysis, which is important but not Sarah's immediate planning focus. The correct answer (option 2) accurately reflects Sarah's goal of proactively provoking failures to identify weaknesses and test resilience.
8 / 18
Sarah: 'Okay team, let's run a full chaos experiment. I'm going to trigger a synthetic transaction failure—essentially, I'll simulate a dead endpoint returning a 503 error for the user authentication service. We should monitor everything closely and expect a cascading failure across dependent services.'
Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
Sarah's statement demonstrates an understanding of chaos engineering by proposing a controlled disruption. However, the explanation highlights that 'appropriate' is the best fit because it accurately reflects her approach: she's outlining a test with monitoring expectations. The other options misinterpret her intention; simply stating a failure doesn't account for potential rollback needs or scope limitations—these are critical aspects of a well-planned game day. A good facilitator would build on this by adding details about the recovery process and impact assessment.
9 / 18
Sarah is preparing for a game day focused on testing the resilience of her team's microservices. During a Slack discussion, a junior developer asks, 'So, we're just deliberately making things fail to see how they react?' Sarah responds: 'Exactly! We need to provoke failures – think intermittent network issues, service timeouts, even simulating a sudden spike in traffic – to identify weaknesses and ensure our monitoring and alerting are actually effective. It's about finding the *unexpected* ways our system might break.' Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
This question assesses understanding of a core tenet of chaos engineering: actively seeking out failure. Option A is incorrect because precise playbooks stifle the exploratory nature of game days. Option B misrepresents the goal; while production-like conditions are desirable, 'perfect control' isn't the aim – it's about observing *uncontrolled* behavior. Option D focuses on post-incident analysis, which is important but not Sarah's immediate planning focus. The correct answer (option 2) accurately reflects Sarah's goal of proactively provoking failures to identify weaknesses and test resilience.
10 / 18
Sarah: 'Okay team, let's run a full chaos experiment. I'm going to trigger a synthetic transaction failure—essentially, I'll simulate a dead endpoint returning a 503 error for the user authentication service. We should monitor everything closely and expect a cascading failure across dependent services.'
Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
Sarah's statement demonstrates an understanding of chaos engineering by proposing a controlled disruption. However, the explanation highlights that 'appropriate' is the best fit because it accurately reflects her approach: she's outlining a test with monitoring expectations. The other options misinterpret her intention; simply stating a failure doesn't account for potential rollback needs or scope limitations—these are critical aspects of a well-planned game day. A good facilitator would build on this by adding details about the recovery process and impact assessment.
11 / 18
Sarah is preparing for a game day focused on testing the resilience of her team's microservices. During a Slack discussion, a junior developer asks, 'So, we're just deliberately making things fail to see how they react?' Sarah responds: 'Exactly! We need to provoke failures – think intermittent network issues, service timeouts, even simulating a sudden spike in traffic – to identify weaknesses and ensure our monitoring and alerting are actually effective. It's about finding the *unexpected* ways our system might break.' Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
This question assesses understanding of a core tenet of chaos engineering: actively seeking out failure. Option A is incorrect because precise playbooks stifle the exploratory nature of game days. Option B misrepresents the goal; while production-like conditions are desirable, 'perfect control' isn't the aim – it's about observing *uncontrolled* behavior. Option D focuses on post-incident analysis, which is important but not Sarah's immediate planning focus. The correct answer (option 2) accurately reflects Sarah's goal of proactively provoking failures to identify weaknesses and test resilience.
12 / 18
Sarah: 'Okay team, let's run a full chaos experiment. I'm going to trigger a synthetic transaction failure—essentially, I'll simulate a dead endpoint returning a 503 error for the user authentication service. We should monitor everything closely and expect a cascading failure across dependent services.'
Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
Sarah's statement demonstrates an understanding of chaos engineering by proposing a controlled disruption. However, the explanation highlights that 'appropriate' is the best fit because it accurately reflects her approach: she's outlining a test with monitoring expectations. The other options misinterpret her intention; simply stating a failure doesn't account for potential rollback needs or scope limitations—these are critical aspects of a well-planned game day. A good facilitator would build on this by adding details about the recovery process and impact assessment.
13 / 18
Sarah is preparing for a game day focused on testing the resilience of her team's microservices. During a Slack discussion, a junior developer asks, 'So, we're just deliberately making things fail to see how they react?' Sarah responds: 'Exactly! We need to provoke failures – think intermittent network issues, service timeouts, even simulating a sudden spike in traffic – to identify weaknesses and ensure our monitoring and alerting are actually effective. It's about finding the *unexpected* ways our system might break.' Which of the following best describes Sarah's approach to game day planning, considering the concept of 'chaos engineering'?
This question assesses understanding of a core tenet of chaos engineering: actively seeking out failure. Option A is incorrect because precise playbooks stifle the exploratory nature of game days. Option B misrepresents the goal; while production-like conditions are desirable, 'perfect control' isn't the aim – it's about observing *uncontrolled* behavior. Option D focuses on post-incident analysis, which is important but not Sarah's immediate planning focus. The correct answer (option 2) accurately reflects Sarah's goal of proactively provoking failures to identify weaknesses and test resilience.
14 / 18
Code Review Comment: 'This endpoint is highly dependent on the external payment gateway. A failure there should trigger a retry mechanism, but it's not implemented. Let's simulate a gateway outage for game day.' What does this comment primarily indicate about the planned chaos experiment?
The comment highlights a vulnerability – reliance on an external system. It's framing the planned outage as a controlled test of the system's ability to handle this dependency. The incorrect options misinterpret the situation; a low balance isn't relevant here, and simplification isn't the goal of a chaos experiment.
15 / 18
Slack Message from Lead Dev (Mark): 'Okay team, we're running a simulated service degradation test. I've triggered a 502 Bad Gateway error for the product catalog API. Monitor response times and error rates closely – let's see how quickly our circuit breakers engage.' What is Mark primarily trying to achieve with this message?
Mark's message is focused on observing the system's response to a controlled failure. The goal is to collect metrics regarding performance and error rates during this simulated degradation. The other options represent secondary concerns – awareness, escalation, or tool validation—which are not the primary focus of this specific experiment.
16 / 18
PR Description: 'Implemented improved retry logic for the user authentication service. This will automatically re-attempt requests if a transient error (503) is encountered. This change *should* improve resilience but doesn't account for scenarios where the underlying system is permanently unavailable.' What does this PR description implicitly suggest about the game day planning?
The description explicitly mentions '503' errors which are commonly used in chaos experiments. The phrasing 'permanently unavailable' strongly suggests that a scenario involving a sustained outage is planned for game day. It's crucial to test how the system behaves when the root cause isn't just temporary.
17 / 18
Standup Update from Developer (Elena): 'I've been working on implementing circuit breakers for the payment service. We're planning a game day to test their effectiveness by simulating a complete outage – essentially, we'll be blocking all traffic to the backend.' How should Elena best frame this statement to the team?
Elena's statement needs to convey the *purpose* of the game day – a realistic test of resilience. Acknowledging the potential for downtime is essential because that's precisely what they are trying to assess and improve upon. The other options represent secondary considerations or requests for help.
18 / 18
Game Day Report Summary: 'The service experienced intermittent latency spikes during the simulated network outage, but the circuit breakers engaged promptly and prevented data corruption. Overall, the system demonstrated good resilience.' What is the MOST critical takeaway from this summary?
The summary explicitly states that the system 'successfully handled' the simulated failure. That is the key finding – demonstrating resilience under stress. While optimization and root cause analysis might be valuable follow-up steps, they are secondary to the core success of the experiment.
What will I practice in "Game Day Planning and Facilitation Vocabulary — Chaos Engineering"?
This is a Chaos Engineering exercise set. It walks through 18 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 18 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.