Practice observability vocabulary used during chaos experiments: experiment dashboards, blast radius metrics, safety thresholds, and chaos scoring.
0 / 26 completed
1 / 26
An SRE says 'the experiment dashboard shows the steady state is holding'. What does this mean?
The experiment dashboard tracks the defined steady-state metrics in real time. 'Steady state is holding' means injected failures are not causing observable degradation beyond the defined thresholds — the system is resilient.
2 / 26
What is a 'blast radius metric' in a chaos experiment?
Blast radius metrics quantify the scope of impact: percentage of affected requests, number of impacted users, or downstream services affected. Monitoring blast radius helps ensure the experiment stays within safe bounds.
3 / 26
What happens when a message says 'experiment paused due to safety threshold'?
Safety thresholds are pre-defined abort conditions. If a metric like error rate or latency exceeds the threshold, the chaos orchestrator automatically halts the experiment to protect users — a critical safety mechanism.
4 / 26
What is a 'chaos experiment trace' in the context of distributed tracing?
Chaos experiment traces are distributed traces collected while failures are injected. They reveal which services degrade under failure, helping teams understand the failure propagation path and validate that circuit breakers and fallbacks work correctly.
5 / 26
What is 'chaos scoring' used for?
Chaos scoring provides a resilience metric over time. Systems score higher as they pass more experiments without exceeding safety thresholds, providing a trend metric for improving system reliability.
6 / 26
PR Description
"Running chaos experiment `impact-db-read` on production. Initial observations show intermittent 500 errors impacting read latency for the `/users` endpoint. We're monitoring CPU utilization and network I/O – currently within acceptable ranges. Expecting some disruption, but aiming to keep it short."
This scenario highlights a key aspect of chaos experiments: proactively identifying and addressing potential negative impacts. The description correctly identifies that the experiment is about mitigating performance degradation, which aligns with the core purpose of chaos engineering – surfacing vulnerabilities through controlled disruption. Option A is incorrect as it describes a reduction in latency, while option C misinterprets the description's intent.
7 / 26
Sarah: "Hey team, I've deployed the `chaos-injector` to simulate a network partition. The dashboard is reporting high latency spikes across multiple services – particularly around the payment gateway. It's fluctuating wildly, but seems consistent."
This question tests understanding of how to interpret fluctuating metrics during a chaos experiment. The key here is 'acceptable' – while fluctuations are common, *consistent* spikes indicate a problem with the injector's configuration or the way it's simulating the fault. Options A and B misinterpret normal load versus the purpose of the experiment; option C correctly identifies acceptable variance while highlighting the need for continued monitoring, and option D suggests a critical issue requiring immediate attention.
8 / 26
John: "I'm seeing a lot of 'timeouts' in the API response logs during the chaos experiment. The service is returning HTTP 504 errors intermittently."
Maria: "We've configured the injector to randomly introduce network latency, simulating a degraded connection. The goal is to observe how resilient our system is to these conditions."
Which of the following best describes Maria's intention regarding the observed 504 errors?
Maria is intentionally inducing failure (network latency) to *test* the system's resilience. The 504 errors are an expected outcome of this stress test – they demonstrate how the service handles transient failures. Option A is incorrect because it suggests a fundamental design flaw which wouldn't be revealed by controlled chaos; options C and D are inappropriate responses given the experiment's purpose.
9 / 26
Maria is intentionally introducing network latency to simulate a degraded connection. The observed 504 errors in the payment gateway's API response logs are being used to assess its resilience. Which of the following best describes Maria's intention regarding these errors?
Maria is conducting a chaos experiment designed to evaluate resilience. The 504 errors are not necessarily indicative of a root cause (option A); instead, they're data points being collected to understand how the system *behaves* under stress. Proactive code optimization (option B) isn't the goal here; the focus is on observing behavior, and immediately resolving the error wouldn't allow for meaningful analysis – this experiment's purpose is to deliberately introduce problems to see how well the system handles them (option D).
10 / 26
PR Description
"Running chaos experiment `impact-db-read` on production. Initial observations show intermittent 500 errors impacting read latency for the `/users` endpoint. We're monitoring CPU utilization and network I/O – currently within acceptable ranges. Expecting some disruption, but aiming to keep it short."
This scenario highlights a key aspect of chaos experiments: proactively identifying and addressing potential negative impacts. The description correctly identifies that the experiment is about mitigating performance degradation, which aligns with the core purpose of chaos engineering – surfacing vulnerabilities through controlled disruption. Option A is incorrect as it describes a reduction in latency, while option C misinterprets the description's intent.
11 / 26
Sarah: "Hey team, I've deployed the `chaos-injector` to simulate a network partition. The dashboard is reporting high latency spikes across multiple services – particularly around the payment gateway. It's fluctuating wildly, but seems consistent."
This question tests understanding of how to interpret fluctuating metrics during a chaos experiment. The key here is 'acceptable' – while fluctuations are common, *consistent* spikes indicate a problem with the injector's configuration or the way it's simulating the fault. Options A and B misinterpret normal load versus the purpose of the experiment; option C correctly identifies acceptable variance while highlighting the need for continued monitoring, and option D suggests a critical issue requiring immediate attention.
12 / 26
John: "I'm seeing a lot of 'timeouts' in the API response logs during the chaos experiment. The service is returning HTTP 504 errors intermittently."
Maria: "We've configured the injector to randomly introduce network latency, simulating a degraded connection. The goal is to observe how resilient our system is to these conditions."
Which of the following best describes Maria's intention regarding the observed 504 errors?
Maria is intentionally inducing failure (network latency) to *test* the system's resilience. The 504 errors are an expected outcome of this stress test – they demonstrate how the service handles transient failures. Option A is incorrect because it suggests a fundamental design flaw which wouldn't be revealed by controlled chaos; options C and D are inappropriate responses given the experiment's purpose.
13 / 26
Maria is intentionally introducing network latency to simulate a degraded connection. The observed 504 errors in the payment gateway's API response logs are being used to assess its resilience. Which of the following best describes Maria's intention regarding these errors?
Maria is conducting a chaos experiment designed to evaluate resilience. The 504 errors are not necessarily indicative of a root cause (option A); instead, they're data points being collected to understand how the system *behaves* under stress. Proactive code optimization (option B) isn't the goal here; the focus is on observing behavior, and immediately resolving the error wouldn't allow for meaningful analysis – this experiment's purpose is to deliberately introduce problems to see how well the system handles them (option D).
14 / 26
PR Description
"Running chaos experiment `impact-db-read` on production. Initial observations show intermittent 500 errors impacting read latency for the `/users` endpoint. We're monitoring CPU utilization and network I/O – currently within acceptable ranges. Expecting some disruption, but aiming to keep it short."
This scenario highlights a key aspect of chaos experiments: proactively identifying and addressing potential negative impacts. The description correctly identifies that the experiment is about mitigating performance degradation, which aligns with the core purpose of chaos engineering – surfacing vulnerabilities through controlled disruption. Option A is incorrect as it describes a reduction in latency, while option C misinterprets the description's intent.
15 / 26
Sarah: "Hey team, I've deployed the `chaos-injector` to simulate a network partition. The dashboard is reporting high latency spikes across multiple services – particularly around the payment gateway. It's fluctuating wildly, but seems consistent."
This question tests understanding of how to interpret fluctuating metrics during a chaos experiment. The key here is 'acceptable' – while fluctuations are common, *consistent* spikes indicate a problem with the injector's configuration or the way it's simulating the fault. Options A and B misinterpret normal load versus the purpose of the experiment; option C correctly identifies acceptable variance while highlighting the need for continued monitoring, and option D suggests a critical issue requiring immediate attention.
16 / 26
John: "I'm seeing a lot of 'timeouts' in the API response logs during the chaos experiment. The service is returning HTTP 504 errors intermittently."
Maria: "We've configured the injector to randomly introduce network latency, simulating a degraded connection. The goal is to observe how resilient our system is to these conditions."
Which of the following best describes Maria's intention regarding the observed 504 errors?
Maria is intentionally inducing failure (network latency) to *test* the system's resilience. The 504 errors are an expected outcome of this stress test – they demonstrate how the service handles transient failures. Option A is incorrect because it suggests a fundamental design flaw which wouldn't be revealed by controlled chaos; options C and D are inappropriate responses given the experiment's purpose.
17 / 26
Maria is intentionally introducing network latency to simulate a degraded connection. The observed 504 errors in the payment gateway's API response logs are being used to assess its resilience. Which of the following best describes Maria's intention regarding these errors?
Maria is conducting a chaos experiment designed to evaluate resilience. The 504 errors are not necessarily indicative of a root cause (option A); instead, they're data points being collected to understand how the system *behaves* under stress. Proactive code optimization (option B) isn't the goal here; the focus is on observing behavior, and immediately resolving the error wouldn't allow for meaningful analysis – this experiment's purpose is to deliberately introduce problems to see how well the system handles them (option D).
18 / 26
PR Description
"Running chaos experiment `impact-db-read` on production. Initial observations show intermittent 500 errors impacting read latency for the `/users` endpoint. We're monitoring CPU utilization and network I/O – currently within acceptable ranges. Expecting some disruption, but aiming to keep it short."
This scenario highlights a key aspect of chaos experiments: proactively identifying and addressing potential negative impacts. The description correctly identifies that the experiment is about mitigating performance degradation, which aligns with the core purpose of chaos engineering – surfacing vulnerabilities through controlled disruption. Option A is incorrect as it describes a reduction in latency, while option C misinterprets the description's intent.
19 / 26
Sarah: "Hey team, I've deployed the `chaos-injector` to simulate a network partition. The dashboard is reporting high latency spikes across multiple services – particularly around the payment gateway. It's fluctuating wildly, but seems consistent."
This question tests understanding of how to interpret fluctuating metrics during a chaos experiment. The key here is 'acceptable' – while fluctuations are common, *consistent* spikes indicate a problem with the injector's configuration or the way it's simulating the fault. Options A and B misinterpret normal load versus the purpose of the experiment; option C correctly identifies acceptable variance while highlighting the need for continued monitoring, and option D suggests a critical issue requiring immediate attention.
20 / 26
John: "I'm seeing a lot of 'timeouts' in the API response logs during the chaos experiment. The service is returning HTTP 504 errors intermittently."
Maria: "We've configured the injector to randomly introduce network latency, simulating a degraded connection. The goal is to observe how resilient our system is to these conditions."
Which of the following best describes Maria's intention regarding the observed 504 errors?
Maria is intentionally inducing failure (network latency) to *test* the system's resilience. The 504 errors are an expected outcome of this stress test – they demonstrate how the service handles transient failures. Option A is incorrect because it suggests a fundamental design flaw which wouldn't be revealed by controlled chaos; options C and D are inappropriate responses given the experiment's purpose.
21 / 26
Maria is intentionally introducing network latency to simulate a degraded connection. The observed 504 errors in the payment gateway's API response logs are being used to assess its resilience. Which of the following best describes Maria's intention regarding these errors?
Maria is conducting a chaos experiment designed to evaluate resilience. The 504 errors are not necessarily indicative of a root cause (option A); instead, they're data points being collected to understand how the system *behaves* under stress. Proactive code optimization (option B) isn't the goal here; the focus is on observing behavior, and immediately resolving the error wouldn't allow for meaningful analysis – this experiment's purpose is to deliberately introduce problems to see how well the system handles them (option D).
22 / 26
During a chaos experiment simulating a database outage, David writes in the team Slack channel: "The service is returning a 502 Bad Gateway error with increasing frequency. I'm seeing elevated latency metrics on the frontend.". Which of the following best describes the primary issue being reported?
Option A: The application code itself has a bug causing the errors. Option B: The service is experiencing transient network connectivity problems, leading to failed requests. Option C: The database server is overloaded and unable to handle the increased load. Option D: The frontend servers are malfunctioning, generating false 502 errors.
This scenario focuses on transient issues. A 502 Bad Gateway often indicates a problem with communication between services – in this case, likely due to network instability or temporary service unavailability. Option C is incorrect because it suggests a sustained database overload, which wouldn't typically manifest as intermittent gateway errors.
23 / 26
You are reviewing a PR description for a chaos experiment targeting the order processing service. The description reads: 'Running chaos experiment `order-queue-block` on staging. Initial observations show intermittent HTTP 503 Service Unavailable errors across multiple queues. We're monitoring queue depth and message processing times.' What does the term 'intermittent' most likely imply in this context?
Option A: The errors are consistently reproducible under identical conditions. Option B: The errors occur sporadically, with periods of normal operation in between. Option C: The experiment is configured incorrectly, causing the service to fail repeatedly. Option D: The service is experiencing a permanent outage, requiring immediate attention.
'Intermittent' describes an event that doesn't happen predictably. It suggests that the errors are transient and not indicative of a fundamental problem with the order processing service. Option C is incorrect as it implies a persistent configuration error; option D incorrectly assumes a permanent outage based on the observed symptoms.
24 / 26
During a chaos run simulating a degraded network connection to your API gateway, you receive the following response from the monitoring dashboard: 'Latency spikes detected in requests to the `/products` endpoint. Average latency increased from 5ms to 150ms over the last five minutes.' What is the *primary* concern highlighted by this message?
Option A: The API gateway's hardware is failing. Option B: The service implementing the `/products` endpoint is experiencing performance issues. Option C: There's a problem with network connectivity impacting the speed of requests reaching the API gateway. Option D: The monitoring system itself has an error, reporting false latency data.
The message directly states 'latency spikes' and identifies the `/products` endpoint. This points to the service handling that endpoint as the source of the increased latency. While network issues *could* be a contributing factor, the dashboard's focus on the endpoint suggests it is the root cause.
25 / 26
Maria, a chaos engineering specialist, is documenting her experiment. She writes: 'I'm intentionally introducing network latency to simulate a degraded connection between the web servers and the database. The observed 504 errors in the payment gateway's API response logs are being used to assess its resilience.' What is Maria primarily attempting to achieve with this experiment?
Option A: Identify vulnerabilities in the database schema. Option B: Simulate a real-world failure scenario to test the system's ability to cope. Option C: Optimize the performance of the payment gateway's API calls. Option D: Monitor CPU usage on the web servers for unusual spikes.
Maria is deliberately introducing an adverse condition (network latency) to *test* the system's resilience. This aligns with the core principle of chaos engineering – exposing systems to failure to understand their behavior and identify weaknesses. The goal isn't optimization or vulnerability scanning but rather stress testing.
26 / 26
You are investigating a production incident where users report slow response times when accessing a key feature. The chaos engineering team has deployed a tool that randomly introduces delays in the network path between the user's browser and your application servers. Analyzing the server logs, you find numerous 'connection refused' errors originating from the application servers. Which of the following actions would be MOST appropriate as the *next* step?
Option A: Immediately roll back the chaos experiment to restore normal service. Option B: Increase the resources (CPU and memory) allocated to the application servers. Option C: Investigate the network path between the user's browser and the application servers for potential bottlenecks or misconfigurations. Option D: Escalate the incident to a higher-level support team without further investigation.
The logs indicate that the application servers are unable to establish connections. This strongly suggests a resource constraint (likely network bandwidth) is causing the connection failures. Rolling back the experiment might temporarily alleviate symptoms but doesn't address the root cause. Increasing resources would be a reactive measure if the bottleneck isn't related to resource exhaustion.
What will I practice in "Chaos Observability Vocabulary Quiz"?
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.