You read an AZ-305 caching scenario, and two of the options look reasonable. Decide from the job the requirement assigns to the cache. App data that the application reads repeatedly, plus session or cart state shared across app instances, points to a Redis-style application cache. Cacheable HTTP content served to users at edge locations, such as static assets or safe GET responses, points to a CDN or Azure Front Door edge cache.
The trap is treating the two as interchangeable. They sit at different points in the request path. A Redis-style cache sits behind the application and keeps the app from re-reading the data store. An edge cache sits in the HTTP delivery path and serves users cacheable content without hitting the origin every time.
The exam measures this decision directly. The current study guide lists "Recommend a caching solution for applications" as a task under Design an application architecture, in the Design infrastructure solutions domain, which is 30-35% of the exam (skills measured as of April 17, 2026) (AZ-305 study guide). The English language version of the exam was updated on April 17, 2026, so recheck the study guide before you book (AZ-305 exam page).
The cues that pick the cache
Match the scenario wording to a job before you look at the answer choices.
- If the scenario says the application reads the same data repeatedly, a product catalog is read-heavy, or a database is under heavy read load, the answer is a Redis-style application cache.
- If it says shopping-cart or session state must survive scale-out across app instances, the answer is a Redis-style application cache.
- If it says users in multiple regions need images, CSS, or JavaScript faster, or large files with reduced origin load, the answer is a CDN or Front Door edge cache.
- If it says authenticated or user-specific responses must be served, edge caching is off the table for that route.
- If it says origin selection, failover, or layer 7 routing, the scenario is asking a routing question. Front Door does both routing and caching, so name the job the requirement assigns before you pick.
What each service actually does
Azure Cache for Redis and Azure Managed Redis
Microsoft describes Azure Cache for Redis as an in-memory data store based on the Redis software that improves the performance and scalability of an application that uses backend data stores heavily. The overview lists data cache, content cache, session store, job and message queuing, and distributed transactions as the key scenarios (Azure Cache for Redis overview). The session store pattern is the exam cue for cart state. Storing too much in a cookie can hurt performance, because the cookie grows and is passed and validated with every request. The typical solution uses the cookie as a key and keeps the associated data in an in-memory cache, which is faster than a full relational database.
The overview carries an important notice. Azure Cache for Redis announced its retirement timeline for all SKUs, and Microsoft recommends moving existing instances to Azure Managed Redis as soon as you can. So when an answer choice names Azure Cache for Redis, read the role the cache plays in the scenario. In a current architecture review, evaluate Azure Managed Redis for new or migrated designs.
Microsoft describes Azure Managed Redis as an in-memory data store based on the Redis Enterprise software. Microsoft operates the service and hosts it on Azure, and any application within or outside of Azure can use it. It supports the key patterns, including data cache, session store, deduplication, leaderboards, job and message queuing, and distributed transactions, and it can be deployed alongside App Service, Functions, Container Apps, Azure SQL, or Cosmos DB (Azure Managed Redis overview).
The mechanism behind the data cache scenario is the cache-aside pattern. The application checks the cache first and loads data into the cache on demand when there is a miss. When the data changes, it writes the change to the data store and invalidates the corresponding cache item. The pattern page says to use it when resource demand is unpredictable, and that it is a poor fit when the data is sensitive or security related, when most requests miss the cache, or when session state in a web farm would create client-server affinity. It works best for relatively static data that applications read frequently (Cache-Aside pattern).
Azure Front Door and CDN edge caching
Microsoft describes Azure Front Door as a modern content delivery network with dynamic site acceleration and load balancing capabilities. When caching is configured on a route, the edge site that receives a request checks its cache for a valid response and forwards the request to the origin on a miss. Each edge site manages its own cache, so requests might be served by different edge sites (Azure Front Door caching). Caching at the edge reduces the traffic sent to the origin and can significantly decrease latency and reduce the load on origin servers.
Only GET requests are cacheable. All other request methods are always proxied through the network. Static assets such as images, CSS, and JavaScript files are ideal for caching, while dynamic assets such as authenticated API endpoints shouldn't be cached, to prevent the leakage of personal information. The page recommends separate routes for static and dynamic assets, with caching disabled for the dynamic route, and warns that a misconfiguration can inadvertently cache user-specific data that is then shared by multiple users (Azure Front Door caching).
Azure Front Door and Azure CDN are both services that offer global content delivery with intelligent routing and caching at the application layer. Track the retirement dates. Azure CDN Standard from Microsoft (classic) is retiring on September 30, 2027, and Azure Front Door (classic) is retiring on March 31, 2027, and both migrate to Azure Front Door Standard or Premium (Azure Front Door and Azure CDN comparison).
The decision in one table
| Redis-style application cache | CDN or Front Door edge cache | |
|---|---|---|
| What it is | An in-memory data store the application reads and writes | A cache in the HTTP delivery path at edge locations |
| What it holds | App data, session and cart state, queues, transactions | Cacheable GET responses (static assets, large files) |
| Who queries it | Application code, by key | The client's request, by URL |
| The scenario cue | "Shared cart state across app instances" | "Users worldwide need images and JavaScript faster" |
| Verdict | Pick it when the app owns the cache key and the data changes | Pick it when the content is cacheable HTTP served to users |
When a scenario wants both
Both caches can appear in the same architecture, doing different jobs. A retail site can serve product images and JavaScript from the edge while the app keeps product metadata and cart state in a Redis-style cache. The edge cache lowers the latency users see for content, and the app cache lowers repeated backend reads.
That does not make "both" the exam answer. When a prompt stacks several requirements, weigh the requirement the scenario is built to measure, and pick the cache that serves it first. A prompt about global users and static content is an edge-caching answer. A prompt about shared session state across scaled-out app instances is a Redis-style answer. When a scenario really asks for both, state each job separately in the design so the requirement each service serves is visible.
Worked scenario: the retail catalog and cart
A retailer runs a web app in Azure. The requirements:
- Product images, CSS, and JavaScript should load quickly for customers in North America, Europe, and Asia.
- The product catalog database receives repeated reads for popular items.
- Shopping-cart state must survive scale-out across multiple app instances.
- Authenticated checkout APIs must not leak user-specific responses.
- The team must avoid redesigning the global routing layer in this decision.
Classify each requirement before you pick a service.
The static assets go to the edge. Images, CSS, and JavaScript are cacheable GET content, and static assets are ideal for edge caching. Front Door or CDN caching serves them from edge locations near the users. Caching helps reduce the traffic sent to the origin and can significantly decrease latency.
The repeated catalog reads go behind the app. If every app instance asks the database for the same popular item, a Redis-style cache with the cache-aside pattern answers the repeated reads. The app checks the cache, falls back to the database on a miss, and invalidates the item when the catalog changes.
The shopping-cart state goes behind the app, not to the edge. Session store is a documented Redis scenario, and keeping cart data keyed by the user cookie in the cache is faster than a full relational database.
The authenticated checkout APIs get no edge caching. Misconfigured edge caching can share user-specific data across users, so the dynamic route runs with caching disabled.
Strong answer: Use Front Door or CDN caching for the public static assets, a Redis-style cache for the catalog reads and the cart state, and no edge caching for the checkout APIs. The routing layer stays out of this decision.
What the wrong answer reveals
- If you answer CDN for session state, you cached in the wrong place. Session state has to be associated with a user and available to the app instances, and a shared edge HTTP cache is not a session store.
- If you answer Redis for global image delivery, you solved the wrong latency problem. Redis-style caching cuts backend data-store latency for app code. It does not place static files at edge locations near users.
- If you answer Front Door because the prompt says global, check whether the requirement is caching or routing. Front Door does both. If the scenario asks for origin selection or failover, the decision belongs to the routing design, and the caching requirement may not be part of it.
- If an answer choice names a retiring service, the decision does not change. The cache's job still picks the answer first. The retirement notice matters in a current architecture review, where the migration path is Azure Managed Redis for Redis-style designs and Azure Front Door Standard or Premium for CDN classic designs.
A drill for this boundary
Before you read the answer choices, write one phrase next to the prompt.
- "app reads the same data repeatedly" means a Redis-style cache.
- "shared cart or session state" means a Redis-style cache.
- "static files near global users" means a CDN or Front Door edge cache.
- "authenticated or user-specific response" means no edge caching for that route.
- "origin selection, failover, or layer 7 routing" means the scenario is asking a routing question.
If a caching question keeps costing you points, start with the free AZ-305 assessment. It is free, needs no card, and returns a Readiness Report with your top gaps (free AZ-305 assessment). For each caching question you miss, write one line naming the job you misread, such as "I treated shared session state as edge content." Fix that boundary, then work the nearby scenarios again. The full AZ-305 Pass Plan is your ranked list of repair tasks, with one targeted fix for each gap CramHQ finds in your practice. After the assessment, keep working the caching scenarios: CramHQ measures each boundary miss in exam points and orders the list so the heaviest gap is first. The practice tests and the timed final simulation check your readiness on the way to the exam. The full path is 34.99 USD for 12 months of access, and the first repair is free (AZ-305 course).