SAA-C03 Design High-Performing Architectures Practice Question
Your application uses ElastiCache Redis as a cache for user profiles stored in DynamoDB. You must ensure that when a profile is updated, subsequent reads see the latest value quickly. Which cache strategy is generally the best fit for this requirement?
⚠ Common exam trap
Many exam-takers confuse cache-aside with write-through or write-behind patterns, or assume that Redis replication alone can solve cache consistency, when in fact explicit invalidation is required to ensure reads see the latest value after a write to the primary data store.
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
✓
Use a cache-aside approach with TTL plus explicit invalidation after writes.
The cache-aside (lazy loading) pattern with TTL plus explicit invalidation ensures that after a write to DynamoDB, the stale Redis entry is removed, forcing the next read to fetch the updated profile from DynamoDB and repopulate the cache. This minimizes the window of inconsistency while keeping cache management simple and efficient for user profile workloads.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Write to DynamoDB only, and never update or invalidate the Redis cache.
Why it's wrong here
Never invalidating means stale data may persist in cache until it naturally expires. That conflicts with the requirement for quick visibility of updates. This design sacrifices correctness for simplicity.
When this WOULD be correct
If the question stated that user profiles are immutable (never updated after creation) or that the application can tolerate stale data for the entire TTL period, then writing only to DynamoDB without cache invalidation would be acceptable.
- ✓
Use a cache-aside approach with TTL plus explicit invalidation after writes.
Why this is correct
A cache-aside (lazy loading) pattern reads from cache first; if missing/expired, it fetches from the source of truth. After an update, explicitly invalidating or updating the cached entry ensures subsequent reads quickly reflect changes. TTL provides protection against missed invalidations while invalidation accelerates correctness after writes.
- ✗
Cache only for reads, and do not fetch from DynamoDB when a key is missing.
Why it's wrong here
If you do not fetch from DynamoDB on cache misses, you can return empty or incorrect responses. Cache-aside requires falling back to the source of truth. This option would break the functionality under cache misses.
When this WOULD be correct
This strategy would be correct in a scenario where the data is static or changes very rarely, and the cache is pre-populated with all necessary data. For example, a read-only reference dataset (like country codes) that is loaded once and never updated, where cache misses are acceptable only during initial load.
- ✗
Rely on eventual consistency of Redis replication to propagate updates to all nodes.
Why it's wrong here
Redis replication behavior is not a substitute for explicit cache invalidation for application-level correctness. Even if replication converges, stale cached entries may still be returned. Correctness needs a strategy tied to write events.
When this WOULD be correct
In a scenario where the requirement is to maximize read throughput and tolerate short periods of stale data, such as a read-heavy application displaying non-critical content (e.g., news headlines) where eventual consistency is acceptable.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Use a cache-aside approach with TTL plus explicit invalidation after writes.Correct answer▾
Why this is correct
A cache-aside (lazy loading) pattern reads from cache first; if missing/expired, it fetches from the source of truth. After an update, explicitly invalidating or updating the cached entry ensures subsequent reads quickly reflect changes. TTL provides protection against missed invalidations while invalidation accelerates correctness after writes.
✗Write to DynamoDB only, and never update or invalidate the Redis cache.Wrong answer — click to see why▾
Why this is wrong here
This option never updates or invalidates the cache, so after a profile update in DynamoDB, the Redis cache still serves stale data until the TTL expires, violating the requirement that subsequent reads see the latest value quickly.
★ When this WOULD be the correct answer
If the question stated that user profiles are immutable (never updated after creation) or that the application can tolerate stale data for the entire TTL period, then writing only to DynamoDB without cache invalidation would be acceptable.
Why candidates choose this
Candidates may think that a simple write-through or write-around pattern is sufficient, or they underestimate the need for explicit invalidation to ensure read-after-write consistency.
✗Cache only for reads, and do not fetch from DynamoDB when a key is missing.Wrong answer — click to see why▾
Why this is wrong here
This option fails because if a key is missing in the cache, the application never fetches the profile from DynamoDB, so stale or missing data persists indefinitely, violating the requirement that subsequent reads see the latest value quickly.
★ When this WOULD be the correct answer
This strategy would be correct in a scenario where the data is static or changes very rarely, and the cache is pre-populated with all necessary data. For example, a read-only reference dataset (like country codes) that is loaded once and never updated, where cache misses are acceptable only during initial load.
Why candidates choose this
Candidates may think that caching only for reads simplifies the architecture and avoids write-through complexity, but they overlook the need to handle cache misses by fetching from the primary data store to ensure data freshness.
✗Rely on eventual consistency of Redis replication to propagate updates to all nodes.Wrong answer — click to see why▾
Why this is wrong here
Redis replication is asynchronous, so relying on eventual consistency does not guarantee that subsequent reads see the latest value quickly after a write. This strategy can lead to stale reads until replication completes.
★ When this WOULD be the correct answer
In a scenario where the requirement is to maximize read throughput and tolerate short periods of stale data, such as a read-heavy application displaying non-critical content (e.g., news headlines) where eventual consistency is acceptable.
Why candidates choose this
Candidates may assume that Redis replication provides strong consistency or that eventual consistency is sufficient for cache updates, overlooking the need for immediate consistency after profile updates.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
One of 302 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services 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 SAA-C03 exam.