SAA-C03 Design High-Performing Architectures Practice Question

A DynamoDB table stores device status items. The partition key is deviceId, and the partition distribution is healthy (no single partition dominates). However, during peak periods the application experiences high read latency because many clients repeatedly request the latest status for the same devices. Which action best improves read latency without changing the DynamoDB partitioning model?

⚠ Common exam trap

Test-takers frequently think a GSI can magically speed up reads, but GSIs do not provide caching and still read from the same storage layer, so they do not reduce latency for repeated identical queries.

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 Amazon DAX as a caching layer in front of DynamoDB and route repeated read operations through DAX.

Amazon DAX is a fully managed, in-memory cache for DynamoDB that provides microsecond read latency. By caching the results of repeated GetItem and Query requests for the same device status items, DAX offloads read traffic from the underlying DynamoDB table, reducing the number of read capacity units consumed and eliminating the latency caused by repeated fetches from disk. This directly addresses the high read latency during peak periods without altering the existing partition key or partitioning model.

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 Amazon DAX as a caching layer in front of DynamoDB and route repeated read operations through DAX.
Why this is correct
Amazon DAX is an in-memory caching layer for DynamoDB that accelerates repeated reads. When many clients request the same items (for example, “latest status” point reads by deviceId), DAX can serve cached responses directly, reducing round trips to DynamoDB and lowering read latency during peak periods.
✗
Change the partition key to a random value for each request to eliminate hot partitions.
Why it's wrong here
The scenario states partition distribution is already healthy, so randomizing the partition key does not target the actual problem (repeat reads of the same items). It also breaks the access pattern because the application can no longer reliably request items by deviceId, and it can reduce usability and query correctness.
✗
Increase write capacity only, because writes generally determine read latency in DynamoDB.
Why it's wrong here
Write capacity does not directly address read latency for repeatedly accessed items. Read latency is primarily influenced by read capacity, item size, network latency, and whether reads are being accelerated via caching (such as DAX). Increasing writes may increase overall workload contention without fixing the repeated-read issue.
When this WOULD be correct
This option would be correct if the question described high write latency or write throttling during peak periods, and the solution required increasing write capacity to handle the write load without changing the partitioning model.
✗
Create an additional Global Secondary Index (GSI) and read exclusively from the index to accelerate reads.
Why it's wrong here
A GSI can support alternate query patterns or access paths, but it does not provide caching for repeated point reads. Creating a GSI changes how items are accessed and billed; it is not as direct as using DAX to reduce latency for repeated reads of the same keys.
When this WOULD be correct
A DynamoDB table has a suboptimal partition key leading to hot partitions, and you need to improve read performance by distributing reads across partitions. Creating a GSI with a different partition key can spread the read load and reduce latency.

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 Amazon DAX as a caching layer in front of DynamoDB and route repeated read operations through DAX.Correct answer▾

Why this is correct

Amazon DAX is an in-memory caching layer for DynamoDB that accelerates repeated reads. When many clients request the same items (for example, “latest status” point reads by deviceId), DAX can serve cached responses directly, reducing round trips to DynamoDB and lowering read latency during peak periods.

✗Increase write capacity only, because writes generally determine read latency in DynamoDB.Wrong answer — click to see why▾

Why this is wrong here

Increasing write capacity does not reduce read latency; read latency is affected by read capacity and throttling, not write capacity. The problem is high read demand on the same items, which write capacity cannot address.

★ When this WOULD be the correct answer

This option would be correct if the question described high write latency or write throttling during peak periods, and the solution required increasing write capacity to handle the write load without changing the partitioning model.

Why candidates choose this

Candidates may mistakenly think that writes and reads are coupled in DynamoDB, or that increasing any capacity will improve overall performance, not realizing that read and write capacities are independent.

✗Create an additional Global Secondary Index (GSI) and read exclusively from the index to accelerate reads.Wrong answer — click to see why▾

Why this is wrong here

Creating a GSI does not reduce read latency for repeated requests to the same items; it only provides an alternate query pattern. The hot partition issue is caused by high read frequency on specific items, which a GSI does not alleviate.

★ When this WOULD be the correct answer

A DynamoDB table has a suboptimal partition key leading to hot partitions, and you need to improve read performance by distributing reads across partitions. Creating a GSI with a different partition key can spread the read load and reduce latency.

Why candidates choose this

Candidates may think that indexes always speed up reads, not realizing that GSIs don't cache data or reduce the load on the base table's partitions for repeated identical queries.

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

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question