Build fluency in the vocabulary of finishing in-flight requests before a process actually exits.
0 / 5 completed
1 / 5
At standup, a dev mentions a process catching the termination signal and finishing its in-flight requests before actually exiting, rather than being killed mid-request. What is this practice called?
Graceful shutdown has a process catch the termination signal, typically SIGTERM, and finish its in-flight requests before actually exiting, rather than being killed abruptly mid-request. Graceful degradation is a different concept about reducing functionality under load while still running, not about the shutdown sequence itself. This finish-in-flight-work-first behavior is what prevents a routine deploy or scale-down from dropping requests a client is actively waiting on.
2 / 5
During a design review, the team wants a load balancer to stop sending new requests to an instance that's shutting down, while still letting that instance finish requests already in progress. Which capability supports this?
Connection draining coordinated with the shutdown sequence stops the load balancer from sending new requests to an instance that's shutting down, while still routing the already-in-flight requests through to completion on that same instance. Continuing to send new requests to a shutting-down instance risks those new requests being dropped the moment the process actually exits. This draining coordination between the load balancer and the instance's own shutdown handler is what makes a graceful shutdown actually effective end to end.
3 / 5
In a code review, a dev notices a shutdown handler waiting for all in-flight requests to complete, but only up to a bounded timeout, after which it force-exits regardless. What does this represent?
A bounded grace period balances letting in-flight requests complete against the risk of the shutdown hanging indefinitely if one request never finishes, for instance because it's stuck waiting on a downstream dependency that's itself unhealthy. A cache eviction policy is an unrelated concept about discarding cached data. This bounded timeout is what keeps a graceful shutdown from turning into an ungraceful hang during an already time-sensitive deploy or scale-down event.
4 / 5
An incident report shows requests were dropped mid-response during every deploy, because the process was killed with SIGKILL immediately rather than being given a chance to finish requests already in progress. What practice would prevent this?
Handling SIGTERM to drain in-flight requests within a bounded grace period before actually exiting lets a process finish the work a client is already waiting on, instead of dropping it the instant the process is asked to stop. Continuing to kill the process immediately with SIGKILL is exactly what caused the dropped mid-response requests in this incident, since SIGKILL gives a process no opportunity to clean up at all. This graceful handling of the termination signal is a baseline requirement for any service deployed with rolling updates.
5 / 5
During a PR review, a teammate asks why the team implements explicit graceful shutdown handling instead of just trusting the load balancer's own retry logic to resend any request that gets dropped mid-response. What is the reasoning?
A load balancer can safely retry a request that never actually reached the backend, but not one that was already partially processed and had a side effect, such as a payment being charged, since blindly retrying that request risks a duplicate charge. Graceful shutdown prevents that scenario from occurring in the first place by letting the in-flight request finish instead of being interrupted mid-processing. The tradeoff is the added implementation complexity of correctly handling the termination signal and bounding how long the process waits before it must exit anyway.
What does the "Graceful Shutdown Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to graceful shutdown vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 11 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.