AZ-305 state-management questions are usually architecture tradeoff questions, not vocabulary checks. The scenario gives you a piece of state, then tests whether you can decide where that state belongs when the app scales across instances, regions, and failure paths.
Use this exam model: keep authoritative business state in a durable system of record, and use a cache only to accelerate access to data the workload can reload, expire, or tolerate as stale. Externalize session or workflow state when any healthy app instance must be able to serve the same user. Use Cosmos DB-style durable distributed state when partitioning, consistency, transaction scope, global distribution, or conflict behavior is the real constraint.
Start With The State's Job
Ask whether the state is authoritative. Critical order data, audit-relevant updates, account changes, and workflow decisions that cannot be lost belong in a durable store. A cache can make those reads faster, but it should not become the only place the business truth exists.
If the state is derived, read-heavy, expensive to recompute, relatively static, or latency-sensitive, a cache becomes a strong answer. For current Azure Redis wording, frame new shared-cache scenarios around Azure Managed Redis. Treat unqualified Azure Cache for Redis wording as legacy or migration-sensitive unless the question is explicitly about an existing deployment.
Scale Changes The Cache Answer
Per-instance memory is simple and fast, but each instance can hold a different view. That may be fine for static reference data or data that can safely vary by instance. It is risky when horizontally scaled instances need the same state.
A shared Redis-style cache gives multiple instances a common cached view, which fits session lookup, expensive reference data, and read-heavy application data. The tradeoff is that the cache is now a dependency: the design must include cache misses, expiration or invalidation, and fallback behavior.
Cache-aside is the common AZ-305 pattern. The app checks the cache first, loads from the durable store on a miss, and updates the durable store before invalidating or refreshing the cached value. The key exam trap is assuming cache-aside automatically keeps data fresh. It does not; the architecture has to define freshness and invalidation.
Worked Scenario
A retail site runs on several application instances. Product catalog reads are heavy, catalog changes are occasional, and users expect low latency. The catalog still has to remain correct after updates.
For AZ-305, this points to cache-aside with a shared Redis-style cache such as Azure Managed Redis. The app reads from cache first. On a miss, it loads the product record from the durable store and populates the cache. When the catalog changes, the app updates the durable store first and then invalidates or refreshes the cached entry. The cache improves latency, but the durable store remains the source of truth.
Now add shopping cart or checkout workflow state. If any app instance can receive the next request, do not depend on per-instance memory or sticky sessions as the main design. Externalize the state so another instance can continue the workflow. If the state is critical order state, persist it durably and use cache only as an acceleration layer.
Finally, suppose the app stores user-owned order documents for a global audience, and related updates must be atomic when they belong to the same logical group. This is no longer just a cache question. Cosmos DB-style durable distributed state may be appropriate, but the exam answer should name the real design constraints: partition key choice affects performance and transaction scope, consistency level changes stale-read and latency behavior, and multi-region writes require a conflict posture.
Compact Exam Rules
| Scenario signal | Better exam move |
|---|---|
| Read-heavy, repeated, latency-sensitive data that can be reloaded | Use cache-aside with explicit expiration or invalidation. |
| Critical, audit-relevant, or non-loss-tolerant state | Store it durably; use cache only to accelerate reads. |
| Multiple app instances must see the same state | Prefer shared external state over isolated per-instance memory. |
| The proposed answer depends on sticky sessions | Treat it as a warning sign unless affinity is explicitly acceptable. |
| Atomic updates must stay within related Cosmos DB items | Check whether the items share the same logical partition key. |
| Global reads and writes drive the design | Choose consistency and write-region behavior based on stale-read tolerance, latency, availability, and conflict handling. |
One major trap: resiliency features on a cache do not turn cache-only data into a durable system of record. If losing the cache would lose the business truth, the design is wrong for this exam objective.
Quick Recap
If the interactive components do not load, remember the decision model: classify the state first. Durable business truth goes to a system of record. Cacheable, reloadable, or derived data can use cache-aside with planned expiration, invalidation, miss handling, and outage behavior. Horizontally scaled apps should externalize shared session or workflow state instead of depending on one app instance. Cosmos DB enters the answer when durable distributed state is shaped by partition keys, transaction scope, consistency, global distribution, and conflict behavior.
Ready to test this under exam pressure? Take the targeted AZ-305 assessment and look for state-management scenarios where one word, such as "critical," "shared," "global," "stale," or "same partition," changes the correct architecture.