Chaos Experiment Design — Vocabulary and Language
Learn vocabulary for designing chaos experiments: steady-state hypothesis, blast radius, fault injection, and experiment scope.
0 / 30 completed
1 / 30
What is a 'steady-state hypothesis' in chaos engineering?
Steady-state hypothesis (from Chaos Engineering principles): define normal behavior in measurable terms BEFORE the experiment — e.g., 'p99 latency < 200ms and error rate < 0.1%.' The experiment then verifies the steady state holds under the chaos condition. If it does not, the system is not resilient to that failure.
2 / 30
What is 'blast radius' in chaos engineering vocabulary?
Blast radius is a key safety concept in chaos engineering: how many users/services/systems could be affected if this experiment goes wrong? You minimize blast radius by starting in non-production, limiting experiments to a small percentage of traffic, using feature flags to target a subset of users, and having easy kill switches.
3 / 30
What does 'start in production but small' mean in chaos engineering vocabulary?
Chaos engineering principle: staging environments rarely accurately represent production load, dependencies, and behavior. Starting in production (with minimal blast radius) gives more accurate resilience signal. Use canary deployments, percentage-based traffic routing, or dark traffic to limit initial scope.
4 / 30
What is a 'kill switch' (or abort condition) in chaos engineering?
Every chaos experiment must have a kill switch: a clear abort condition ('if error rate exceeds 1% or p99 latency exceeds 500ms, stop the experiment immediately') and a mechanism to stop it quickly — typically an automated monitor and a manual kill button. This is a safety prerequisite for chaos experiments in production.
5 / 30
What is 'fault injection' in chaos engineering vocabulary?
Fault injection is the core technical mechanism of chaos engineering: programmatically introducing specific failures to test how a system responds. Types: latency injection (slow a dependency), error injection (make a dependency return 500 errors), resource exhaustion (fill disk, spike CPU), network partition (block traffic between services).
6 / 30
PR Description:
"Running automated tests failed after deploying version 1.2. I'm investigating a potential issue with the new authentication service. It seems like requests to the /users endpoint are timing out intermittently."This scenario presents a realistic PR description. The question tests understanding of how chaos engineering concepts – like observing unexpected behavior – are discussed in practical contexts. Options A and B represent misunderstandings; a chaotic deployment doesn't justify ignoring errors, and a code review comment isn't inherently about chaos experiments. Option D is too vague; the description *does* contain relevant information for investigating potential issues related to a controlled experiment.
7 / 30
Sarah: "Hey team, I'm running a small experiment to test the resilience of our payment service. I've introduced a simulated network latency of 50ms on requests hitting the transaction processing module. We'll monitor error rates and response times closely – this is purely for observation."This describes 'fault injection', a key component of chaos engineering. It's not simply monitoring existing issues; instead, it's actively introducing artificial problems – in this case, network latency – to see how the system behaves under stress. The goal is to proactively discover vulnerabilities and strengthen resilience, not to cause disruption for its own sake.
8 / 30
Mark has commented in the PR: "I'm going to introduce some *unexpected* load into our system using a tool called `Chaos Mesh`. Specifically, I'll be triggering intermittent failures on the database servers – essentially simulating a degraded state. This should help us understand how gracefully our application handles these situations and identify any bottlenecks."
Which of the following best describes Mark's approach?Mark is employing a technique called 'chaos engineering,' specifically *fault injection*. He's deliberately introducing failures – in this case, intermittent database server outages – to observe the system's behavior under stress. This isn't about fixing bugs or optimizing performance; it's a proactive method of uncovering vulnerabilities and understanding resilience. The key concept here is testing how the system responds to *unexpected* conditions, which aligns with chaos engineering principles.
9 / 30
Mark is using a technique called 'fault injection' to proactively test the system's resilience. He's intentionally creating failures – in this case, intermittent database server outages – to observe how the application responds.
Which of the following best captures Mark's strategy?
Which of the following best captures Mark's strategy?
Mark's actions directly align with fault injection. This involves deliberately introducing faults (like database server failures) into the system to see how it behaves under stress. The goal isn't simply performance testing or breaking the system; it's about understanding and validating the system's ability to recover gracefully – a key aspect of chaos engineering. Introducing overwhelming load would be considered a different, potentially destructive technique.
10 / 30
PR Description:
"Running automated tests failed after deploying version 1.2. I'm investigating a potential issue with the new authentication service. It seems like requests to the /users endpoint are timing out intermittently."This scenario presents a realistic PR description. The question tests understanding of how chaos engineering concepts – like observing unexpected behavior – are discussed in practical contexts. Options A and B represent misunderstandings; a chaotic deployment doesn't justify ignoring errors, and a code review comment isn't inherently about chaos experiments. Option D is too vague; the description *does* contain relevant information for investigating potential issues related to a controlled experiment.
11 / 30
Sarah: "Hey team, I'm running a small experiment to test the resilience of our payment service. I've introduced a simulated network latency of 50ms on requests hitting the transaction processing module. We'll monitor error rates and response times closely – this is purely for observation."This describes 'fault injection', a key component of chaos engineering. It's not simply monitoring existing issues; instead, it's actively introducing artificial problems – in this case, network latency – to see how the system behaves under stress. The goal is to proactively discover vulnerabilities and strengthen resilience, not to cause disruption for its own sake.
12 / 30
Mark has commented in the PR: "I'm going to introduce some *unexpected* load into our system using a tool called `Chaos Mesh`. Specifically, I'll be triggering intermittent failures on the database servers – essentially simulating a degraded state. This should help us understand how gracefully our application handles these situations and identify any bottlenecks."
Which of the following best describes Mark's approach?Mark is employing a technique called 'chaos engineering,' specifically *fault injection*. He's deliberately introducing failures – in this case, intermittent database server outages – to observe the system's behavior under stress. This isn't about fixing bugs or optimizing performance; it's a proactive method of uncovering vulnerabilities and understanding resilience. The key concept here is testing how the system responds to *unexpected* conditions, which aligns with chaos engineering principles.
13 / 30
Mark is using a technique called 'fault injection' to proactively test the system's resilience. He's intentionally creating failures – in this case, intermittent database server outages – to observe how the application responds.
Which of the following best captures Mark's strategy?
Which of the following best captures Mark's strategy?
Mark's actions directly align with fault injection. This involves deliberately introducing faults (like database server failures) into the system to see how it behaves under stress. The goal isn't simply performance testing or breaking the system; it's about understanding and validating the system's ability to recover gracefully – a key aspect of chaos engineering. Introducing overwhelming load would be considered a different, potentially destructive technique.
14 / 30
PR Description:
"Running automated tests failed after deploying version 1.2. I'm investigating a potential issue with the new authentication service. It seems like requests to the /users endpoint are timing out intermittently."This scenario presents a realistic PR description. The question tests understanding of how chaos engineering concepts – like observing unexpected behavior – are discussed in practical contexts. Options A and B represent misunderstandings; a chaotic deployment doesn't justify ignoring errors, and a code review comment isn't inherently about chaos experiments. Option D is too vague; the description *does* contain relevant information for investigating potential issues related to a controlled experiment.
15 / 30
Sarah: "Hey team, I'm running a small experiment to test the resilience of our payment service. I've introduced a simulated network latency of 50ms on requests hitting the transaction processing module. We'll monitor error rates and response times closely – this is purely for observation."This describes 'fault injection', a key component of chaos engineering. It's not simply monitoring existing issues; instead, it's actively introducing artificial problems – in this case, network latency – to see how the system behaves under stress. The goal is to proactively discover vulnerabilities and strengthen resilience, not to cause disruption for its own sake.
16 / 30
Mark has commented in the PR: "I'm going to introduce some *unexpected* load into our system using a tool called `Chaos Mesh`. Specifically, I'll be triggering intermittent failures on the database servers – essentially simulating a degraded state. This should help us understand how gracefully our application handles these situations and identify any bottlenecks."
Which of the following best describes Mark's approach?Mark is employing a technique called 'chaos engineering,' specifically *fault injection*. He's deliberately introducing failures – in this case, intermittent database server outages – to observe the system's behavior under stress. This isn't about fixing bugs or optimizing performance; it's a proactive method of uncovering vulnerabilities and understanding resilience. The key concept here is testing how the system responds to *unexpected* conditions, which aligns with chaos engineering principles.
17 / 30
Mark is using a technique called 'fault injection' to proactively test the system's resilience. He's intentionally creating failures – in this case, intermittent database server outages – to observe how the application responds.
Which of the following best captures Mark's strategy?
Which of the following best captures Mark's strategy?
Mark's actions directly align with fault injection. This involves deliberately introducing faults (like database server failures) into the system to see how it behaves under stress. The goal isn't simply performance testing or breaking the system; it's about understanding and validating the system's ability to recover gracefully – a key aspect of chaos engineering. Introducing overwhelming load would be considered a different, potentially destructive technique.
18 / 30
PR Description:
"Running automated tests failed after deploying version 1.2. I'm investigating a potential issue with the new authentication service. It seems like requests to the /users endpoint are timing out intermittently."This scenario presents a realistic PR description. The question tests understanding of how chaos engineering concepts – like observing unexpected behavior – are discussed in practical contexts. Options A and B represent misunderstandings; a chaotic deployment doesn't justify ignoring errors, and a code review comment isn't inherently about chaos experiments. Option D is too vague; the description *does* contain relevant information for investigating potential issues related to a controlled experiment.
19 / 30
Sarah: "Hey team, I'm running a small experiment to test the resilience of our payment service. I've introduced a simulated network latency of 50ms on requests hitting the transaction processing module. We'll monitor error rates and response times closely – this is purely for observation."This describes 'fault injection', a key component of chaos engineering. It's not simply monitoring existing issues; instead, it's actively introducing artificial problems – in this case, network latency – to see how the system behaves under stress. The goal is to proactively discover vulnerabilities and strengthen resilience, not to cause disruption for its own sake.
20 / 30
Mark has commented in the PR: "I'm going to introduce some *unexpected* load into our system using a tool called `Chaos Mesh`. Specifically, I'll be triggering intermittent failures on the database servers – essentially simulating a degraded state. This should help us understand how gracefully our application handles these situations and identify any bottlenecks."
Which of the following best describes Mark's approach?Mark is employing a technique called 'chaos engineering,' specifically *fault injection*. He's deliberately introducing failures – in this case, intermittent database server outages – to observe the system's behavior under stress. This isn't about fixing bugs or optimizing performance; it's a proactive method of uncovering vulnerabilities and understanding resilience. The key concept here is testing how the system responds to *unexpected* conditions, which aligns with chaos engineering principles.
21 / 30
Mark is using a technique called 'fault injection' to proactively test the system's resilience. He's intentionally creating failures – in this case, intermittent database server outages – to observe how the application responds.
Which of the following best captures Mark's strategy?
Which of the following best captures Mark's strategy?
Mark's actions directly align with fault injection. This involves deliberately introducing faults (like database server failures) into the system to see how it behaves under stress. The goal isn't simply performance testing or breaking the system; it's about understanding and validating the system's ability to recover gracefully – a key aspect of chaos engineering. Introducing overwhelming load would be considered a different, potentially destructive technique.
22 / 30
Reviewer: "This change introduces a 'chaos experiment' – injecting simulated network latency. While the goal is good, consider using more precise terminology like 'latency injection' or 'network stress testing'. It's crucial to clearly document the expected impact of this latency on downstream services."The reviewer's comment correctly identifies that 'chaos experiment' is an imprecise term. They appropriately suggest more descriptive alternatives like 'latency injection' or 'network stress testing', and importantly emphasize the need for clear documentation of expected impacts. This demonstrates a deeper understanding of the context than simply pointing out a problem without offering solutions.
23 / 30
Alex: "Hey team, I'm running a small experiment to simulate a database server outage using Chaos Mesh. Specifically, I've configured it to randomly drop connections every 60 seconds for the next hour. We should monitor CPU and memory usage on the application servers as key metrics.
/monitor chaos-mesh-outageThe Slack message effectively communicates the core elements of the chaos experiment: the tool (Chaos Mesh), the injected failure (random connection drops), the duration (one hour), and the key metrics for monitoring. It's a concise and actionable update.
24 / 30
"Implementing fault injection to test API resilience. We've introduced a 50ms latency simulation on requests to the /products endpoint using a custom script. This will help us identify performance bottlenecks under simulated load. Monitoring metrics include response time and error rates.
// Script: latency_injector.pyThis PR description provides a clear overview of the chaos experiment. It details the technique (fault injection), the tool used (a custom script), the target API endpoint (/products), and the relevant metrics for assessing performance. The key is that it's understandable to someone unfamiliar with the specific implementation.
25 / 30
"I'm conducting a 'chaos experiment' focused on simulating a network partition affecting our user authentication service. I've introduced intermittent packet loss with a 20% probability using a tool that mimics real-world network conditions. We are tracking login success rates and error codes during this simulation to identify potential vulnerabilities."
This standup update succinctly describes a chaos experiment. It clearly states the objective (network partition simulation), the method (intermittent packet loss with a probability), and the key metrics being monitored (login success/error). A good standup update focuses on what was done, what's being monitored, and why.
26 / 30
The API returns the following error message after a 'chaos experiment' triggered by Chaos Mesh: `{"code": 503, "message": "Service Unavailable - Temporary Failure"}`. What does this primarily indicate about the system's state?
The HTTP status code 503 (Service Unavailable) combined with the message 'Temporary Failure' strongly suggests that the system is experiencing a transient disruption due to the injected failure by Chaos Mesh. The response accurately reflects this situation.
27 / 30
Reviewer: "This pull request introduces a 'chaos experiment' – injecting simulated network latency. While the intent is valuable, using terms like 'latency injection' or 'network stress testing' provides more clarity and aligns with industry best practices for documenting these types of tests. Consider revising the comment to reflect this."
The reviewer's feedback highlights the importance of precise language in technical documentation. Using standard terms like 'latency injection' or 'network stress testing' improves clarity and professionalism when describing a chaos experiment. The incorrect options misinterpret the reviewer's primary concern – the terminology itself – rather than the underlying test methodology.
28 / 30
During a 'chaos experiment' designed to simulate database failures, the team observed intermittent errors related to transaction rollbacks. The API returned the following message: `{"code": 400, "message": "Bad Request - Transaction Rollback Failed"}`. What is the most likely cause of this error?
The API response indicates a 'Bad Request' due to a failed transaction rollback. This strongly suggests that there's an error in the application code responsible for handling rollbacks – perhaps incorrect parameters or logic errors are causing it to fail when the database experiences temporary issues during the experiment. Options A, C and D represent other potential causes of database failures.
29 / 30
Sarah is using Chaos Mesh to inject latency into requests to her e-commerce platform's product catalog service. She's configured a delay of 75ms for 90% of requests. A code review comment reads: "This experiment could benefit from more precise terminology – consider 'latency injection testing' instead of just 'chaos experiment'."
While 'chaos experiment' provides a general idea, 'latency injection testing' offers greater precision and aligns with standard terminology in performance testing. Using less specific terms like 'chaos' can obscure the true nature of the test. This demonstrates the importance of clear communication and using appropriate technical vocabulary.
30 / 30
Mark is running a chaos experiment to simulate network partitions affecting his payment service. He's monitoring metrics showing a sudden spike in HTTP 503 errors. The Chaos Mesh configuration involves randomly dropping packets with a 30% probability. Which of the following best describes what's happening?
A spike in 503 errors during a network partition simulation indicates that the backend infrastructure of the payment service cannot handle the increased load and error rates caused by the simulated disruption. This aligns with how services typically respond when faced with temporary unavailability or increased traffic due to a failure.
Frequently Asked Questions
What will I practice in "Chaos Experiment Design — Vocabulary and Language"?
This is a Chaos Engineering exercise set. It walks through 30 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 30 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.