Learn how to describe and discuss fault injection techniques in chaos engineering: latency injection, error injection, resource exhaustion, and network partition.
0 / 14 completed
1 / 14
A team says: 'We are going to inject latency into the payment service dependency.' What will they do?
Latency injection is one of the most common and valuable chaos experiments: real production failures often manifest as slow dependencies rather than hard errors. Latency injection tests whether callers have appropriate timeouts, circuit breakers, and fallback logic. 'Injecting 2 seconds of latency' means adding a 2-second artificial delay to the targeted service's responses — not crashing it, not returning errors, just slowing it down.
2 / 14
What is the correct way to describe an error injection experiment?
Error injection means making a service return specific error responses (HTTP 4xx/5xx, gRPC error codes, etc.) at a defined rate — without actually breaking the underlying service. The description must include: the error type (HTTP 500), the injection rate (30%), the target (recommendation service), and the expected resilience behavior being tested (graceful degradation on the product page). 'Turning off the database' is not controlled error injection — it is a broader, less targeted disruption.
3 / 14
An engineer reports: 'We observed resource exhaustion on the primary node.' What happened?
Resource exhaustion experiments test a different failure mode from latency or error injection: they simulate the resource constraint failures that happen in production due to memory leaks, runaway processes, disk-filling logs, or connection pool exhaustion. When reporting, specify the resource type: 'We exhausted available memory on the primary node to 95% utilization' or 'We filled the disk to 100% to test log rotation alerts and database failover.'
4 / 14
What is a 'network partition' and how is it typically described in chaos engineering?
A network partition (also called a split-brain scenario) blocks network communication between specific components. It is more targeted than latency injection — no traffic reaches the destination rather than slow traffic. Description should specify: which services are partitioned from each other, the protocol/port affected, and the expected behavior being tested (fallback, failover, error handling). Network partitions are particularly important for distributed systems, databases, and consensus algorithms.
5 / 14
Which sentence correctly compares two fault types?
Distinguishing fault types is important for experiment design: latency injection tests timeout configuration, circuit breaker sensitivity, and degradation under slow dependencies. Error injection tests error handling code paths, fallback logic, and retry behavior. Resource exhaustion tests alerting, auto-scaling, and graceful degradation under resource pressure. Network partition tests split-brain handling, failover, and distributed consensus. Each reveals different resilience gaps.
6 / 14
PR Description
During a code review of the new user onboarding flow, Sarah comments: 'I'm seeing some intermittent failures when provisioning accounts. The API response times are consistently high, and sometimes we get a 502 Bad Gateway error. I've added a circuit breaker to the account creation service to mitigate this, but it's still happening occasionally.'
Which of the following best describes Sarah's observations regarding potential fault injection?
Sarah's description points towards resource exhaustion. The consistently high response times and intermittent 502 errors strongly suggest that the account creation service is overloaded, preventing it from processing requests efficiently. While latency could be a contributing factor, the specific error code (502) combined with performance metrics indicates a more fundamental issue: the system's resources are being consumed faster than they can be replenished. The circuit breaker is a band-aid solution; the root cause – insufficient resources – remains.
7 / 14
PR Description
During a code review of the new user onboarding flow, Sarah comments: 'I'm seeing some intermittent failures when provisioning accounts. The API response times are consistently high, and sometimes we get a 502 Bad Gateway error. I've added a circuit breaker to the account creation service to mitigate this, but it's still happening occasionally.'
Which of the following best describes Sarah's observations regarding potential fault injection?
Sarah's description points towards resource exhaustion. The consistently high response times and intermittent 502 errors strongly suggest that the account creation service is overloaded, preventing it from processing requests efficiently. While latency could be a contributing factor, the specific error code (502) combined with performance metrics indicates a more fundamental issue: the system's resources are being consumed faster than they can be replenished. The circuit breaker is a band-aid solution; the root cause – insufficient resources – remains.
8 / 14
PR Description
During a code review of the new user onboarding flow, Sarah comments: 'I'm seeing some intermittent failures when provisioning accounts. The API response times are consistently high, and sometimes we get a 502 Bad Gateway error. I've added a circuit breaker to the account creation service to mitigate this, but it's still happening occasionally.'
Which of the following best describes Sarah's observations regarding potential fault injection?
Sarah's description points towards resource exhaustion. The consistently high response times and intermittent 502 errors strongly suggest that the account creation service is overloaded, preventing it from processing requests efficiently. While latency could be a contributing factor, the specific error code (502) combined with performance metrics indicates a more fundamental issue: the system's resources are being consumed faster than they can be replenished. The circuit breaker is a band-aid solution; the root cause – insufficient resources – remains.
9 / 14
PR Description
During a code review of the new user onboarding flow, Sarah comments: 'I'm seeing some intermittent failures when provisioning accounts. The API response times are consistently high, and sometimes we get a 502 Bad Gateway error. I've added a circuit breaker to the account creation service to mitigate this, but it's still happening occasionally.'
Which of the following best describes Sarah's observations regarding potential fault injection?
Sarah's description points towards resource exhaustion. The consistently high response times and intermittent 502 errors strongly suggest that the account creation service is overloaded, preventing it from processing requests efficiently. While latency could be a contributing factor, the specific error code (502) combined with performance metrics indicates a more fundamental issue: the system's resources are being consumed faster than they can be replenished. The circuit breaker is a band-aid solution; the root cause – insufficient resources – remains.
10 / 14
Alex: 'We're running a simulation to mimic network partition scenarios. The goal is to observe how our microservices degrade under intermittent connectivity between the authentication and user profile services. We'll use synthetic traffic generation to create periods of complete loss of communication.' What type of fault injection is Alex describing?
Alex is describing **latency** fault injection. Latency involves intentionally adding delays to communication paths, mimicking real-world network issues or overloaded systems. The key here is the focus on *increasing response times*, which distinguishes it from data corruption (random errors), resource exhaustion (overload), and network partition (complete disconnection).
11 / 14
David writes in a Slack message: 'I've deployed an error injection tool that randomly returns HTTP 500 status codes during API calls. We need to monitor the impact on user authentication rates.' What is David primarily testing with this action?
David is testing **error** injection. The deliberate introduction of HTTP 500 status codes simulates a failure condition. While this *could* indirectly impact latency, the primary goal is to observe how the system handles and recovers from an error, focusing on the application's ability to deal with unexpected failures rather than just speed.
12 / 14
Maria (in a PR description) states: 'To assess the resilience of our image processing pipeline, we introduced artificial delays in each stage. This resulted in a significant increase in the overall processing time for large images and highlighted potential bottlenecks.' What specific fault injection technique is Maria utilizing?
Maria is employing **latency** fault injection. By deliberately inserting delays into each stage of the image processing pipeline, she's mimicking a slow or congested network environment. This allows them to identify performance bottlenecks and understand how the system behaves under increased load – a core element of latency testing.
13 / 14
Ben says: 'We're using Chaos Mesh to simulate a network partition between our frontend and backend services. We want to see how quickly the UI degrades when users can no longer access API data.' What is Ben primarily evaluating?
Ben is evaluating **network partition** fault injection. A network partition simulates a scenario where communication between services is completely severed. This allows teams to understand how the system responds when critical connectivity is lost and to test recovery mechanisms – specifically focusing on service availability and resource utilization during that disruption.
14 / 14
Which of the following best describes the difference between 'latency' and 'error' in the context of fault injection?
Latency specifically addresses the *speed* of operations – artificially increasing response times. Conversely, **error** represents simulating application failures (e.g., HTTP status codes) or data corruption. These are distinct mechanisms for introducing problems into a system.
What will I practice in "Fault Injection Vocabulary — Latency, Error, Resource Exhaustion, Network Partition"?
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.