Build fluency in the vocabulary of how long a resolver may reuse a cached DNS answer.
0 / 5 completed
1 / 5
At standup, a dev mentions a DNS record specifying how many seconds a resolver is allowed to keep reusing a cached answer before it must ask the authoritative server again. What is this value called?
Time to live, or TTL, is the value attached to a DNS record specifying how many seconds a resolver may keep reusing a cached answer before it's required to query the authoritative server again for a fresh one. A CDN cache invalidation is a related but distinct concept about purging cached content at the edge, not about how long a DNS answer itself stays cached. This TTL is what determines the tradeoff between fast, cache-served lookups and how quickly a DNS change actually propagates out to every resolver that's already cached the old answer.
2 / 5
During a design review, the team lowers a record's TTL to a much shorter value in the hours leading up to a planned server migration, specifically so resolvers won't hold onto the old IP address for long once the record actually changes. Which capability does this lowered TTL provide?
Lowering the TTL ahead of time provides faster propagation of the upcoming change, since resolvers are forced to expire and re-check the record much sooner, meaning once the actual migration happens, most resolvers will only be serving the stale answer for a short window instead of however long the original, longer TTL would have allowed. Resolvers do not re-check with the authoritative server on every lookup regardless of TTL, since honoring the cached TTL is exactly the point of DNS caching in the first place. This planned TTL reduction ahead of a migration is a standard, well-known technique for minimizing the window of stale DNS answers during a cutover.
3 / 5
In a code review, a dev notices a critical record's TTL is set to twenty-four hours, and the team is planning a same-day emergency failover to a different IP address. What does this represent?
This is a propagation risk, since any resolver that already cached the old answer under a twenty-four-hour TTL has no reason to re-check the authoritative server until that TTL expires, meaning it will keep serving the stale IP address for up to a full day even after the emergency failover has already happened. A CSRF token is an unrelated web security concept, not a DNS caching one. This is exactly why a long-lived TTL on a record that might need an emergency failover is a liability, and why proactively lowering TTLs on critical records ahead of any planned or anticipated change is considered good practice.
4 / 5
An incident report shows a large fraction of users kept hitting a decommissioned server for nearly a full day after a DNS failover, because the record's TTL had been left at twenty-four hours with no advance reduction before the change was made. What practice would prevent this?
Lowering the record's TTL well in advance of any planned change gives resolvers time to expire and re-cache with the new, shorter value before the actual failover happens, so once the change is made, resolvers only serve the stale answer for that shorter window instead of up to a full day. Leaving the TTL at its long-lived default with no advance reduction is exactly what caused users to keep hitting the decommissioned server for nearly a day in this incident. This advance TTL-lowering is a standard, well-established practice for any planned DNS cutover where minimizing the stale-answer window actually matters.
5 / 5
During a PR review, a teammate asks why the team temporarily lowers a record's TTL before a planned migration instead of just leaving it at its normal, longer-lived value throughout. What is the reasoning?
A resolver won't re-check the authoritative server until its already-cached copy's TTL expires, so leaving a long TTL in place straight through a migration means any resolver that cached the old answer just before the cutover keeps serving that stale answer for the entire remaining duration of that long TTL. Temporarily shortening the TTL ahead of time ensures resolvers naturally expire their cached copies and re-check far sooner, catching the new answer shortly after it's published. The tradeoff is a temporary increase in DNS query volume against the authoritative server while the shortened TTL is in effect, a small cost against meaningfully shrinking the stale-answer window during a change that actually matters.
What does the "DNS Caching & TTL Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to dns caching & ttl 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 — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
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.