Practice resilience engineering vocabulary: resilience vs. robustness, graceful degradation, and the difference from reliability engineering.
0 / 18 completed
1 / 18
A site reliability engineer says 'Resilience is the ability to adapt and recover.' How does this differ from reliability?
Reliability engineering focuses on preventing failures from occurring (reducing failure rate). Resilience engineering accepts that failures will happen and focuses on the system's ability to absorb disruption, adapt, and recover — minimizing impact duration and severity.
2 / 18
A design review says 'The system degrades gracefully.' What does graceful degradation mean?
Graceful degradation means the system is designed so that partial failures lead to reduced functionality rather than total failure. For example, if the recommendation engine fails, the site still loads without recommendations rather than returning a 500 error.
3 / 18
Your architecture document says 'Resilience vs. robustness: we prioritize resilience.' What is the key distinction?
Robustness is the ability to withstand stress without changing (strong but brittle). Resilience is the ability to adapt to stress and recover (flexible and adaptive). Resilient systems may temporarily degrade but recover; robust systems try not to degrade but can fail catastrophically when pushed past their limits.
4 / 18
A conference talk says 'Reliability engineering focuses on preventing failure; resilience engineering prepares for it.' Which phrase best captures resilience engineering's core focus?
The core insight of resilience engineering is that in complex systems, failure is inevitable. Rather than only trying to prevent failure, resilience engineering designs explicit recovery paths, fallbacks, and adaptive responses into the system from the start.
5 / 18
A resilience review recommends 'adding redundancy, circuit breakers, and retry logic.' These are all examples of:
Redundancy (multiple instances), circuit breakers (fail-fast to prevent cascade), and retry logic (handle transient failures) are classic resilience patterns. They are engineering decisions made specifically to improve the system's ability to handle and recover from failures.
6 / 18
Slack message
**Sarah (SRE):** "Okay team, we're seeing intermittent errors with the /users endpoint. Initial diagnostics point to a potential spike in traffic coinciding with the recent marketing campaign launch. Let's implement some circuit breaker logic and increase the rate limit for that service."
This scenario tests understanding of applying resilience engineering concepts in a practical Slack communication. While increasing the rate limit is a valid action, the key phrase here – 'circuit breaker logic' – demonstrates proactive preparation for failure by isolating the affected service and preventing cascading issues. The correct answer correctly identifies that circuit breakers are a standard practice, reflecting a core resilience strategy. Options A and D highlight potential misinterpretations: insufficient error rates don't necessitate immediate action, and simply increasing rate limits without safeguards can be ineffective.
7 / 18
Liam (Lead Developer) comments on a PR: "I'm concerned about the lack of retry logic in this service. If the database is temporarily unavailable, we'll just get stuck in an error loop. We need to build resilience into our system—specifically, mechanisms to automatically handle transient failures and keep things moving."
Liam's comment highlights a key difference between traditional reliability and resilience engineering. While traditional reliability focuses on preventing failures from happening in the first place (e.g., robust database design), resilience engineering acknowledges that failures are inevitable. Implementing retry logic is a direct action to *prepare* for those transient errors, automatically recovering from them and maintaining service availability – this is the core of building a resilient system. The other options misinterpret Liam's concern or suggest alternative approaches not aligned with proactive resilience strategies.
8 / 18
Slack message
**Sarah (SRE):** "Okay team, we're seeing intermittent errors with the /users endpoint. Initial diagnostics point to a potential spike in traffic coinciding with the recent marketing campaign launch. Let's implement some circuit breaker logic and increase the rate limit for that service."
This scenario tests understanding of applying resilience engineering concepts in a practical Slack communication. While increasing the rate limit is a valid action, the key phrase here – 'circuit breaker logic' – demonstrates proactive preparation for failure by isolating the affected service and preventing cascading issues. The correct answer correctly identifies that circuit breakers are a standard practice, reflecting a core resilience strategy. Options A and D highlight potential misinterpretations: insufficient error rates don't necessitate immediate action, and simply increasing rate limits without safeguards can be ineffective.
9 / 18
Liam (Lead Developer) comments on a PR: "I'm concerned about the lack of retry logic in this service. If the database is temporarily unavailable, we'll just get stuck in an error loop. We need to build resilience into our system—specifically, mechanisms to automatically handle transient failures and keep things moving."
Liam's comment highlights a key difference between traditional reliability and resilience engineering. While traditional reliability focuses on preventing failures from happening in the first place (e.g., robust database design), resilience engineering acknowledges that failures are inevitable. Implementing retry logic is a direct action to *prepare* for those transient errors, automatically recovering from them and maintaining service availability – this is the core of building a resilient system. The other options misinterpret Liam's concern or suggest alternative approaches not aligned with proactive resilience strategies.
10 / 18
Slack message
**Sarah (SRE):** "Okay team, we're seeing intermittent errors with the /users endpoint. Initial diagnostics point to a potential spike in traffic coinciding with the recent marketing campaign launch. Let's implement some circuit breaker logic and increase the rate limit for that service."
This scenario tests understanding of applying resilience engineering concepts in a practical Slack communication. While increasing the rate limit is a valid action, the key phrase here – 'circuit breaker logic' – demonstrates proactive preparation for failure by isolating the affected service and preventing cascading issues. The correct answer correctly identifies that circuit breakers are a standard practice, reflecting a core resilience strategy. Options A and D highlight potential misinterpretations: insufficient error rates don't necessitate immediate action, and simply increasing rate limits without safeguards can be ineffective.
11 / 18
Liam (Lead Developer) comments on a PR: "I'm concerned about the lack of retry logic in this service. If the database is temporarily unavailable, we'll just get stuck in an error loop. We need to build resilience into our system—specifically, mechanisms to automatically handle transient failures and keep things moving."
Liam's comment highlights a key difference between traditional reliability and resilience engineering. While traditional reliability focuses on preventing failures from happening in the first place (e.g., robust database design), resilience engineering acknowledges that failures are inevitable. Implementing retry logic is a direct action to *prepare* for those transient errors, automatically recovering from them and maintaining service availability – this is the core of building a resilient system. The other options misinterpret Liam's concern or suggest alternative approaches not aligned with proactive resilience strategies.
12 / 18
Slack message
**Sarah (SRE):** "Okay team, we're seeing intermittent errors with the /users endpoint. Initial diagnostics point to a potential spike in traffic coinciding with the recent marketing campaign launch. Let's implement some circuit breaker logic and increase the rate limit for that service."
This scenario tests understanding of applying resilience engineering concepts in a practical Slack communication. While increasing the rate limit is a valid action, the key phrase here – 'circuit breaker logic' – demonstrates proactive preparation for failure by isolating the affected service and preventing cascading issues. The correct answer correctly identifies that circuit breakers are a standard practice, reflecting a core resilience strategy. Options A and D highlight potential misinterpretations: insufficient error rates don't necessitate immediate action, and simply increasing rate limits without safeguards can be ineffective.
13 / 18
Liam (Lead Developer) comments on a PR: "I'm concerned about the lack of retry logic in this service. If the database is temporarily unavailable, we'll just get stuck in an error loop. We need to build resilience into our system—specifically, mechanisms to automatically handle transient failures and keep things moving."
Liam's comment highlights a key difference between traditional reliability and resilience engineering. While traditional reliability focuses on preventing failures from happening in the first place (e.g., robust database design), resilience engineering acknowledges that failures are inevitable. Implementing retry logic is a direct action to *prepare* for those transient errors, automatically recovering from them and maintaining service availability – this is the core of building a resilient system. The other options misinterpret Liam's concern or suggest alternative approaches not aligned with proactive resilience strategies.
14 / 18
Reviewer: 'This service lacks circuit breakers. If the external API fails for more than 5 seconds, it will continuously retry, potentially overwhelming the upstream provider and causing cascading failures.' What is the primary goal of implementing a circuit breaker in this scenario?
Circuit breakers are designed to *prevent* a failing dependency from causing widespread issues. The core purpose is to temporarily halt requests to an unhealthy service, allowing it time to recover and preventing the retry logic from exacerbating the problem. Options A and C misinterpret circuit breakers' function; A addresses error handling generally, while C focuses on a specific symptom rather than the root cause.
15 / 18
David (DevOps): 'We're seeing increased latency in our payment processing service. Initial analysis suggests a correlation with recent deployments of the new fraud detection module. We need to consider how we can maintain availability during these periods.' What aspect of resilience engineering is David primarily addressing here?
David is focused on *proactive* resilience – anticipating potential issues (deployment-related latency) and preparing strategies to maintain service availability. The other options represent reactive measures or components of a broader resilience strategy but don't directly address the specific challenge outlined in the message.
16 / 18
PR Description: 'Implementing this new feature requires integration with a third-party service that is known to be unreliable. To mitigate potential downtime, we've added exponential backoff and jitter to the retry logic. However, this doesn't address the fundamental unreliability of the external service.' Which statement best describes the approach taken in this PR?
This PR demonstrates a common pitfall: applying reactive measures (retry logic) to *mask* an unreliable dependency instead of addressing the root cause. While useful for temporary mitigation, it doesn't fundamentally improve resilience against the external service's unreliability. The focus should be on decoupling and alternative solutions.
17 / 18
Maria (Tech Lead): 'Yesterday, we identified a bottleneck in our data pipeline due to a recent schema change. We've implemented a temporary workaround by duplicating the affected data set, which is consuming significant storage space. We're investigating more permanent solutions, but this buys us time.' What principle of resilience engineering does Maria's response illustrate?
Maria's action—implementing a temporary workaround—highlights the importance of *short-term resilience* – creating a bridge to allow continued operation while longer-term solutions are developed. While not ideal, it demonstrates an understanding that immediate functionality is more important than perfect stability in a degraded state.
18 / 18
Which of the following best describes the difference between 'robustness' and 'resilience' in the context of software engineering?
Robustness emphasizes designing systems to handle expected variations and errors gracefully – operating correctly under normal conditions. Resilience, conversely, focuses on the ability of a system to *adapt* and recover from unexpected failures or disruptions after they've occurred. These are distinct but complementary goals.
What will I practice in "Resilience Engineering Vocabulary"?
This is a Chaos Engineering exercise set. It walks through 18 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 18 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.