Question 491 of 1,446
Manage a solution that can span multiple database technologies →mediumMultiple ChoiceObjective-mapped
PCDE Practice Question: Manage a solution that can span multiple database technologies
A company uses Memorystore for Redis with the 'volatile-lru' eviction policy. They notice that recently added keys with TTL are being evicted even though there is still memory available. What is the most likely cause?
⚠ Common exam trap
A common misconception is that 'volatile-lru' evicts all keys when memory is low, but in fact it only evicts keys with TTLs, leaving non-volatile keys untouched even if they consume the majority of memory.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The volatile-lru policy evicts only keys with an expiry set, and there are many keys without expiry occupying memory
The 'volatile-lru' eviction policy in Memorystore for Redis evicts only keys that have a TTL (expiry) set, using an LRU (Least Recently Used) algorithm among those keys. If many keys without expiry are consuming memory, the eviction process will still target only the volatile keys, even if overall memory is not fully exhausted, because the policy is constrained to evict only from the subset of keys with TTLs. This explains why recently added keys with TTL are being evicted prematurely — the non-volatile keys are 'protected' from eviction, forcing the eviction of volatile keys to free memory.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The volatile-lru policy evicts only keys with an expiry set, and there are many keys without expiry occupying memory
Why this is correct
volatile-lru evicts only keys with TTL. If many non-volatile keys consume memory, volatile keys may be evicted even if overall memory appears free.
- ✗
The allkeys-lru policy would be more appropriate
Why it's wrong here
allkeys-lru evicts any key, but that doesn't explain why volatile keys are being evicted with available memory.
- ✗
The maxmemory setting is not configured
Why it's wrong here
If maxmemory is not set, Memorystore uses the instance memory size; eviction occurs when memory is full, not when free.
- ✗
The maxmemory-policy is misconfigured
Why it's wrong here
The policy is correctly set to volatile-lru; the issue is memory allocation, not the policy itself.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
5 more ways this is tested on PCDE
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A Memorystore for Redis instance is running out of memory. The application uses Redis as a cache with key expiration. You want to prevent data loss for keys that have not reached their TTL. Which eviction policy should you configure?
medium- A.noeviction
- B.volatile-ttl
- C.allkeys-lru
- ✓ D.volatile-lru
Variation 2. A Cloud Memorystore for Redis instance is running out of memory. The team wants to automatically remove the least recently used keys when memory is full. Which eviction policy should they configure?
easy- A.volatile-lru
- B.volatile-ttl
- C.noeviction
- ✓ D.allkeys-lru
Why D: The `allkeys-lru` eviction policy is correct because it applies the LRU (Least Recently Used) algorithm to all keys in the Redis instance, not just those with an expiry set. This ensures that when memory is full, the least recently accessed keys are automatically removed, regardless of whether they have a TTL, which directly meets the requirement to free memory without manual intervention.
Variation 3. A Memorystore for Redis instance is experiencing out-of-memory errors, causing keys to be evicted. The application relies on all keys being present. The current maxmemory-policy is allkeys-lru. What should the engineer do to prevent evictions?
medium- ✓ A.Change the eviction policy to noeviction.
- B.Change the eviction policy to volatile-lru.
- C.Enable persistence to Cloud Storage to offload memory.
- D.Scale up the instance to a higher tier with more memory.
Why A: Changing the eviction policy to noeviction causes Redis to return errors instead of evicting keys when memory is full. This ensures that all existing keys remain present, which is critical for the application. While scaling up (option D) could increase memory capacity, it does not guarantee that evictions will be prevented if memory usage grows to exceed the new limit. The noeviction policy directly prevents evictions, at the cost of write failures when memory is exhausted.
Variation 4. A Memorystore for Redis instance is running out of memory. The application can tolerate some data loss but not crashes. The team wants to ensure the instance remains available without manual intervention. Which eviction policy should they configure?
hard- A.volatile-lru
- B.volatile-ttl
- C.noeviction
- ✓ D.allkeys-lru
Why D: (allkeys-lru) is correct because it allows Redis to evict the least recently used keys from the entire keyspace when memory is full, which keeps the instance available without crashing. Since the application can tolerate some data loss but not crashes, this policy ensures memory pressure is relieved automatically, preventing out-of-memory errors that would cause the instance to become unavailable.
Variation 5. A Memorystore for Redis instance is running out of memory. The application uses a mix of cache and session data. Which eviction policy should be chosen to minimize cache misses while ensuring session data is not evicted?
medium- A.noeviction
- ✓ B.volatile-ttl
- C.allkeys-lru
- D.allkeys-random
Why B: The volatile-ttl policy evicts keys with a TTL set, prioritizing those with the shortest remaining TTL. Since session data typically has a TTL and cache data may or may not, this policy allows you to protect session data by assigning it a longer TTL, while cache data with shorter TTLs is evicted first, minimizing cache misses.
Last reviewed: Jul 4, 2026
This PCDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCDE exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.