Chaos Experiment Design Vocabulary
Master the vocabulary for designing and describing chaos experiments: hypothesis formulation, blast radius, steady state, fault injection, game day language, and chaos monkey terminology.
0 / 26 completed
1 / 26
Which sentence uses chaos experiment vocabulary correctly to describe a hypothesis?
A well-formed chaos hypothesis names the steady state in measurable terms, specifies the exact fault to be injected, and states the resilience mechanism expected to compensate. Vague predictions ('probably be fine') are not hypotheses — they cannot be falsified. The blast radius and kill switch are safety controls, not hypothesis content.
2 / 26
A colleague says: 'Let's limit the blast radius to 5% of traffic.' What are they communicating?
Blast radius control is a safety practice: rather than exposing all users to a potentially disruptive experiment, you route a small percentage of traffic through instances with the fault injected (the experiment group), keeping the rest unaffected (control group). This gives real-world resilience signal at minimal risk. Common mechanisms: percentage-based traffic routing, feature flags, canary deployments.
3 / 26
What is the correct way to use 'steady state' in a chaos engineering sentence?
Steady state must be verified BEFORE the experiment (baseline), monitored DURING (does it hold?), and verified AFTER (did it recover?). Steady state is always expressed as measurable metrics with specific thresholds — not subjective descriptions like 'servers are stable.' Absence of recent deployments is a precondition for the experiment, not a steady-state definition.
4 / 26
Which phrase correctly describes the action of introducing a failure in chaos engineering?
'We inject a fault' is the standard chaos engineering phrasing. The sentence should specify: what type of fault (packet loss, latency, error, resource exhaustion), the magnitude (30%), and the exact target (network link between two named services). This precision is important for reproducibility and for correlating observations with the specific fault condition.
5 / 26
What does 'chaos monkey language' typically refer to in team communication?
Chaos Monkey is Netflix's original tool for randomly terminating EC2 instances to test resilience. The 'Simian Army' extended this to a suite of tools (Latency Monkey, Conformity Monkey, Security Monkey). When practitioners say 'the chaos monkey took down two instances,' they are using the vocabulary of this tooling tradition. Understanding these terms helps when reading Netflix engineering blog posts and chaos engineering literature.
6 / 26
PR Description:
"We're introducing a new feature that directly integrates with the payment gateway. Initial tests show an average latency increase of 15ms under peak load. To investigate further, we'll be running a short chaos experiment where we simulate intermittent network disruptions to the gateway during this period. We expect this will highlight potential bottlenecks and inform our performance optimizations."The correct answer focuses on the clear articulation of the experiment's goals and anticipated effects. A crucial element of 'chaos experiment design vocabulary' is recognizing that a well-defined PR description should explicitly state what problems are being investigated with the chaos experiment, such as latency increases. The other options misinterpret the importance of framing the experiment's purpose within the context of understanding potential negative impacts – it's about identifying bottlenecks, not just running disruptions.
7 / 26
During a code review for the new user onboarding flow, Sarah says: 'I'm introducing a small chaos experiment – let's deliberately spike the latency on the authentication service to see how gracefully the system degrades. We should monitor the blast radius of this test and ensure it doesn't impact critical paths.' Which statement best reflects Sarah's approach?
Sarah correctly uses 'blast radius' to describe the potential impact of her experiment. The key here is that a 'blast radius' in chaos engineering refers to the range of systems affected by a failure – it's not just about latency numbers. A good hypothesis would explicitly state *what* she expects to observe (e.g., 'we hypothesize that increased authentication latency will lead to a spike in error rates on user registration'). This question tests understanding of how this vocabulary is used in a practical scenario, correcting the misconception that it's purely about technical metrics.
8 / 26
The core concept here is understanding how 'steady state' applies within the context of chaos engineering. It shouldn't be used as a description of *creating* an unstable condition; rather, it's the target state you observe after deliberately introducing instability. The other options misunderstand the roles of 'blast radius' and incorrectly apply 'steady state' to the experiment's setup.
9 / 26
Mark just commented: 'This latency increase is a good starting point for a controlled chaos experiment. Let's focus on maintaining a steady state of disruption – perhaps a sustained 20ms spike – to really stress-test the gateway's resilience.' Which element does Mark emphasize as crucial for this experiment?
Mark's comment highlights the importance of 'steady state' in chaos experiments. Maintaining a steady state – a consistent level of disruption – allows for accurate measurement and observation of system behavior under sustained stress. This contrasts with rapidly introducing and removing failures, which would obscure the true impact of the experiment. The goal is to observe how the system reacts to a prolonged condition.
10 / 26
PR Description:
"We're introducing a new feature that directly integrates with the payment gateway. Initial tests show an average latency increase of 15ms under peak load. To investigate further, we'll be running a short chaos experiment where we simulate intermittent network disruptions to the gateway during this period. We expect this will highlight potential bottlenecks and inform our performance optimizations."The correct answer focuses on the clear articulation of the experiment's goals and anticipated effects. A crucial element of 'chaos experiment design vocabulary' is recognizing that a well-defined PR description should explicitly state what problems are being investigated with the chaos experiment, such as latency increases. The other options misinterpret the importance of framing the experiment's purpose within the context of understanding potential negative impacts – it's about identifying bottlenecks, not just running disruptions.
11 / 26
During a code review for the new user onboarding flow, Sarah says: 'I'm introducing a small chaos experiment – let's deliberately spike the latency on the authentication service to see how gracefully the system degrades. We should monitor the blast radius of this test and ensure it doesn't impact critical paths.' Which statement best reflects Sarah's approach?
Sarah correctly uses 'blast radius' to describe the potential impact of her experiment. The key here is that a 'blast radius' in chaos engineering refers to the range of systems affected by a failure – it's not just about latency numbers. A good hypothesis would explicitly state *what* she expects to observe (e.g., 'we hypothesize that increased authentication latency will lead to a spike in error rates on user registration'). This question tests understanding of how this vocabulary is used in a practical scenario, correcting the misconception that it's purely about technical metrics.
12 / 26
The core concept here is understanding how 'steady state' applies within the context of chaos engineering. It shouldn't be used as a description of *creating* an unstable condition; rather, it's the target state you observe after deliberately introducing instability. The other options misunderstand the roles of 'blast radius' and incorrectly apply 'steady state' to the experiment's setup.
13 / 26
Mark just commented: 'This latency increase is a good starting point for a controlled chaos experiment. Let's focus on maintaining a steady state of disruption – perhaps a sustained 20ms spike – to really stress-test the gateway's resilience.' Which element does Mark emphasize as crucial for this experiment?
Mark's comment highlights the importance of 'steady state' in chaos experiments. Maintaining a steady state – a consistent level of disruption – allows for accurate measurement and observation of system behavior under sustained stress. This contrasts with rapidly introducing and removing failures, which would obscure the true impact of the experiment. The goal is to observe how the system reacts to a prolonged condition.
14 / 26
PR Description:
"We're introducing a new feature that directly integrates with the payment gateway. Initial tests show an average latency increase of 15ms under peak load. To investigate further, we'll be running a short chaos experiment where we simulate intermittent network disruptions to the gateway during this period. We expect this will highlight potential bottlenecks and inform our performance optimizations."The correct answer focuses on the clear articulation of the experiment's goals and anticipated effects. A crucial element of 'chaos experiment design vocabulary' is recognizing that a well-defined PR description should explicitly state what problems are being investigated with the chaos experiment, such as latency increases. The other options misinterpret the importance of framing the experiment's purpose within the context of understanding potential negative impacts – it's about identifying bottlenecks, not just running disruptions.
15 / 26
During a code review for the new user onboarding flow, Sarah says: 'I'm introducing a small chaos experiment – let's deliberately spike the latency on the authentication service to see how gracefully the system degrades. We should monitor the blast radius of this test and ensure it doesn't impact critical paths.' Which statement best reflects Sarah's approach?
Sarah correctly uses 'blast radius' to describe the potential impact of her experiment. The key here is that a 'blast radius' in chaos engineering refers to the range of systems affected by a failure – it's not just about latency numbers. A good hypothesis would explicitly state *what* she expects to observe (e.g., 'we hypothesize that increased authentication latency will lead to a spike in error rates on user registration'). This question tests understanding of how this vocabulary is used in a practical scenario, correcting the misconception that it's purely about technical metrics.
16 / 26
The core concept here is understanding how 'steady state' applies within the context of chaos engineering. It shouldn't be used as a description of *creating* an unstable condition; rather, it's the target state you observe after deliberately introducing instability. The other options misunderstand the roles of 'blast radius' and incorrectly apply 'steady state' to the experiment's setup.
17 / 26
Mark just commented: 'This latency increase is a good starting point for a controlled chaos experiment. Let's focus on maintaining a steady state of disruption – perhaps a sustained 20ms spike – to really stress-test the gateway's resilience.' Which element does Mark emphasize as crucial for this experiment?
Mark's comment highlights the importance of 'steady state' in chaos experiments. Maintaining a steady state – a consistent level of disruption – allows for accurate measurement and observation of system behavior under sustained stress. This contrasts with rapidly introducing and removing failures, which would obscure the true impact of the experiment. The goal is to observe how the system reacts to a prolonged condition.
18 / 26
PR Description:
"We're introducing a new feature that directly integrates with the payment gateway. Initial tests show an average latency increase of 15ms under peak load. To investigate further, we'll be running a short chaos experiment where we simulate intermittent network disruptions to the gateway during this period. We expect this will highlight potential bottlenecks and inform our performance optimizations."The correct answer focuses on the clear articulation of the experiment's goals and anticipated effects. A crucial element of 'chaos experiment design vocabulary' is recognizing that a well-defined PR description should explicitly state what problems are being investigated with the chaos experiment, such as latency increases. The other options misinterpret the importance of framing the experiment's purpose within the context of understanding potential negative impacts – it's about identifying bottlenecks, not just running disruptions.
19 / 26
During a code review for the new user onboarding flow, Sarah says: 'I'm introducing a small chaos experiment – let's deliberately spike the latency on the authentication service to see how gracefully the system degrades. We should monitor the blast radius of this test and ensure it doesn't impact critical paths.' Which statement best reflects Sarah's approach?
Sarah correctly uses 'blast radius' to describe the potential impact of her experiment. The key here is that a 'blast radius' in chaos engineering refers to the range of systems affected by a failure – it's not just about latency numbers. A good hypothesis would explicitly state *what* she expects to observe (e.g., 'we hypothesize that increased authentication latency will lead to a spike in error rates on user registration'). This question tests understanding of how this vocabulary is used in a practical scenario, correcting the misconception that it's purely about technical metrics.
20 / 26
The core concept here is understanding how 'steady state' applies within the context of chaos engineering. It shouldn't be used as a description of *creating* an unstable condition; rather, it's the target state you observe after deliberately introducing instability. The other options misunderstand the roles of 'blast radius' and incorrectly apply 'steady state' to the experiment's setup.
21 / 26
Mark just commented: 'This latency increase is a good starting point for a controlled chaos experiment. Let's focus on maintaining a steady state of disruption – perhaps a sustained 20ms spike – to really stress-test the gateway's resilience.' Which element does Mark emphasize as crucial for this experiment?
Mark's comment highlights the importance of 'steady state' in chaos experiments. Maintaining a steady state – a consistent level of disruption – allows for accurate measurement and observation of system behavior under sustained stress. This contrasts with rapidly introducing and removing failures, which would obscure the true impact of the experiment. The goal is to observe how the system reacts to a prolonged condition.
22 / 26
During a standup update, Alex says: 'We're running a chaos experiment to assess the blast radius of the new API gateway integration. We've intentionally introduced a 30ms latency spike and are monitoring for cascading failures across dependent services. Which of these best describes the primary focus of this experiment?',
The core purpose of a 'blast radius' experiment is to determine which downstream services are affected by an initial disruption. This question directly addresses Alex's statement about monitoring for cascading failures – that's precisely what 'blast radius' refers to in this context. Option A incorrectly frames the issue as traffic volume; blast radius describes the *reach* of the problem, not just load.
23 / 26
In a Slack channel discussing a proposed chaos experiment on the order management system, Ben proposes: 'Let's establish a steady state of 10ms latency increase. We should then observe the system's behavior over a period of 60 minutes to gauge its resilience. What does 'steady state' primarily mean in this scenario?',
'Steady state' in chaos engineering refers to a consistent condition – in this case, a maintained 10ms latency. This allows for reliable measurement and observation of the system's response over an extended timeframe without the influence of fluctuating variables. Option A misinterprets 'steady state'; it doesn't mean *no* change, but rather a predictable, stable one.
24 / 26
Reviewing a PR for a new feature that adds a rate limiting component to the user authentication service, Emily comments: 'I'm introducing a small chaos experiment – let's deliberately increase the request rate by 2x to see how gracefully the system degrades. We need to carefully monitor the blast radius of this increased load.' What is Emily primarily trying to achieve with this experiment?
Emily's experiment is designed to stress-test the authentication service and determine its capacity. By intentionally increasing the load (2x), she's trying to reveal any bottlenecks or limitations in the system's ability to handle higher traffic – this is directly related to 'blast radius'. Option A misses the point of a chaos experiment; it's about *understanding* the impact, not just testing one component.
25 / 26
During a code review discussion, David says: 'We're running a controlled chaos experiment on the payment processing service. We've implemented a synthetic attack that simulates a sudden spike in transaction volume – approximately 50% above normal. The goal is to observe the system's steady state behavior under this load.' Which of the following best describes the relationship between 'synthetic attack' and 'steady state'?
A 'synthetic attack' deliberately introduces a disruptive element (the 50% spike). The 'steady state' observation is then made *after* this temporary condition has been applied. This allows engineers to see how the system recovers and behaves under sustained load – it's about measuring the system's resilience after the initial disruption, not the disruption itself.
26 / 26
In a Slack message regarding a planned chaos experiment on the recommendation engine, Sarah writes: 'Let's introduce a hypothesis that increasing latency by 20ms will reveal potential issues with caching. We'll monitor for a steady state of this increased latency and observe any changes in user behavior metrics such as click-through rates.' What is Sarah primarily attempting to achieve through this experiment?
Sarah's experiment is driven by a specific *hypothesis* (latency impacting caching). She's establishing a controlled condition (20ms latency) and then observing the system's behavior – particularly user metrics – to see if her hypothesis holds true. This aligns with the core principle of chaos experiments: testing assumptions under simulated stress.
Frequently Asked Questions
What will I practice in "Chaos Experiment Design Vocabulary — Hypothesis, Blast Radius, Steady State"?
This is a Chaos Engineering exercise set. It walks through 26 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 26 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.