Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.
Question 1 · choose 1
An application uses an Azure Managed Redis cache on the Balanced tier with the OSS clustering policy. The team now wants to store embeddings in Redis and run vector similarity queries. What must they do?
AEnable the RediSearch module on the existing cache in its Advanced settings
BCreate a new cache with RediSearch, Enterprise clustering and NoEviction
CKeep the OSS clustering policy and run FT.CREATE through a cluster-aware client
DMove to the Flash Optimized tier for cheaper storage of large vector sets
Show the answer and why
AEnable the RediSearch module on the existing cache in its Advanced settings
Incorrect
Modules can't be added to an existing Azure Managed Redis instance.
BCreate a new cache with RediSearch, Enterprise clustering and NoEviction
Correct
Modules can only be added when a cache is created, and RediSearch requires the Enterprise policy and NoEviction.
CKeep the OSS clustering policy and run FT.CREATE through a cluster-aware client
Incorrect
The OSS clustering policy can't be used with the RediSearch module.
DMove to the Flash Optimized tier for cheaper storage of large vector sets
Incorrect
RediSearch isn't available on the Flash Optimized tier.
Vector search in Azure Managed Redis comes from RediSearch. Plan it at provisioning: pick Memory Optimized, Balanced or Compute Optimized, enable RediSearch, use the Enterprise clustering policy and NoEviction.
An Azure Managed Redis cache uses the default eviction policy. The application writes keys without expiration, the cache filled up, and new writes now fail instead of older keys being removed. No modules are in use. Which change lets Redis remove the least recently used keys under memory pressure?
AChange the eviction policy to allkeys-lru
BKeep volatile-lru; it already evicts the least recently used keys
CChange the eviction policy to NoEviction
DTurn off high availability to double the usable memory
Show the answer and why
AChange the eviction policy to allkeys-lru
Correct
allkeys-lru lets any key be evicted under memory pressure, whether or not it has a TTL.
BKeep volatile-lru; it already evicts the least recently used keys
Incorrect
volatile-lru only evicts keys that have a TTL, and these keys have none.
CChange the eviction policy to NoEviction
Incorrect
NoEviction never removes keys, so writes keep failing once memory is full.
DTurn off high availability to double the usable memory
Incorrect
High availability has nothing to do with which keys can be evicted, and turning it off risks losing data during maintenance.
The default policy is volatile-lru: only keys with an expiration are eligible for eviction. Setting TTLs on keys is the first defense; allkeys-lru is the policy that lets any key be evicted.
A product service uses Azure Managed Redis with the cache-aside pattern: on a price change it writes the database and then deletes the cached entry. Readers sometimes see the old price right after an update. The business now requires every read after a successful price update to return the new price. Which approach meets this?
AWrite-through caching that updates the database and the cache in one write
BShorten the TTL on price keys to one minute
CDelete the cached entry before writing the database instead of after the write
DChange the eviction policy to allkeys-lru
Show the answer and why
AWrite-through caching that updates the database and the cache in one write
Correct
Write-through refreshes the cache as part of the write, so readers see the new value immediately after a successful write.
BShorten the TTL on price keys to one minute
Incorrect
A shorter TTL narrows the window but still allows stale reads after an update.
CDelete the cached entry before writing the database instead of after the write
Incorrect
A reader can repopulate the cache from the old row between the delete and the database write.
DChange the eviction policy to allkeys-lru
Incorrect
Eviction handles memory pressure; it doesn't keep cached data consistent with the database.
Cache-aside invalidates on write and repopulates on the next read, so a reader can briefly get a miss or stale data. When read paths need read-after-write freshness, write-through caching is the documented alternative.
A Python worker connects to Azure Managed Redis with its user-assigned managed identity instead of an access key. Which two steps are part of a correct setup? (Choose TWO.)
AUse the identity's client ID as the user name
BAuthenticate with the identity's object ID as the user name and a token for https://redis.azure.com/.default as the password
CAdd a Microsoft Entra group that contains the identity as a Redis user
DConnect over the non-TLS port so the token can be inspected
ESend a new AUTH with a refreshed token before the current token expires
Show the answer and why
AUse the identity's client ID as the user name
Incorrect
The user value is the object ID of the identity or service principal.
BAuthenticate with the identity's object ID as the user name and a token for https://redis.azure.com/.default as the password
Correct
That's the documented user and password pair for Microsoft Entra authentication to the cache.
CAdd a Microsoft Entra group that contains the identity as a Redis user
Incorrect
Microsoft Entra groups aren't supported for cache authentication.
DConnect over the non-TLS port so the token can be inspected
Incorrect
Microsoft Entra authentication is supported only on TLS connections.
ESend a new AUTH with a refreshed token before the current token expires
Correct
Connections stay authenticated only if the client re-authenticates with a fresh token, at least three minutes before expiry.
Add the identity as a Redis user on the cache, then have the client request a token for the Redis scope, authenticate with the object ID and the token, and re-send AUTH with a fresh token before expiry, with some jitter across clients.
A Python service connects to an Azure Managed Redis cache that uses the OSS clustering policy. Which two statements describe how the client should connect? (Choose TWO.)
AHard-code the 85xx shard ports in configuration for faster start-up
BConnect to the cache's public IP address instead of its host name
CMake the initial connection to port 10000 on the cache host name
DUse a cluster-aware client that discovers shard ports with CLUSTER NODES
ETurn off TLS so the cluster redirects work
Show the answer and why
AHard-code the 85xx shard ports in configuration for faster start-up
Incorrect
These ports can change over time and shouldn't be hard-coded.
BConnect to the cache's public IP address instead of its host name
Incorrect
The IP address can change, for example after scaling; rely on the host name.
CMake the initial connection to port 10000 on the cache host name
Correct
With the OSS policy, clients start on port 10000.
DUse a cluster-aware client that discovers shard ports with CLUSTER NODES
Correct
The client connects straight to shards on ports in the 85xx range, which it learns from the cluster.
ETurn off TLS so the cluster redirects work
Incorrect
The cache requires TLS by default, and cluster connections work over TLS.
The OSS clustering policy exposes the Redis Cluster API, so clients connect directly to shards for the lowest latency. The Enterprise policy instead offers one proxied endpoint for clients that don't support clustering.
A cache for session data in a development environment must keep all its data in memory. It needs plenty of memory but little throughput, at a low price. Which Azure Managed Redis tier fits?
AMemory Optimized
BCompute Optimized
CBalanced
DFlash Optimized
Show the answer and why
AMemory Optimized
Correct
Its 8:1 memory-to-vCPU ratio suits memory-heavy, low-throughput use such as development and test.
BCompute Optimized
Incorrect
Its 2:1 ratio targets maximum throughput, the opposite of what's needed.
CBalanced
Incorrect
Balanced's 4:1 ratio is for standard workloads that need more compute than this one.
DFlash Optimized
Incorrect
Flash Optimized moves less-used data from RAM to NVMe storage, so not all data stays in memory.
Three tiers keep data in memory with different memory-to-vCPU ratios; Flash Optimized adds NVMe storage for large data sets at some cost to performance.
Your application stores about 10 GB of data in an Azure Managed Redis cache with high availability enabled. The Used Memory metric shows about 20 GB, and a colleague proposes moving to a SKU twice as large. What's the right reading?
AUsed Memory includes replica shards; watch Used Memory Percentage instead, which already accounts for replication
BThe data is duplicated by a client bug, so the larger SKU is needed
CTurn off high availability to halve memory use in production
DUsed Memory excludes replicas, so the dataset really is 20 GB
Show the answer and why
AUsed Memory includes replica shards; watch Used Memory Percentage instead, which already accounts for replication
Correct
With HA, the metric covers primary and replica memory, and the SKU limit already allows for replication.
BThe data is duplicated by a client bug, so the larger SKU is needed
Incorrect
The doubling is expected with high availability, not a bug.
CTurn off high availability to halve memory use in production
Incorrect
Without HA, data isn't replicated and is lost during maintenance; that's for development and test only.
DUsed Memory excludes replicas, so the dataset really is 20 GB
Incorrect
It's the other way around: the metric includes replica shards.
Choose the SKU by the actual dataset size. Used Memory adds replica memory when HA is on, while Used Memory Percentage is relative to the SKU limit; consider scaling when it stays above 75 percent.
A semantic cache built with RedisVL on Azure Managed Redis returns cached answers for prompts that mean something different from the cached prompt. Which change makes matching stricter?
ARaise the distance_threshold value
BLengthen the TTL of cached entries
CLower the distance_threshold value
DEmbed prompts with a different model from the one used for the cache
Show the answer and why
ARaise the distance_threshold value
Incorrect
A higher distance accepts prompts that are further apart, making the problem worse.
BLengthen the TTL of cached entries
Incorrect
TTL controls how long entries live, not how similar a prompt must be to match.
CLower the distance_threshold value
Correct
The threshold is a cosine distance from 0 to 2; lower values require prompts to be closer in meaning.
DEmbed prompts with a different model from the one used for the cache
Incorrect
Queries must use the same embedding model and dimensions as the index.
Semantic caching reuses an LLM response when a new prompt's embedding is within a threshold of a cached prompt's embedding. Tune the threshold, partition entries by tenant, model and prompt version, and set TTLs.