Learn the vocabulary of deciding which cached entry to discard once a cache is full.
0 / 5 completed
1 / 5
At standup, a dev mentions a cache that discards whichever entry hasn't been accessed for the longest time once it's full, making room for a new entry. What eviction policy is being described?
Least Recently Used, or LRU, discards whichever entry hasn't been accessed for the longest time once the cache is full, making room for a new entry based on recency of access. A cache that never evicts anything at all would grow unbounded and eventually exhaust its available memory. This recency-based eviction is one of the most common cache eviction policies precisely because recently accessed data is often likely to be accessed again soon.
2 / 5
During a design review, the team wants a cache that tracks how frequently each entry has been accessed overall, evicting the one accessed the fewest total times rather than the one accessed longest ago. Which capability supports this?
Least Frequently Used, or LFU, eviction tracks how frequently each entry has been accessed overall, evicting the one accessed the fewest total times rather than simply the one accessed longest ago. Evicting based purely on recency, with no regard for total frequency, can discard a genuinely popular entry just because it happens not to have been accessed in the last moment. This frequency-based tracking is what LFU offers as an alternative to LRU when overall popularity matters more than recency.
3 / 5
In a code review, a dev notices the cache's eviction policy was chosen deliberately after considering the actual access pattern of the cached data, rather than defaulting to whichever policy happened to be the library's out-of-the-box setting. What does this represent?
Deliberate eviction policy selection matches the chosen policy, whether LRU, LFU, or another, to the cached data's actual access pattern, rather than defaulting to whatever the library's out-of-the-box setting happens to be. Using the default with no consideration of the real access pattern risks a mismatch, like LRU evicting a genuinely popular entry that just wasn't accessed in the last moment. This deliberate matching is what keeps a cache's hit rate high for the specific workload it's actually serving.
4 / 5
An incident report shows a cache's hit rate dropped noticeably after switching to a new dataset, because the LRU eviction policy kept discarding a small set of consistently popular entries whenever a brief lull in their access pattern happened to coincide with the cache filling up. What practice would prevent this?
Evaluating whether an LFU or a hybrid eviction policy better matches the new dataset's access pattern, rather than defaulting to LRU unconditionally, addresses exactly the hit-rate drop this incident describes, since a consistently popular entry with an occasional lull can be unfairly evicted under pure recency-based LRU. Keeping LRU unchanged regardless of the dataset's actual pattern ignores that mismatch entirely. This deliberate evaluation is a standard step whenever a cache's underlying workload changes meaningfully.
5 / 5
During a PR review, a teammate asks why the team evaluates LRU against LFU for a given cache instead of just always using LRU since it's the more common default. What is the reasoning?
LRU can unfairly evict a consistently popular entry during a brief lull in its access pattern, since it only considers recency and not overall frequency. LFU tracks overall frequency instead, and may better preserve a genuinely popular entry depending on the actual workload. The tradeoff is that LFU requires tracking additional per-entry state and can itself struggle to evict a once-popular entry that's no longer actually relevant, which is why some caches use a hybrid policy combining both signals.
What does the "Cache Eviction Policies Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to cache eviction policies 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.