How to Reduce DynamoDB Read Latency Using DAX
Exhibit
DynamoDB metrics and access pattern: - Table mode: on-demand - ConsumedReadCapacityUnits: steady, no throttling overall - SuccessfulRequestLatency: p95 = 34 ms - Hot partition key detected: tenant#42 consumes 92% of read traffic during peak Application notes: - Requests repeatedly fetch the same dashboard items for up to 60 seconds - Reads are eventually consistent and the application can tolerate brief cache staleness - Writes are infrequent and do not dominate the workload
Based on the exhibit, which design change is the best way to reduce the observed read latency for this DynamoDB-backed service?
Quick Answer
The answer is to add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it. This is the best way to reduce DynamoDB read latency because DAX acts as an in-memory cache that delivers microsecond response times for eventually consistent reads, eliminating the need to repeatedly query the underlying table for hot data. On the SAA-C03 exam, this scenario tests your understanding of caching layers versus table redesigns or application-level caching—a common trap is choosing to add more read capacity units, which only increases throughput, not speed. Remember that DAX is specifically designed for read-heavy workloads where low latency is critical, not for write optimization. Memory tip: DAX = Data Accelerator for eXtra speed, think “DAX slashes latency to the max.”
⚠ Common exam trap
Test-takers frequently assume increasing capacity limits (Option B) or adding indexes (Option C) will solve latency issues, but they fail to recognize that latency is a caching problem, not a throughput or partitioning problem, and that DAX is the AWS-native solution for DynamoDB read-heavy workloads with repeated access patterns.
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
✓
Add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it.
Adding a DynamoDB Accelerator (DAX) cluster in front of the table reduces read latency by providing an in-memory cache for repeated read traffic. DAX delivers microsecond response times for eventually consistent reads, which directly addresses the observed latency issue without requiring application-level caching or table redesign.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it.
Why this is correct
DAX is designed to accelerate repeated eventually consistent reads from DynamoDB by caching hot items in memory. The exhibit shows one tenant driving most of the reads and the same dashboard items being requested repeatedly within a short window, which is an excellent fit for DAX. It reduces latency and offloads the hot key without requiring a schema redesign.
- ✗
Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.
Why it's wrong here
On-demand capacity already scales automatically with traffic, so raising table limits does nothing to reduce read latency caused by hot partitions or inefficient access patterns. It is tempting because on-demand mode removes throughput planning, which suits unpredictable spiky workloads rather than fixing partition-level contention.
When this WOULD be correct
This option would be correct if the question described a scenario where the application is experiencing ProvisionedThroughputExceededException errors due to insufficient read capacity, and the workload is unpredictable, making on-demand capacity the appropriate solution.
- ✗
Create a global secondary index on tenantId to distribute the load across more partitions.
Why it's wrong here
A global secondary index on tenantId still routes each tenant's items to partitions by that key, so a single hot tenant continues to concentrate load rather than spreading it. It is tempting because GSIs enable alternate query patterns, which suits querying by non-key attributes rather than relieving partition-level read contention.
When this WOULD be correct
If the question described a scenario where read traffic is evenly distributed across many distinct tenantId values and the goal is to improve query performance by avoiding full table scans, then adding a GSI on tenantId would be correct.
- ✗
Move the dashboard data into S3 and use Lambda functions to read it on demand.
Why it's wrong here
Moving dashboard data to S3 and reading it via Lambda adds cold-start and request latency, and S3 is not a low-latency key-value store for per-item reads. It is tempting because S3 plus Lambda suits infrequent analytical queries over large datasets, not the sub-millisecond item reads a DynamoDB-backed service requires.
When this WOULD be correct
This option would be correct if the question involved large, infrequently accessed dashboard data (e.g., historical reports) where cost savings from S3's lower storage cost outweigh latency concerns, and the Lambda function can be optimized with provisioned concurrency to minimize cold starts.
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.
✓Add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it.Correct answer▾
Why this is correct
DAX is designed to accelerate repeated eventually consistent reads from DynamoDB by caching hot items in memory. The exhibit shows one tenant driving most of the reads and the same dashboard items being requested repeatedly within a short window, which is an excellent fit for DAX. It reduces latency and offloads the hot key without requiring a schema redesign.
✗Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.Wrong answer — click to see why▾
Why this is wrong here
Increasing on-demand table limits does not reduce read latency; it only prevents throttling. The observed latency is likely due to repeated reads of the same hot data, which DAX caching addresses directly.
★ When this WOULD be the correct answer
This option would be correct if the question described a scenario where the application is experiencing ProvisionedThroughputExceededException errors due to insufficient read capacity, and the workload is unpredictable, making on-demand capacity the appropriate solution.
Why candidates choose this
Candidates may assume that increasing capacity limits will improve performance, confusing throughput with latency, or they may not understand that DynamoDB's on-demand scaling handles capacity but not caching or hot-key issues.
✗Create a global secondary index on tenantId to distribute the load across more partitions.Wrong answer — click to see why▾
Why this is wrong here
A GSI on tenantId does not reduce read latency for repeated reads of the same data; it only helps with query flexibility. The observed latency is likely due to hot partitions or throttling, which DAX's caching directly addresses.
★ When this WOULD be the correct answer
If the question described a scenario where read traffic is evenly distributed across many distinct tenantId values and the goal is to improve query performance by avoiding full table scans, then adding a GSI on tenantId would be correct.
Why candidates choose this
Candidates may think that distributing load across partitions via a GSI will reduce latency, but they overlook that GSIs don't cache data and that the bottleneck is likely from repeated reads of the same items, not partition distribution.
✗Move the dashboard data into S3 and use Lambda functions to read it on demand.Wrong answer — click to see why▾
Why this is wrong here
Moving dashboard data to S3 and using Lambda to read it on demand would likely increase read latency due to cold starts and S3's higher latency for small, frequent reads compared to DAX. It also adds complexity and cost without addressing the root cause of high read latency on DynamoDB.
★ When this WOULD be the correct answer
This option would be correct if the question involved large, infrequently accessed dashboard data (e.g., historical reports) where cost savings from S3's lower storage cost outweigh latency concerns, and the Lambda function can be optimized with provisioned concurrency to minimize cold starts.
Why candidates choose this
Candidates may think S3 is always faster or cheaper for any data, or they might overestimate Lambda's ability to reduce latency without considering cold starts and network overhead.
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 935 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 →
Same concept, more angles
1 more way this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Based on the exhibit, which design change is the best way to reduce the observed read latency for this DynamoDB-backed service?
hard- ✓ A.Add a DynamoDB Accelerator (DAX) cluster in front of the table and send repeated read traffic through it.
- B.Increase the on-demand table limits so DynamoDB can automatically absorb more traffic.
- C.Create a global secondary index on tenantId to distribute the load across more partitions.
- D.Move the dashboard data into S3 and use Lambda functions to read it on demand.
Why A: Adding a DynamoDB Accelerator (DAX) cluster in front of the table reduces read latency by providing an in-memory cache that serves repeated read requests with microsecond response times, bypassing the need to read from the underlying DynamoDB table's SSD storage. This directly addresses the observed latency issue for frequently accessed data, as DAX is optimized for read-heavy workloads and supports eventual and strong consistency reads.
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.