Azure Cache for Redis vs CDN: What AZ-305 Caching Questions Expect
For AZ-305, choose Redis-style caching when the application needs fast access to frequently read data, shared session state, shopping carts, rate counters, or cache-aside behavior close to the app tier. Choose CDN or Azure Front Door caching when the requirement is to cache HTTP responses, static assets, large files, or short-lived public API responses at edge locations near users. The exam trap is confusing a data cache with an edge cache: Redis sits behind the application and helps the app avoid repeated data-store work; Front Door/CDN sits in the HTTP path and helps users receive cacheable content without hitting the origin.
This is in scope because Microsoft lists AZ-305 infrastructure solutions at 30-35%, and the current study guide's application architecture section includes "Recommend a caching solution for applications" (AZ-305 exam page, AZ-305 study guide).
Decision Shortcut
Pick Redis-style caching when the prompt says app data or user state. Microsoft describes Azure Cache for Redis as an in-memory data store for apps that heavily use backend data stores, with scenarios such as data cache, content cache, session store, job/message queuing, and transactions. Microsoft also now says Azure Cache for Redis has announced a retirement timeline for all SKUs and recommends moving existing instances to Azure Managed Redis as soon as possible (Azure Cache for Redis overview).
For current architecture language, understand Azure Managed Redis too. Microsoft describes Azure Managed Redis as a managed in-memory data store that supports patterns such as data cache, session store, deduplication, leaderboards, queues, and transactions, and it can be deployed with App Service, Functions, Container Apps, Azure SQL, or Cosmos DB (Azure Managed Redis overview).
Pick Front Door/CDN caching when the prompt says edge, HTTP, static files, cache-control, global users, or origin offload. Microsoft says Azure Front Door is a modern CDN with dynamic site acceleration and load-balancing capabilities, and that edge caching can reduce origin traffic and latency. It also warns that authenticated API endpoints should not be cached because user-specific data can leak; static assets such as images, CSS, and JavaScript are ideal candidates (Front Door caching).
Data Cache Or Edge Cache?
The diagram is intentionally small. It gives you a first decision: is the cache used by the application to retrieve data, or by the edge to answer HTTP requests?
Decision Cards
Redis-Style App Cache
Use Redis-style caching when the scenario describes hot reference data, profile lookups, product catalog reads, shopping-cart/session state, leaderboard-like data, distributed locks or counters, or a database under heavy read load. The application owns the cache key, reads from the cache first, and falls back to the database or service when there is a miss.
The cache-aside pattern is the exam-friendly version of that design. Microsoft says cache-aside loads data into a cache on demand from a data store and helps maintain a strategy for stale data. It is useful when resource demand is unpredictable, but it is a poor fit for sensitive/security data, mostly uncached workloads, or session state that depends on client-server affinity in a web farm (Cache-Aside pattern).
Exam clue: "The product database is under heavy read load, and all web instances need shared access to hot product data." That points to an application data cache, not an edge CDN answer.
Current-service nuance: if an answer choice says Azure Cache for Redis, recognize the exam pattern. In a real 2026 architecture review, call out the retirement notice and evaluate Azure Managed Redis for new or migrated designs.
Front Door Or CDN Edge Cache
Use Front Door/CDN caching when the scenario says users are globally distributed and the workload serves cacheable HTTP content: images, CSS, JavaScript, downloads, marketing pages, or GET API responses that are safe to share. The edge cache is not queried by your app code like a database. It responds in the HTTP delivery path when a valid cached response exists.
Microsoft says Front Door checks the edge cache for a valid response when caching is configured on a route, forwards to origin on a miss, and each edge site manages its own cache. Microsoft also says only GET requests are cacheable and other request methods are proxied through the network (Front Door caching).
Exam clue: "Users worldwide download product images and JavaScript files; minimize latency and reduce traffic to the origin." That is an edge-cache answer.
Current-service nuance: Microsoft says Azure Front Door and Azure Content Delivery Network both provide global content delivery, intelligent routing, and caching at the application layer. But the same comparison page says Azure CDN Standard from Microsoft (classic) is retiring on September 30, 2027 and points migration to Azure Front Door Standard/Premium (Front Door and CDN comparison).
When Both Are Correct
Many production architectures use both, but for different reasons. A retail site might use Front Door caching for product images and JavaScript, while the app uses Redis-style caching for product metadata, inventory read models, or anonymous session context. The edge cache lowers user-facing content latency. The app cache lowers repeated backend reads.
That does not mean the exam answer is always "both." AZ-305 scenarios usually include a strongest requirement. If the prompt says "global users and static content," edge caching is the cleaner first answer. If it says "shared session state across scaled-out app instances," Redis-style caching is the cleaner first answer.
Worked Scenario: Retail Catalog And Cart
A retailer runs a web app in Azure. 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.
- Architects must avoid redesigning the global routing layer in this decision.
Step 1: classify the public assets.
Images, CSS, and JavaScript are HTTP assets that can be safely cached when headers and invalidation are designed correctly. Front Door/CDN caching fits because Microsoft identifies static assets as ideal for edge caching and says caching can reduce origin load and latency.
Step 2: classify repeated catalog reads.
The product catalog data is app data. If every app instance repeatedly asks the database for the same popular item metadata, use a Redis-style cache with a cache-aside pattern. The app checks the cache, falls back to the origin store on a miss, then sets an expiration or invalidates the item when the data changes.
Step 3: classify shopping-cart state.
Shopping-cart or user history state belongs behind the application, not in a public edge cache. Microsoft lists session store as a Redis scenario: store too much in cookies and performance suffers; use a cookie as a key and retrieve the associated data from an in-memory cache. For current designs, evaluate Azure Managed Redis; if the exam uses the older product name, understand the Redis role.
Step 4: protect authenticated APIs.
Do not cache user-specific checkout responses at the edge. Microsoft warns that misconfigured edge caching can share user-specific data across users, and recommends disabling caching for dynamic/authenticated routes.
Strong answer:
Use Front Door/CDN caching for public static assets, Redis-style caching for shared product-data reads and session/cart state, and disable edge caching for authenticated checkout APIs. Send routing or load-balancing choices to the separate ingress design, not to this caching decision.
What Wrong Answers Reveal
If you choose CDN for session state, you are caching in the wrong place. Session state must be associated with a user and safely available to app instances; a shared edge HTTP cache is not the session store.
If you choose Redis for global image delivery, you are solving the wrong latency problem. Redis may reduce backend data-store latency for app code, but it does not place static files at global points of presence for users.
If you choose Front Door only because the prompt says "global," check whether the actual requirement is caching or routing. Front Door can do both, but AZ-305 may be asking you to choose an ingress/load-balancing service. For that boundary, use the AZ-305 load balancing decision guide.
If you choose a retiring service name without nuance, update your study notes. Exam material and answer choices can lag service naming, but a real architect should notice Microsoft's current retirement and migration guidance.
Study Drill For AZ-305
Before reading answer choices, write one phrase next to the prompt:
- "app reads data repeatedly" means Redis-style cache;
- "shared cart/session state" means Redis-style cache;
- "static files near global users" means Front Door/CDN cache;
- "authenticated or private response" means do not edge-cache it;
- "origin selection, failover, or L7 routing" means this is probably the existing routing decision, not a cache decision.
When you are ready to test the boundary, take the AZ-305 assessment. CramHQ is independent exam-preparation software, not a Microsoft product and not a pass guarantee. For this topic, the useful learning loop is to identify whether a missed question came from app-data caching, session-state placement, cache-control headers, privacy risk, or routing drift, then use targeted remediation and nearby practice instead of rereading the whole infrastructure domain.
Quick Recap
Use Redis-style caching for hot application data, cache-aside, shared session state, carts, counters, and backend read offload. Use Front Door/CDN caching for cacheable HTTP content at the edge: static assets, large files, and safe GET responses. Do not edge-cache private or authenticated user-specific responses. In current Azure architecture discussions, treat Azure Managed Redis as the forward-looking Redis service and treat Azure CDN Standard from Microsoft (classic) as a migration-path service toward Azure Front Door Standard/Premium. On AZ-305, the right answer starts with the cache's job, not with the word "performance."
