Learn vocabulary for chaos engineering culture: chaos maturity model, GameDay practice, blameless culture, and psychological safety.
0 / 14 completed
1 / 14
What is the 'chaos maturity model'?
The chaos maturity model (popularised by Gremlin and others) describes progression through levels: ad-hoc/manual experiments → repeatable experiments → automated chaos in staging → continuous chaos in production with full automation and observability.
2 / 14
A team lead says 'GameDay is a practice drill, not a production incident'. What is a GameDay?
GameDay is a deliberate, pre-planned exercise (borrowed from sports/military practice) where teams simulate failure scenarios to test their response capabilities, validate runbooks, and find resilience gaps — in a controlled, low-stakes environment.
3 / 14
What does 'blameless chaos culture' mean?
Blameless chaos culture means that when a chaos experiment reveals a weakness, the focus is on improving the system — not blaming the engineer who built it. This encourages honest reporting and willingness to experiment.
4 / 14
Why is 'psychological safety' important in chaos engineering practice?
Without psychological safety, teams hide weaknesses, avoid running experiments that might reveal problems, and cover up results. Psychological safety is a prerequisite for an honest, effective chaos practice.
5 / 14
When someone says 'we ran a chaos experiment on the payment service', what professional context does this imply?
'Running a chaos experiment on a service' means deliberately injecting controlled failures (latency, errors, resource exhaustion) in a planned, observable way — it's a proactive reliability practice, not an accident.
6 / 14
PR Description
During a code review, John submitted a pull request to update the user authentication service. The description reads: 'Ran a small chaos experiment – injected a 50ms delay into the token validation endpoint. Observed no impact on key metrics during the test.' Sarah, the senior engineer, comments: 'That's… ambitious. How did you ensure this didn't break anything?'
Which of the following best describes John's approach and the implication of his comment?
The correct answer highlights John's approach as a formal chaos experiment. The key here is the phrase 'observed no impact on key metrics.' This indicates he followed best practices by defining clear objectives, executing the experiment under controlled conditions, and then rigorously verifying that there were no unintended consequences. Options A and B are incorrect because they represent overly optimistic or simplistic interpretations of 'chaos experiments' – a true experiment requires careful monitoring and validation. Option D is also incorrect as it describes reactive alerting rather than proactive chaos engineering.
7 / 14
PR Description
During a code review, John submitted a pull request to update the user authentication service. The description reads: 'Ran a small chaos experiment – injected a 50ms delay into the token validation endpoint. Observed no impact on key metrics during the test.' Sarah, the senior engineer, comments: 'That's… ambitious. How did you ensure this didn't break anything?'
Which of the following best describes John's approach and the implication of his comment?
The correct answer highlights John's approach as a formal chaos experiment. The key here is the phrase 'observed no impact on key metrics.' This indicates he followed best practices by defining clear objectives, executing the experiment under controlled conditions, and then rigorously verifying that there were no unintended consequences. Options A and B are incorrect because they represent overly optimistic or simplistic interpretations of 'chaos experiments' – a true experiment requires careful monitoring and validation. Option D is also incorrect as it describes reactive alerting rather than proactive chaos engineering.
8 / 14
PR Description
During a code review, John submitted a pull request to update the user authentication service. The description reads: 'Ran a small chaos experiment – injected a 50ms delay into the token validation endpoint. Observed no impact on key metrics during the test.' Sarah, the senior engineer, comments: 'That's… ambitious. How did you ensure this didn't break anything?'
Which of the following best describes John's approach and the implication of his comment?
The correct answer highlights John's approach as a formal chaos experiment. The key here is the phrase 'observed no impact on key metrics.' This indicates he followed best practices by defining clear objectives, executing the experiment under controlled conditions, and then rigorously verifying that there were no unintended consequences. Options A and B are incorrect because they represent overly optimistic or simplistic interpretations of 'chaos experiments' – a true experiment requires careful monitoring and validation. Option D is also incorrect as it describes reactive alerting rather than proactive chaos engineering.
9 / 14
PR Description
During a code review, John submitted a pull request to update the user authentication service. The description reads: 'Ran a small chaos experiment – injected a 50ms delay into the token validation endpoint. Observed no impact on key metrics during the test.' Sarah, the senior engineer, comments: 'That's… ambitious. How did you ensure this didn't break anything?'
Which of the following best describes John's approach and the implication of his comment?
The correct answer highlights John's approach as a formal chaos experiment. The key here is the phrase 'observed no impact on key metrics.' This indicates he followed best practices by defining clear objectives, executing the experiment under controlled conditions, and then rigorously verifying that there were no unintended consequences. Options A and B are incorrect because they represent overly optimistic or simplistic interpretations of 'chaos experiments' – a true experiment requires careful monitoring and validation. Option D is also incorrect as it describes reactive alerting rather than proactive chaos engineering.
10 / 14
Sarah (DevOps Engineer) posted in the team Slack channel: 'Just ran a little chaos experiment on the API gateway – introduced a random 10% failure rate. Monitoring looks good so far!'. Which of the following best describes Sarah's approach to this activity?
The key here is 'chaos experiment'. This phrase signifies a deliberate effort to expose system weaknesses through controlled failures. Option A misinterprets this as frivolous behavior; option C and D highlight the importance of user impact which isn't the primary goal of chaos engineering. The correct answer accurately reflects the core principle: testing resilience by simulating real-world failure scenarios.
11 / 14
During a standup meeting, David says, 'Yesterday, we ran a chaos experiment on the order processing service. We introduced intermittent network latency to simulate peak load conditions. The results showed that our queuing system handled the increased traffic without significant degradation.' What does David's statement primarily demonstrate?
David's statement highlights a crucial aspect of chaos engineering: actively probing systems under stress. Introducing latency mimics a high-load scenario, revealing how well the system responds and recovers – demonstrating proactive resilience testing. The other options misinterpret David's actions; he isn't breaking the service but observing its behavior.
12 / 14
You are reviewing a pull request from Maria where she describes a chaos experiment. The PR description reads: 'Simulated a DDoS attack on the web server – flooded it with synthetic requests to test mitigation strategies'. What is Maria's primary intention in this action?
DDoS (Distributed Denial of Service) simulations are a core component of chaos engineering. By intentionally flooding the system with traffic mimicking an attack, Maria is validating the effectiveness of security measures and identifying vulnerabilities – specifically testing resilience against malicious inputs. The other options represent misinterpretations of the experiment's purpose.
13 / 14
A senior engineer, Alex, observes a team member, Ben, running a chaos experiment. He asks, 'What's the point of deliberately causing problems?' Ben replies, 'It's about learning what breaks and how to fix it faster.' What fundamental principle is Ben articulating related to chaos engineering?
Ben's response encapsulates the core philosophy of chaos engineering: using controlled failures to gain insights into system behavior. 'Learning from failure' – specifically in a managed and safe context – allows teams to identify weaknesses, improve recovery strategies, and ultimately build more resilient systems. This contrasts with simply causing problems without a defined purpose.
14 / 14
You receive an API response from the monitoring system after a chaos experiment: `[ { "metric": "latency", "value": "250ms", "timestamp": "2024-10-27T10:00:00Z" }, { "metric": "error_rate", "value": "0.1%", "timestamp": "2024-10-27T10:00:00Z" } ]`. Considering the context of a chaos experiment, what does this API response primarily indicate?
The API response reveals key metrics – latency and error rate – measured *during* the chaos experiment. These numbers demonstrate how the system behaved under simulated stress. A non-zero latency or error rate isn't necessarily negative; it provides data to assess the resilience of the system during the experiment, allowing for informed decision-making about improvements.
What will I practice in "Chaos Engineering Culture Vocabulary Quiz"?
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.