AZ-204 Practice Question: Azure Cache for Redis for distributed session…
Users of a web application hosted on App Service are randomly signed out when the app is scaled out to three instances. Investigation shows that session data stored in in-process memory is not available when subsequent requests hit a different instance. What is the recommended solution?
⚠ Common exam trap
Test-takers frequently confuse ARR affinity (sticky sessions) as a complete solution, not realizing it only masks the problem by pinning users to instances, but fails to provide resilience against instance failures or scaling operations.
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
✓
Store session data in Azure Cache for Redis and configure all App Service instances to connect to the same Redis endpoint
When an App Service scales out to multiple instances, in-process session state is stored locally on each instance and is not shared. Azure Cache for Redis provides a centralized, in-memory data store that all instances can access, ensuring session data is available regardless of which instance handles a request. This is the recommended pattern for distributed session state in Azure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Store session data in Azure Cache for Redis and configure all App Service instances to connect to the same Redis endpoint
Why this is correct
Redis acts as a shared external session store. Each instance serializes the session to Redis on write and deserializes it on read. Because all instances point to the same Redis instance, any instance can serve any user's requests correctly, making the session store horizontally scalable and instance-independent.
- ✗
Enable ARR affinity (sticky sessions) on the App Service to route each user's requests to the same instance
Why it's wrong here
ARR affinity is a workaround that masks the problem without solving it. Sticky sessions break when an instance restarts or is removed during a scale-in event. They also create uneven load distribution, partially defeating the purpose of scaling out. Distributed session storage is the correct solution.
- ✗
Write session data to Azure Blob Storage as a JSON file keyed by session ID on every request
Why it's wrong here
Blob Storage works for session persistence but has higher latency than Redis (tens to hundreds of milliseconds per read/write vs microseconds). For high-traffic apps, this latency accumulates into noticeable response time degradation. Redis is optimized for this use case.
- ✗
Store session state in a Cosmos DB container with a TTL equal to the session timeout
Why it's wrong here
Cosmos DB can store session data but adds unnecessary cost and complexity compared to Redis. Redis is the industry standard for distributed caching and session state in .NET applications and is supported natively by the ASP.NET Core data protection and session middleware.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft 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 AZ-204 exam.