Practice vocabulary for running chaos experiments in production: safeguards, self-healing, monitoring, and production chaos boundaries.
0 / 21 completed
1 / 21
Your team says 'We run chaos experiments in production with safeguards.' What are typical safeguards for production chaos?
Production chaos safeguards include: automatic abort conditions (if error rate exceeds X%, stop), blast radius limits (only affect a small % of traffic), rollback procedures, and pre-agreed halt criteria — ensuring experiments can be stopped before causing customer impact.
2 / 21
A chaos runbook says 'The chaos experiment is automated and self-healing.' What does self-healing mean in this context?
A self-healing chaos experiment is designed so the system automatically recovers once the fault injection stops — the experiment tests the system's ability to restore itself, not just that it fails gracefully.
3 / 21
Your chaos protocol says 'The chaos engineer monitors during the experiment.' What should the engineer specifically watch?
During a chaos experiment, the engineer monitors business metrics (error rates, latency, transaction success rates) and technical metrics simultaneously. The goal is to detect unexpected blast radius and abort before real customer harm occurs.
4 / 21
A post-experiment report says 'We ran the experiment during low-traffic hours.' Why is traffic timing important for production chaos?
Running experiments during low-traffic periods (nights, weekends) reduces the number of customers affected if something goes wrong unexpectedly. It is a risk management approach for early-stage production chaos experiments.
5 / 21
Your chaos policy document defines 'the production chaos boundary.' What does this boundary define?
The production chaos boundary explicitly defines the scope of what is allowed: which services are in-scope, what percentage of requests can be affected, what failure types can be injected, and what is strictly off-limits — protecting critical paths.
6 / 21
Sarah: "Hey team, I'm running a chaos experiment to test the resilience of our API gateway. It's currently injecting intermittent 502 errors."
Mark (in a Slack channel): "Sounds risky! Should we just kill the experiment?"
The correct response—scaling up resources—reflects best practices in chaos engineering. While a 502 error *can* be a genuine problem, it's frequently a symptom of increased load or temporary infrastructure issues. Immediately killing the experiment without investigation risks prematurely halting valuable data collection and potentially masking an important real-time performance bottleneck. Options A and D represent overly cautious responses that don't align with the iterative nature of chaos experiments; option C is also incorrect as 502 errors are *part* of the experiment, not automatically resolved.
7 / 21
PR Description
Subject: Injecting latency to test API performance
Body:
We're running a chaos experiment to simulate network congestion and assess the impact on our user-facing API. The goal is to observe how the system handles increased latency under load. We've introduced a synthetic, intermittent delay of 100ms using curl --silent --writeout %{time}, targeting the authentication service. Please review and approve before deploying.
What does the phrase 'synthetic delay' imply in this context?
The key here is understanding 'synthetic'. This phrase means an artificially created delay—in this case, using `curl` to mimic network latency. The description explicitly states it's for testing and doesn't imply a real network issue or hardware problem. Option A is incorrect because synthetic delays are *not* caused by natural slowdowns; they are deliberately introduced. Options C and D are also incorrect as a synthetic delay isn't a permanent configuration or a hardware malfunction.
8 / 21
Liam: "We're using a tool called `Chaos Monkey` to randomly kill servers in our production environment. This helps us identify weaknesses and improve our resilience."
Chloe (in a PR description for a new experiment): "Introducing intermittent 300ms latency to the payment service via a custom script."
What does Chloe's statement primarily aim to achieve?
Chloe's statement focuses on introducing a controlled disruption – this is the core principle of chaos engineering. 'Chaos Monkey' typically refers to random server termination; Chloe's action demonstrates a deliberate attempt to test resilience under specific conditions. The goal isn't simply to break things, but to observe and understand how the system responds to unexpected delays, mimicking real-world latency issues and validating recovery mechanisms. Option A is incorrect as it describes a different strategy; option C is too broad; and option D is completely misaligned with the purpose of chaos experiments.
9 / 21
Sarah: "Hey team, I'm running a chaos experiment to test the resilience of our API gateway. It's currently injecting intermittent 502 errors."
Mark (in a Slack channel): "Sounds risky! Should we just kill the experiment?"
The correct response—scaling up resources—reflects best practices in chaos engineering. While a 502 error *can* be a genuine problem, it's frequently a symptom of increased load or temporary infrastructure issues. Immediately killing the experiment without investigation risks prematurely halting valuable data collection and potentially masking an important real-time performance bottleneck. Options A and D represent overly cautious responses that don't align with the iterative nature of chaos experiments; option C is also incorrect as 502 errors are *part* of the experiment, not automatically resolved.
10 / 21
PR Description
Subject: Injecting latency to test API performance
Body:
We're running a chaos experiment to simulate network congestion and assess the impact on our user-facing API. The goal is to observe how the system handles increased latency under load. We've introduced a synthetic, intermittent delay of 100ms using curl --silent --writeout %{time}, targeting the authentication service. Please review and approve before deploying.
What does the phrase 'synthetic delay' imply in this context?
The key here is understanding 'synthetic'. This phrase means an artificially created delay—in this case, using `curl` to mimic network latency. The description explicitly states it's for testing and doesn't imply a real network issue or hardware problem. Option A is incorrect because synthetic delays are *not* caused by natural slowdowns; they are deliberately introduced. Options C and D are also incorrect as a synthetic delay isn't a permanent configuration or a hardware malfunction.
11 / 21
Liam: "We're using a tool called `Chaos Monkey` to randomly kill servers in our production environment. This helps us identify weaknesses and improve our resilience."
Chloe (in a PR description for a new experiment): "Introducing intermittent 300ms latency to the payment service via a custom script."
What does Chloe's statement primarily aim to achieve?
Chloe's statement focuses on introducing a controlled disruption – this is the core principle of chaos engineering. 'Chaos Monkey' typically refers to random server termination; Chloe's action demonstrates a deliberate attempt to test resilience under specific conditions. The goal isn't simply to break things, but to observe and understand how the system responds to unexpected delays, mimicking real-world latency issues and validating recovery mechanisms. Option A is incorrect as it describes a different strategy; option C is too broad; and option D is completely misaligned with the purpose of chaos experiments.
12 / 21
Sarah: "Hey team, I'm running a chaos experiment to test the resilience of our API gateway. It's currently injecting intermittent 502 errors."
Mark (in a Slack channel): "Sounds risky! Should we just kill the experiment?"
The correct response—scaling up resources—reflects best practices in chaos engineering. While a 502 error *can* be a genuine problem, it's frequently a symptom of increased load or temporary infrastructure issues. Immediately killing the experiment without investigation risks prematurely halting valuable data collection and potentially masking an important real-time performance bottleneck. Options A and D represent overly cautious responses that don't align with the iterative nature of chaos experiments; option C is also incorrect as 502 errors are *part* of the experiment, not automatically resolved.
13 / 21
PR Description
Subject: Injecting latency to test API performance
Body:
We're running a chaos experiment to simulate network congestion and assess the impact on our user-facing API. The goal is to observe how the system handles increased latency under load. We've introduced a synthetic, intermittent delay of 100ms using curl --silent --writeout %{time}, targeting the authentication service. Please review and approve before deploying.
What does the phrase 'synthetic delay' imply in this context?
The key here is understanding 'synthetic'. This phrase means an artificially created delay—in this case, using `curl` to mimic network latency. The description explicitly states it's for testing and doesn't imply a real network issue or hardware problem. Option A is incorrect because synthetic delays are *not* caused by natural slowdowns; they are deliberately introduced. Options C and D are also incorrect as a synthetic delay isn't a permanent configuration or a hardware malfunction.
14 / 21
Liam: "We're using a tool called `Chaos Monkey` to randomly kill servers in our production environment. This helps us identify weaknesses and improve our resilience."
Chloe (in a PR description for a new experiment): "Introducing intermittent 300ms latency to the payment service via a custom script."
What does Chloe's statement primarily aim to achieve?
Chloe's statement focuses on introducing a controlled disruption – this is the core principle of chaos engineering. 'Chaos Monkey' typically refers to random server termination; Chloe's action demonstrates a deliberate attempt to test resilience under specific conditions. The goal isn't simply to break things, but to observe and understand how the system responds to unexpected delays, mimicking real-world latency issues and validating recovery mechanisms. Option A is incorrect as it describes a different strategy; option C is too broad; and option D is completely misaligned with the purpose of chaos experiments.
15 / 21
Sarah: "Hey team, I'm running a chaos experiment to test the resilience of our API gateway. It's currently injecting intermittent 502 errors."
Mark (in a Slack channel): "Sounds risky! Should we just kill the experiment?"
The correct response—scaling up resources—reflects best practices in chaos engineering. While a 502 error *can* be a genuine problem, it's frequently a symptom of increased load or temporary infrastructure issues. Immediately killing the experiment without investigation risks prematurely halting valuable data collection and potentially masking an important real-time performance bottleneck. Options A and D represent overly cautious responses that don't align with the iterative nature of chaos experiments; option C is also incorrect as 502 errors are *part* of the experiment, not automatically resolved.
16 / 21
PR Description
Subject: Injecting latency to test API performance
Body:
We're running a chaos experiment to simulate network congestion and assess the impact on our user-facing API. The goal is to observe how the system handles increased latency under load. We've introduced a synthetic, intermittent delay of 100ms using curl --silent --writeout %{time}, targeting the authentication service. Please review and approve before deploying.
What does the phrase 'synthetic delay' imply in this context?
The key here is understanding 'synthetic'. This phrase means an artificially created delay—in this case, using `curl` to mimic network latency. The description explicitly states it's for testing and doesn't imply a real network issue or hardware problem. Option A is incorrect because synthetic delays are *not* caused by natural slowdowns; they are deliberately introduced. Options C and D are also incorrect as a synthetic delay isn't a permanent configuration or a hardware malfunction.
17 / 21
Liam: "We're using a tool called `Chaos Monkey` to randomly kill servers in our production environment. This helps us identify weaknesses and improve our resilience."
Chloe (in a PR description for a new experiment): "Introducing intermittent 300ms latency to the payment service via a custom script."
What does Chloe's statement primarily aim to achieve?
Chloe's statement focuses on introducing a controlled disruption – this is the core principle of chaos engineering. 'Chaos Monkey' typically refers to random server termination; Chloe's action demonstrates a deliberate attempt to test resilience under specific conditions. The goal isn't simply to break things, but to observe and understand how the system responds to unexpected delays, mimicking real-world latency issues and validating recovery mechanisms. Option A is incorrect as it describes a different strategy; option C is too broad; and option D is completely misaligned with the purpose of chaos experiments.
18 / 21
// Code Review Comment
"This patch introduces intermittent 502 errors into the API gateway. While this is part of a chaos experiment, it's crucial to monitor error rates closely and have a rollback plan ready. The current logging isn't sufficient for rapid diagnosis."
This scenario tests understanding of how a code review comment relates to a chaos experiment. The key is that while the injected error *is* part of the experiment, proactive monitoring and robust logging are still vital for identifying problems quickly and ensuring the experiment's success. Option A is too drastic; option B is counterproductive; option C misses the point entirely.
19 / 21
"Hey @john_doe, our latency test in Production is spiking dramatically. The Chaos Monkey seems to be triggering a cascade of timeouts across the Order Processing service. Should we halt the experiment and revert?"
This scenario tests understanding of accepting and managing unexpected outcomes during a chaos experiment. Stopping immediately might mask valuable insights. The key here is acknowledging that 'chaos' by definition involves unpredictable behavior; investigation is crucial to determine if the spike represents a genuine vulnerability or simply a side effect of the injected disruption.
20 / 21
"During today's stand-up, Sarah reported that she's running a chaos experiment injecting intermittent 502 errors into the payment gateway. She mentioned they're monitoring error rates and have a rollback plan in place. Which of the following best summarizes her update?"
This question assesses the ability to concisely summarize complex information. Option 2 accurately captures the key details of Sarah's update – the experiment type, what's being monitored, and the rollback plan. The other options misrepresent or oversimplify the situation.
21 / 21
Code Review Comment
"The PR introduces a simulated failure condition – injecting latency – to test API performance. While the intention is valid, the current implementation lacks sufficient detail about the expected impact and monitoring strategy. Consider adding a section outlining key metrics to track (e.g., request latency percentiles, error rates) and how deviations from baseline will be addressed."
The original question focused solely on identifying problems. This response goes further by explaining *why* the initial comment was insufficient – it lacked concrete steps for monitoring. It also provides a constructive suggestion for improving the PR's clarity.
What will I practice in "Chaos in Production Vocabulary"?
This is a Chaos Engineering exercise set. It walks through 21 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 21 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.