How Do You Increase Read Cache in Azure Cache for Redis?
Short answer
A Decrease maxmemory-reserved so more of the Standard tier's memory holds cached data for reads instead of being reserved for Redis internals.
Question
Key Takeaways
Tests the distinction between the maxmemory-reserved memory reservation and the Maxmemory eviction policy, trapping candidates into picking volatile-lru even though it is already the default.
Azure Cache for Redis reserves memory per instance for non-cache operations, and the maxmemory-reserved setting controls how much is held back. On a default Standard tier instance that already uses volatile-lru, decreasing that reservation is what frees memory for cached read operations.
Common mistake: Choosing D (volatile-lru) because it sounds like the policy that best serves cache reads, when in fact Azure Cache for Redis Standard instances already default to volatile-lru, so selecting it frees no additional memory.
Expert Analysis
Why the Answer Is Correct
To give read operations more cache, you must free memory that the default Standard tier instance reserves for Redis internals rather than for data. The maxmemory-reserved setting is exactly that reservation: as quoted in the thread from Microsoft guidance, the value covers memory "reserved for non-cache operations, such as replication during failover" (sonnov24). Decreasing maxmemory-reserved on redis1 lets the same instance hold more cached keys, so read operations hit memory instead of missing or being evicted. Because the default maxmemory policy is already volatile-lru, the only lever that actually changes available read capacity is the reservation, which makes option A the effective configuration. This reduction should be made gradually and monitored, since too small a reservation can hurt failover and replication stability.Why the Other Options Are Wrong
Increasing maxmemory-reserved (B) takes memory away from cached data, moving in the opposite direction of the goal. Setting noeviction (C) stops Redis from evicting anything, so once memory fills, writes fail with out-of-memory errors while reads still only see what is already stored; it does not add read cache capacity. Setting volatile-lru (D) is already the default Maxmemory policy on Azure Cache for Redis Standard instances, so explicitly selecting it changes nothing on redis1. Option D is therefore a no-op dressed up as eviction tuning, which is why the vote split between A and D is misleading rather than evidence for D.Community Comment Notes
sonnov24 and lincio96 both landed on A, with lincio96 reasoning that reducing the reservation expands memory available for cached data for both reads and writes. Mattt, Vichu_1607, emma09 and bbc9a52 chose D, arguing volatile-lru prioritizes frequently accessed keys; bbc9a52 wrote that the "Maxmemory policy determines how Redis handles keys when memory reaches the configured maximum limit", which is accurate but ignores that this policy is already the default. emma09 added simply "I go with D", and _tharindus picked C (noeviction), which would actually cause write failures under memory pressure. The D camp is essentially answering a different question about desirable eviction behavior rather than how to raise read capacity on an instance that already uses volatile-lru.Official Reference
https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-memory-management
This link opens the official vendor documentation in a new tab.
Exam Strategy
When a stem says the instance uses default settings, first work out what is already configured — Azure Cache for Redis Standard defaults to volatile-lru, so any option that picks an eviction policy is usually a no-op. Then look for the memory-management setting, maxmemory-reserved, and reason about which direction frees data memory.
Frequently Asked Questions
Why isn't volatile-lru the right Maxmemory policy change for redis1?
What happens if maxmemory-reserved is decreased too far?
Community Votes
56% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 7 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 7
-
sonnov24 👍 5 Answered Ahttps://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-memory-management Microsoft: "The maxmemory-reserved setting configures the amount of memory, in MB per instance in a cluster, that is reserved for non-cache operations, such as replication during failover. Setting this value allows you to have a more consistent Redis server experience when your load varies. This value should be set higher for workloads that write large amounts of data. When memory is reserved for such operations, it's unavailable for storage of cached data."
-
lincio96 👍 4 Answered AI'd choose A because: Decreasing maxmemory-reserved (option A) directly increases the amount of memory available for storing cached data by reducing the memory reserved for Redis internal operations. This effectively increases the available memory for both read and write operations. While you need to be cautious not to reduce it too much (to avoid stability issues), this option provides more memory for caching data, which helps with read operations.
-
Mattt 👍 3 Answered DSetting the Maxmemory policy to volatile-lru will allow the cache to evict the least recently used keys with expiration, which helps increase available cache space for read operations by prioritizing frequently accessed data.
-
Vichu_1607 👍 2 Answered DD. Set the Maxmemory policy to volatile-lru.
-
bbc9a52 👍 1 Answered DAnswer: D. Set the Maxmemory policy to volatile-lru. Explanation: The Maxmemory policy determines how Redis handles keys when memory reaches the configured maximum limit.
Show 2 more comments
-
emma09 👍 1 Answered DYou need to configure a Maxmemory policy... I go with D
-
_tharindus 👍 1 Answered CSet the Maxmemory policy to noeviction
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.