How Do You Increase Read Cache in Azure Cache for Redis?
You have a Standard tier instance of Azure Cache for Redis named redis1 configured with the default settings. You need to configure a Maxmemory policy to increase the amount of cache available for read operations. How should you configure the Maxmemory policy?
Community Votes
56% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (7 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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?
Azure Cache for Redis Standard tier already defaults to volatile-lru, so selecting it changes nothing on the instance. The extra read cache must come from lowering the maxmemory-reserved reservation instead.
What happens if maxmemory-reserved is decreased too far?
You free memory for cached data, but the reservation also covers non-cache work such as replication during failover. Setting it too low risks instability, so lower it gradually and monitor evictions and latency.