Chaos Engineering Tools — Vocabulary
Learn vocabulary for Chaos Monkey, Gremlin, AWS FIS, LitmusChaos, ChaosBlade, and runbook-as-code concepts.
0 / 26 completed
1 / 26
What is Chaos Monkey in chaos engineering vocabulary?
Chaos Monkey (Netflix, 2010): one of the original chaos engineering tools. Randomly kills EC2 instances during business hours to ensure Netflix engineers build services that tolerate instance failure. Part of the Simian Army (a collection of chaos tools). Key vocabulary: 'opt-in chaos,' 'random termination,' 'resilience validation.' Chaos Monkey is intentionally simple — it does one thing (terminate instances) well.
2 / 26
What distinguishes Gremlin from open-source chaos tools in the vocabulary?
Gremlin vocabulary: 'attack' (a specific chaos fault), 'attack catalog' (library of fault types), 'target' (which hosts/containers to attack), 'scenario' (composed multi-step experiment). Gremlin's differentiators: broad fault library, halt button (stop all attacks instantly), RBAC, compliance reporting, and integrations with PagerDuty/Datadog. Compared to DIY tools, Gremlin reduces the engineering overhead of building and operating chaos infrastructure.
3 / 26
What is AWS Fault Injection Simulator (FIS) in chaos engineering vocabulary?
AWS FIS vocabulary: 'experiment template' (defines targets, actions, stop conditions), 'action' (specific fault: aws:ec2:terminate-instances, aws:rds:failover-db-cluster), 'stop condition' (CloudWatch alarm that halts the experiment if metrics breach a threshold), 'target' (resource filter by tag/ARN/percent). FIS is tightly integrated with AWS — no agents needed for most AWS resource faults. Pairs well with CloudWatch dashboards for observing experiment impact.
4 / 26
What is LitmusChaos in the Kubernetes chaos engineering vocabulary?
LitmusChaos vocabulary: ChaosHub (catalog of pre-built experiments), ChaosEngine (links application to experiment), ChaosExperiment (defines the fault), ChaosResult (records outcome). Kubernetes-native: experiments are declared as YAML CRDs and executed by chaos operators. Supports pod-level faults (kill, CPU hog, memory hog), node faults (drain, taint), and network faults (packet loss, latency). CNCF sandbox project with active community.
5 / 26
What is 'runbook-as-code' in chaos engineering vocabulary?
Runbook-as-code extends infrastructure-as-code principles to operational procedures: experiment definitions, hypothesis, target scope, stop conditions, rollback steps, and expected outcomes are all stored in version control alongside application code. Tools like Gremlin scenarios, AWS FIS templates, or Litmus ChaosEngine YAMLs implement this. Benefits: peer review via pull requests, repeatability, audit trail, CI/CD integration for automated resilience testing.
6 / 26
PR Description:
"We're injecting latency into the API gateway using Chaos Mesh to simulate a DDoS attack. This will help us validate our auto-scaling configuration and identify potential bottlenecks under load. We've deployed chaos-mesh-worker with the --duration 60s --latency 50ms flags."This question tests understanding of practical application. While deploying
chaos-mesh-worker with flags is a common starting point, the core purpose isn't just increasing latency. The correct answer highlights the intended use: validating auto-scaling and identifying bottlenecks under simulated load. Option A misinterprets latency injection as a simple fix; option C suggests an incorrect method for achieving this goal.7 / 26
Reviewer: 'I noticed you're using Chaos Mesh to introduce intermittent failures. While the intention is good – testing resilience – are you documenting the specific failure modes you're targeting? Specifically, what *types* of chaos experiments are you running and why? This will help us understand the scope of the test and ensure it aligns with our overall risk tolerance.
Slack Message from a team member: 'Yeah, we're using Chaos Mesh to simulate network partitions. The goal is to see how quickly the services recover.'The question focuses on the crucial aspect of *intent* within chaos engineering. Simply introducing failures (option A) isn't sufficient; it needs to be a targeted experiment. The correct answer highlights that simulating network partitions with Chaos Mesh is valid, but importantly, documenting *what types* of failures are being tested and why (e.g., testing circuit breaker behavior or data consistency) is essential for effective risk management and demonstrating the value of the chaos engineering effort. Options B and C miss this critical element of strategic experimentation, while option D misinterprets the purpose of Slack communication.
8 / 26
Reviewer: 'I'm seeing you've deployed Kitchen Betty to trigger cascading failures in our backend services. While the aim is to test our recovery strategies, it seems like we haven't defined a clear *scope* for these tests. Specifically, are we focusing on simulating specific failure patterns – like database outages or message queue congestion – and what metrics are we using to measure success? Without this context, it's difficult to assess the effectiveness of the experiment.'
Which of the following best describes the reviewer's concern regarding Kitchen Betty deployment?The reviewer isn't just questioning the use of Kitchen Betty; they're critically examining *how* it's being used. The core concern is the lack of defined scope – specifically, what types of failures are being simulated and how success is measured. This highlights a crucial aspect of chaos engineering: not just injecting chaos, but understanding *what* chaos you're introducing and *why*, tying it back to measurable outcomes like recovery time or service availability.
9 / 26
During a code review of a pull request introducing Chaos Mesh to simulate service degradation, the reviewer asks: 'Are you documenting the specific failure modes you're targeting with this experiment? What types of chaos are you running and why?' The reviewer's primary concern is about context. Which option best reflects that concern?
The reviewer isn't primarily focused on whether the code *works* after injecting chaos (option A). Instead, they're demanding context around *why* that chaos is being injected. The specific configuration details (latency) are secondary to understanding the overall strategy and its justification (option B). The core issue is a lack of defined scope and objectives—what types of failures are intentionally simulated and what constitutes success—which directly relates to risk tolerance and alignment with broader resilience goals (option C). Option D misinterprets the review's focus, suggesting performance metrics should outweigh strategic considerations.
10 / 26
PR Description:
"We're injecting latency into the API gateway using Chaos Mesh to simulate a DDoS attack. This will help us validate our auto-scaling configuration and identify potential bottlenecks under load. We've deployed chaos-mesh-worker with the --duration 60s --latency 50ms flags."This question tests understanding of practical application. While deploying
chaos-mesh-worker with flags is a common starting point, the core purpose isn't just increasing latency. The correct answer highlights the intended use: validating auto-scaling and identifying bottlenecks under simulated load. Option A misinterprets latency injection as a simple fix; option C suggests an incorrect method for achieving this goal.11 / 26
Reviewer: 'I noticed you're using Chaos Mesh to introduce intermittent failures. While the intention is good – testing resilience – are you documenting the specific failure modes you're targeting? Specifically, what *types* of chaos experiments are you running and why? This will help us understand the scope of the test and ensure it aligns with our overall risk tolerance.
Slack Message from a team member: 'Yeah, we're using Chaos Mesh to simulate network partitions. The goal is to see how quickly the services recover.'The question focuses on the crucial aspect of *intent* within chaos engineering. Simply introducing failures (option A) isn't sufficient; it needs to be a targeted experiment. The correct answer highlights that simulating network partitions with Chaos Mesh is valid, but importantly, documenting *what types* of failures are being tested and why (e.g., testing circuit breaker behavior or data consistency) is essential for effective risk management and demonstrating the value of the chaos engineering effort. Options B and C miss this critical element of strategic experimentation, while option D misinterprets the purpose of Slack communication.
12 / 26
Reviewer: 'I'm seeing you've deployed Kitchen Betty to trigger cascading failures in our backend services. While the aim is to test our recovery strategies, it seems like we haven't defined a clear *scope* for these tests. Specifically, are we focusing on simulating specific failure patterns – like database outages or message queue congestion – and what metrics are we using to measure success? Without this context, it's difficult to assess the effectiveness of the experiment.'
Which of the following best describes the reviewer's concern regarding Kitchen Betty deployment?The reviewer isn't just questioning the use of Kitchen Betty; they're critically examining *how* it's being used. The core concern is the lack of defined scope – specifically, what types of failures are being simulated and how success is measured. This highlights a crucial aspect of chaos engineering: not just injecting chaos, but understanding *what* chaos you're introducing and *why*, tying it back to measurable outcomes like recovery time or service availability.
13 / 26
During a code review of a pull request introducing Chaos Mesh to simulate service degradation, the reviewer asks: 'Are you documenting the specific failure modes you're targeting with this experiment? What types of chaos are you running and why?' The reviewer's primary concern is about context. Which option best reflects that concern?
The reviewer isn't primarily focused on whether the code *works* after injecting chaos (option A). Instead, they're demanding context around *why* that chaos is being injected. The specific configuration details (latency) are secondary to understanding the overall strategy and its justification (option B). The core issue is a lack of defined scope and objectives—what types of failures are intentionally simulated and what constitutes success—which directly relates to risk tolerance and alignment with broader resilience goals (option C). Option D misinterprets the review's focus, suggesting performance metrics should outweigh strategic considerations.
14 / 26
PR Description:
"We're injecting latency into the API gateway using Chaos Mesh to simulate a DDoS attack. This will help us validate our auto-scaling configuration and identify potential bottlenecks under load. We've deployed chaos-mesh-worker with the --duration 60s --latency 50ms flags."This question tests understanding of practical application. While deploying
chaos-mesh-worker with flags is a common starting point, the core purpose isn't just increasing latency. The correct answer highlights the intended use: validating auto-scaling and identifying bottlenecks under simulated load. Option A misinterprets latency injection as a simple fix; option C suggests an incorrect method for achieving this goal.15 / 26
Reviewer: 'I noticed you're using Chaos Mesh to introduce intermittent failures. While the intention is good – testing resilience – are you documenting the specific failure modes you're targeting? Specifically, what *types* of chaos experiments are you running and why? This will help us understand the scope of the test and ensure it aligns with our overall risk tolerance.
Slack Message from a team member: 'Yeah, we're using Chaos Mesh to simulate network partitions. The goal is to see how quickly the services recover.'The question focuses on the crucial aspect of *intent* within chaos engineering. Simply introducing failures (option A) isn't sufficient; it needs to be a targeted experiment. The correct answer highlights that simulating network partitions with Chaos Mesh is valid, but importantly, documenting *what types* of failures are being tested and why (e.g., testing circuit breaker behavior or data consistency) is essential for effective risk management and demonstrating the value of the chaos engineering effort. Options B and C miss this critical element of strategic experimentation, while option D misinterprets the purpose of Slack communication.
16 / 26
Reviewer: 'I'm seeing you've deployed Kitchen Betty to trigger cascading failures in our backend services. While the aim is to test our recovery strategies, it seems like we haven't defined a clear *scope* for these tests. Specifically, are we focusing on simulating specific failure patterns – like database outages or message queue congestion – and what metrics are we using to measure success? Without this context, it's difficult to assess the effectiveness of the experiment.'
Which of the following best describes the reviewer's concern regarding Kitchen Betty deployment?The reviewer isn't just questioning the use of Kitchen Betty; they're critically examining *how* it's being used. The core concern is the lack of defined scope – specifically, what types of failures are being simulated and how success is measured. This highlights a crucial aspect of chaos engineering: not just injecting chaos, but understanding *what* chaos you're introducing and *why*, tying it back to measurable outcomes like recovery time or service availability.
17 / 26
During a code review of a pull request introducing Chaos Mesh to simulate service degradation, the reviewer asks: 'Are you documenting the specific failure modes you're targeting with this experiment? What types of chaos are you running and why?' The reviewer's primary concern is about context. Which option best reflects that concern?
The reviewer isn't primarily focused on whether the code *works* after injecting chaos (option A). Instead, they're demanding context around *why* that chaos is being injected. The specific configuration details (latency) are secondary to understanding the overall strategy and its justification (option B). The core issue is a lack of defined scope and objectives—what types of failures are intentionally simulated and what constitutes success—which directly relates to risk tolerance and alignment with broader resilience goals (option C). Option D misinterprets the review's focus, suggesting performance metrics should outweigh strategic considerations.
18 / 26
PR Description:
"We're injecting latency into the API gateway using Chaos Mesh to simulate a DDoS attack. This will help us validate our auto-scaling configuration and identify potential bottlenecks under load. We've deployed chaos-mesh-worker with the --duration 60s --latency 50ms flags."This question tests understanding of practical application. While deploying
chaos-mesh-worker with flags is a common starting point, the core purpose isn't just increasing latency. The correct answer highlights the intended use: validating auto-scaling and identifying bottlenecks under simulated load. Option A misinterprets latency injection as a simple fix; option C suggests an incorrect method for achieving this goal.19 / 26
Reviewer: 'I noticed you're using Chaos Mesh to introduce intermittent failures. While the intention is good – testing resilience – are you documenting the specific failure modes you're targeting? Specifically, what *types* of chaos experiments are you running and why? This will help us understand the scope of the test and ensure it aligns with our overall risk tolerance.
Slack Message from a team member: 'Yeah, we're using Chaos Mesh to simulate network partitions. The goal is to see how quickly the services recover.'The question focuses on the crucial aspect of *intent* within chaos engineering. Simply introducing failures (option A) isn't sufficient; it needs to be a targeted experiment. The correct answer highlights that simulating network partitions with Chaos Mesh is valid, but importantly, documenting *what types* of failures are being tested and why (e.g., testing circuit breaker behavior or data consistency) is essential for effective risk management and demonstrating the value of the chaos engineering effort. Options B and C miss this critical element of strategic experimentation, while option D misinterprets the purpose of Slack communication.
20 / 26
Reviewer: 'I'm seeing you've deployed Kitchen Betty to trigger cascading failures in our backend services. While the aim is to test our recovery strategies, it seems like we haven't defined a clear *scope* for these tests. Specifically, are we focusing on simulating specific failure patterns – like database outages or message queue congestion – and what metrics are we using to measure success? Without this context, it's difficult to assess the effectiveness of the experiment.'
Which of the following best describes the reviewer's concern regarding Kitchen Betty deployment?The reviewer isn't just questioning the use of Kitchen Betty; they're critically examining *how* it's being used. The core concern is the lack of defined scope – specifically, what types of failures are being simulated and how success is measured. This highlights a crucial aspect of chaos engineering: not just injecting chaos, but understanding *what* chaos you're introducing and *why*, tying it back to measurable outcomes like recovery time or service availability.
21 / 26
During a code review of a pull request introducing Chaos Mesh to simulate service degradation, the reviewer asks: 'Are you documenting the specific failure modes you're targeting with this experiment? What types of chaos are you running and why?' The reviewer's primary concern is about context. Which option best reflects that concern?
The reviewer isn't primarily focused on whether the code *works* after injecting chaos (option A). Instead, they're demanding context around *why* that chaos is being injected. The specific configuration details (latency) are secondary to understanding the overall strategy and its justification (option B). The core issue is a lack of defined scope and objectives—what types of failures are intentionally simulated and what constitutes success—which directly relates to risk tolerance and alignment with broader resilience goals (option C). Option D misinterprets the review's focus, suggesting performance metrics should outweigh strategic considerations.
22 / 26
Reviewer Sarah comments: 'I'm seeing you've configured Chaos Mesh to randomly drop connections. To ensure we can accurately assess the impact of this, could you please elaborate on the specific metrics you're monitoring during these experiments – particularly around latency and error rates?
chaos mesh --drop-connections --duration 60s', what does 'duration' refer to here?This question tests understanding of Chaos Mesh's configuration parameters. The 'duration' parameter controls the length of time the experiment runs – it does *not* define the interval between dropped connections. Sarah is requesting information about metrics to assess the impact of these failures.
23 / 26
Alex sends a Slack message: 'Hey team, just deployed Kitchen Betty to trigger a cascading failure in our order processing service. We're aiming to test our failover mechanisms but I haven't defined any specific *boundaries* for this test. What does 'boundaries' mean in the context of a Kitchen Betty experiment?'
Kitchen Betty is designed for controlled chaos. The 'boundaries' parameter is *crucial* – it limits the scope of the experiment by defining which services are affected and preventing unintended consequences in production. This question tests understanding of controlling the impact of a Kitchen Betty deployment.
24 / 26
The API returns the following response after injecting latency into an application using Chaos Mesh: `{"status": "error", "message": "Service unavailable - Latency exceeded threshold.", "latency": "250ms"}`. What does the 'latency' value in this response indicate?
This response is generated by Chaos Mesh when latency injection exceeds the defined threshold. The 'latency' value represents *the actual delay* introduced by the experiment – demonstrating the impact of the simulated failure on service performance and confirming that the configured threshold was breached.
25 / 26
Here's a PR description: 'We're introducing intermittent network packet loss using Chaos Mesh to simulate a degraded WAN connection. This will allow us to test our application's resilience and identify potential bottlenecks under stressed conditions. We've configured
chaos mesh --packet-loss 10 to achieve this.' What is the purpose of the `--packet-loss` argument?The `--packet-loss` argument in Chaos Mesh is specifically used to simulate degraded WAN connectivity by intentionally dropping network packets. This mimics real-world scenarios where packet loss can occur, allowing you to test your application's resilience under these conditions.
26 / 26
During the daily standup, Ben says: 'I deployed Chaos Mesh to simulate a service outage. We're monitoring error rates and latency metrics. The goal is to verify our auto-scaling capabilities.' What key consideration should be added to this statement regarding Chaos Engineering practices?
While monitoring technical metrics is important, a robust Chaos Engineering approach requires documenting the *failure modes* being tested – this includes understanding the expected impact on user experience. This ensures that the experiment's objectives are clearly defined and its success can be properly evaluated beyond just raw numbers.
Frequently Asked Questions
What will I practice in "Chaos Engineering Tools — Vocabulary"?
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.