Practice vocabulary for learning from chaos experiments: unknown dependencies, unexpected behavior, discovering gaps, and actionable insights.
0 / 14 completed
1 / 14
A post-experiment summary says 'The experiment revealed an unknown dependency.' What is an unknown dependency in this context?
Unknown dependencies are often the most valuable discoveries from chaos experiments — services, databases, or external calls that the system silently depends on, but that no team member was aware of. Discovering them before an outage is the point.
2 / 14
Your experiment report says 'The system behaved unexpectedly when the cache was injected with latency.' What should the team do with this finding?
Unexpected behavior revealed by chaos experiments is a finding — it means the system has a gap in its resilience assumptions. The team should document it, understand the root cause, and address it (e.g., add timeouts, fallbacks, or circuit breakers).
3 / 14
Your team says 'We discovered the backup wasn't working until the chaos test.' What type of gap did the chaos experiment surface?
This is a critical class of chaos finding: an assumed recovery mechanism that was never actually tested. Chaos engineering frequently reveals that backups, failover procedures, or circuit breakers exist in theory but don't work in practice.
4 / 14
The experiment learning statement reads: 'We need circuit breakers on this call.' What prompted this conclusion?
Circuit breakers are a resilience pattern that stops requests to a failing service after a threshold, preventing cascade failures. Chaos experiments that induce downstream failures reveal exactly where circuit breakers are missing or not configured correctly.
5 / 14
A chaos retrospective uses the phrase 'the learning was: the system degrades silently without alerting anyone.' What action should this trigger?
Silent degradation is a dangerous failure mode — the system is failing but no one knows. The chaos finding should directly drive adding observability (metrics, alerts, dashboards) so the failure mode is immediately visible if it occurs in production.
6 / 14
PR Title: Fix intermittent API timeout
During code review, Alice comments: 'This PR doesn't explain why the API call sometimes fails. The logging is minimal and doesn't provide any context for diagnosing the issue.' What does Alice mean by 'doesn't provide any context'? Consider the potential impact on a developer debugging this problem.
Alice is highlighting a critical gap in the debugging process – insufficient context within the logs. A 'lack of context' means the logs aren't providing enough information to *understand* the cause of the timeout. This could include missing request parameters, server-side errors not captured in the logs, or network issues not reflected in the response time. The goal isn't simply that the code is poorly written, but rather that the diagnostic data is lacking.
7 / 14
PR Title: Fix intermittent API timeout
During code review, Alice comments: 'This PR doesn't explain why the API call sometimes fails. The logging is minimal and doesn't provide any context for diagnosing the issue.' What does Alice mean by 'doesn't provide any context'? Consider the potential impact on a developer debugging this problem.
Alice is highlighting a critical gap in the debugging process – insufficient context within the logs. A 'lack of context' means the logs aren't providing enough information to *understand* the cause of the timeout. This could include missing request parameters, server-side errors not captured in the logs, or network issues not reflected in the response time. The goal isn't simply that the code is poorly written, but rather that the diagnostic data is lacking.
8 / 14
PR Title: Fix intermittent API timeout
During code review, Alice comments: 'This PR doesn't explain why the API call sometimes fails. The logging is minimal and doesn't provide any context for diagnosing the issue.' What does Alice mean by 'doesn't provide any context'? Consider the potential impact on a developer debugging this problem.
Alice is highlighting a critical gap in the debugging process – insufficient context within the logs. A 'lack of context' means the logs aren't providing enough information to *understand* the cause of the timeout. This could include missing request parameters, server-side errors not captured in the logs, or network issues not reflected in the response time. The goal isn't simply that the code is poorly written, but rather that the diagnostic data is lacking.
9 / 14
PR Title: Fix intermittent API timeout
During code review, Alice comments: 'This PR doesn't explain why the API call sometimes fails. The logging is minimal and doesn't provide any context for diagnosing the issue.' What does Alice mean by 'doesn't provide any context'? Consider the potential impact on a developer debugging this problem.
Alice is highlighting a critical gap in the debugging process – insufficient context within the logs. A 'lack of context' means the logs aren't providing enough information to *understand* the cause of the timeout. This could include missing request parameters, server-side errors not captured in the logs, or network issues not reflected in the response time. The goal isn't simply that the code is poorly written, but rather that the diagnostic data is lacking.
10 / 14
Ben from Sentry reports: 'We're seeing a spike in errors after the chaos test. The metrics show increased latency across multiple services, but the error rate itself is relatively stable.' What does 'stable error rate' suggest about the nature of the problem? Hint: Consider what might be *masked* by a stable error count
'Stable error rate' means that *despite* the increased latency and other metrics, the number of errors reported by monitoring systems hasn't dramatically changed. This often indicates that the chaos test was introducing intermittent failures – problems that don't consistently trigger error reports but cause disruptions nonetheless. The key is to recognize this as a potential mask for deeper issues.
11 / 14
During a Slack discussion about the results of a recent chaos experiment on the payment service, David says: 'The system became unresponsive during the test and didn't recover automatically. We need to investigate if there are any existing circuit breakers that could have prevented this.' What is David referring to when he mentions 'circuit breakers'? Hint: Think about how systems protect themselves from cascading failures
Circuit breakers are a critical resilience pattern. They're designed to *automatically* detect unhealthy conditions (like increased latency or errors) in a dependent service and temporarily halt traffic to it – preventing the problem from cascading and taking down other parts of the system. David is asking if existing circuit breaker configurations were in place to handle this situation.
12 / 14
Maria writes a PR description: 'This change implements chaos engineering by deliberately introducing network latency into the database service. The goal is to test our ability to handle degraded performance.' What's the *primary* purpose of this deliberate introduction of latency? Hint: Consider what you're trying to learn about your system's resilience
The core purpose of introducing chaos – specifically latency in this case – is to *test* the system's resilience. By simulating a degraded condition, you can observe how the database service and its dependent components behave under stress, revealing weaknesses or bottlenecks that might not be apparent during normal operation. It's about learning what happens when things go wrong.
13 / 14
During a standup update, you say: 'We ran a chaos experiment where we randomly killed some worker processes. The system continued to operate, but we saw increased queue lengths.' What does this observation suggest about the system's design? Hint: Think about how systems handle unexpected resource scarcity
Seeing increased queue lengths after killing worker processes indicates the system *does* have a queuing mechanism. This means it's designed to buffer incoming requests when resources are temporarily unavailable. A robust queuing system is a key component of resilient systems, allowing them to continue operating despite intermittent disruptions – it's not necessarily failing.
14 / 14
Carlos writes in a code review comment: 'I'm concerned about the lack of observability here. The service is experiencing intermittent timeouts, but there are no metrics or logs to help us understand *why* they're happening.' What does Carlos mean by 'lack of observability'? Hint: Consider what data you need to diagnose problems
'Observability' refers to the ability to understand the internal state of a system based on its external outputs (logs, metrics, traces). Carlos is highlighting that there's no mechanism for capturing this information – no logging, monitoring, or tracing – which makes it extremely difficult to diagnose intermittent issues like these API timeouts. The absence of data hinders effective troubleshooting.
What will I practice in "Learning from Chaos Vocabulary"?
This is a Chaos Engineering exercise set. It walks through 14 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 14 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.