AZ-204 Practice Question: Connect to and consume Azure services and third-party services
You are using Azure Cache for Redis to cache frequently accessed database query results. You need to ensure that the cache is updated automatically when the underlying data changes. Which pattern should you implement?
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
✓
Cache-aside pattern with cache invalidation
The cache-aside (lazy loading) pattern is the most common approach for caching database queries. In this pattern, the application checks the cache first; on a cache miss, it loads data from the database and stores it in the cache with a TTL. To ensure the cache reflects data changes, the application invalidates (deletes) the cached entry whenever the underlying data is updated, so the next read fetches fresh data. This pattern is explicitly designed for scenarios like Azure Cache for Redis where automatic updates are needed. Option B (read-through) is similar but the cache itself loads data from the database; however, it does not handle cache invalidation on data changes automatically. Option C (event-driven invalidation using Azure Event Grid) is a valid pattern but is more complex and not the standard caching pattern; it requires additional infrastructure to detect changes and publish events. Option D (write-through) updates the cache synchronously on writes, but it does not address automatic updates when data changes outside the cache (e.g., direct database updates). Therefore, the cache-aside pattern with explicit invalidation is the correct choice for automatic cache updates.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Cache-aside pattern with cache invalidation
Why this is correct
The Cache-aside pattern places the responsibility of managing the cache directly with the application. When the application needs data, it first checks the cache; if a miss occurs, it retrieves data from the data store, populates the cache, and returns it. Crucially, when the application modifies data in the underlying data store, it explicitly invalidates or updates the corresponding entry in the cache to ensure data consistency and freshness.
- ✗
Read-through pattern
Why it's wrong here
In a Read-through pattern, the application delegates the responsibility of loading data from the underlying data store to the cache itself. When the application requests data, the cache transparently fetches it from the configured data source if not present, populates its own entry, and then returns it. While this simplifies application code by abstracting data loading, it still necessitates a separate mechanism for cache invalidation when the source data changes externally, as the cache doesn't inherently detect these modifications.
- ✗
Event-driven cache invalidation using Azure Event Grid
Why it's wrong here
While technically feasible, implementing event-driven cache invalidation using Azure Event Grid introduces significant architectural overhead and complexity. It would require publishing events from the data store upon data changes, subscribing to these events with a dedicated handler, and then programmatically invalidating specific cache entries. This approach adds latency, additional components, and potential points of failure, making it less straightforward than direct invalidation methods for typical caching scenarios.
- ✗
Write-through pattern
Why it's wrong here
The Write-through pattern ensures that any data written by the application is simultaneously written to both the cache and the underlying data store. This guarantees that the cache always contains the most recent version of data *written through the application's path*. However, this pattern does not address scenarios where the underlying data store is modified by other applications or processes *outside* the cache's write operations. In such cases, the cache would become stale, as it lacks an inherent mechanism to detect or react to these external data changes.
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Azure Cache for Redis
Azure Cache for Redis is a fully managed in-memory data store based on the open-source Redis software that speeds up applications by temporarily storing frequently accessed data.
Key term
Azure Event Grid
Azure Event Grid is a fully managed event routing service that allows applications and services to react to events in real time using a publish-subscribe model.
About these practice questions
Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.