- A
Store session data in Azure Cache for Redis and configure all App Service instances to connect to the same Redis endpoint
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.
- B
Enable ARR affinity (sticky sessions) on the App Service to route each user's requests to the same instance
Why wrong: 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.
- C
Write session data to Azure Blob Storage as a JSON file keyed by session ID on every request
Why wrong: 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.
- D
Store session state in a Cosmos DB container with a TTL equal to the session timeout
Why wrong: 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.
Quick Answer
The correct solution is to store session data in Azure Cache for Redis and configure all App Service instances to connect to the same Redis endpoint. This works because when an App Service scales out, each instance runs its own process with isolated in-memory session state, so a request hitting a different instance cannot access the original session data. Azure Cache for Redis provides a centralized, distributed in-memory cache that all instances share, ensuring session continuity regardless of which instance handles the request. On the AZ-204 exam, this scenario tests your understanding of distributed session state patterns and the stateless design principle for scalable applications. A common trap is choosing sticky sessions (ARR affinity), which is not recommended because it defeats the purpose of scaling out and creates a single point of failure. Remember the mnemonic: "Scale out, share state—Redis is your distributed slate."
AZ-204 Practice Question: Azure Cache for Redis for distributed session…
This AZ-204 practice question tests your understanding of monitor, troubleshoot, and optimize azure solutions. Match the stated requirement to the specific cloud service, access model, or configuration option — many options are valid in isolation but not for this scenario. A key principle to apply: distributed session state. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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?
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.
Key principle: distributed session state
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.
Related concept
distributed session state
- ✗
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.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates often 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.
Detailed technical explanation
How to think about this question
Azure Cache for Redis implements the Redis protocol, which supports data structures like strings, hashes, and lists, making it ideal for storing session dictionaries. The ASP.NET Core session middleware can be configured with `AddStackExchangeRedisCache` to use Redis as a distributed cache, automatically serializing session data and handling concurrency. In a scaled-out App Service, all instances share the same Redis endpoint, ensuring session consistency even during instance recycling or scaling events.
KKey Concepts to Remember
- distributed session state
- Azure Cache for Redis
- App Service scale-out
- sticky sessions vs distributed cache
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
distributed session state
Real-world example
How this comes up in practice
A media company stores terabytes of video archives that are accessed once a year for audit purposes. Moving these objects to a cold storage tier (Azure Archive, S3 Glacier, or Google Nearline) costs a fraction of hot storage. Questions like this test whether you understand storage tiers, access frequency tradeoffs, and retrieval latency requirements.
What to study next
Got this wrong? Here's your next step.
Review distributed session state, then practise related AZ-204 questions on the same topic to reinforce the concept.
- →
Monitor, troubleshoot, and optimize Azure solutions — study guide chapter
Learn the concepts, then practise the questions
- →
Monitor, troubleshoot, and optimize Azure solutions practice questions
Targeted practice on this topic area only
- →
All AZ-204 questions
997 questions across all exam domains
- →
Microsoft Azure Developer Associate AZ-204 study guide
Full concept coverage aligned to exam objectives
- →
AZ-204 practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related AZ-204 practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Develop Azure compute solutions practice questions
Practise AZ-204 questions linked to Develop Azure compute solutions.
Develop for Azure storage practice questions
Practise AZ-204 questions linked to Develop for Azure storage.
Implement Azure security practice questions
Practise AZ-204 questions linked to Implement Azure security.
Connect to and consume Azure services and third-party services practice questions
Practise AZ-204 questions linked to Connect to and consume Azure services and third-party services.
Monitor, troubleshoot, and optimize Azure solutions practice questions
Practise AZ-204 questions linked to Monitor, troubleshoot, and optimize Azure solutions.
AZ-204 fundamentals practice questions
Practise AZ-204 questions linked to AZ-204 fundamentals.
AZ-204 scenario practice questions
Practise AZ-204 questions linked to AZ-204 scenario.
AZ-204 troubleshooting practice questions
Practise AZ-204 questions linked to AZ-204 troubleshooting.
Practice this exam
Start a free AZ-204 practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this AZ-204 question test?
Monitor, troubleshoot, and optimize Azure solutions — This question tests Monitor, troubleshoot, and optimize Azure solutions — distributed session state.
What is the correct answer to this question?
The correct answer is: 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.
What should I do if I get this AZ-204 question wrong?
Review distributed session state, then practise related AZ-204 questions on the same topic to reinforce the concept.
What is the key concept behind this question?
distributed session state
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 →
Last reviewed: Jun 11, 2026
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.
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.