A mobile app reads the same product catalog items repeatedly throughout the day. The DynamoDB table is already properly keyed, but read latency is still a problem during sales events. The team can tolerate eventually consistent reads and wants the least disruptive change. What should they add?

Add a global secondary index for every frequently viewed product attribute.

A GSI helps with alternative query patterns, but it does not function as an in-memory cache for repeated reads of the same items. Creating more indexes also increases write cost and design complexity. The workload already has a good key design, so the real problem is read latency on hot items, not the absence of a query path.

Switch the table to on-demand capacity mode to reduce latency.

On-demand capacity simplifies scaling, but it does not provide caching or directly reduce per-request latency for repeated reads. It helps absorb traffic variability, yet the underlying read path still goes to DynamoDB. In this scenario, the issue is fast access to hot items, so capacity mode alone is not enough.

Move the catalog to Aurora and use a read replica for every region.

Migrating to Aurora would introduce a different database model and does not address the immediate problem in the simplest way. Read replicas can help with relational read scaling, but they are not a drop-in optimization for this DynamoDB workload. The question specifically asks for the least disruptive change, and DAX preserves the current architecture.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Enable DynamoDB Accelerator to cache frequently accessed items in memory. — DAX is the most appropriate addition because the application repeatedly reads the same items and can accept eventual consistency. It acts as an in-memory cache in front of DynamoDB, which lowers latency and reduces pressure on the table during sales events. Since the key design is already correct, adding DAX improves performance without changing the schema or rewriting access patterns. That makes it a low-disruption, high-impact optimization. Why others are wrong: A GSI helps with alternate query access, but it is not a cache and can add write overhead. On-demand mode helps with scaling elasticity, not repeated-read latency. Moving to Aurora changes the data platform entirely and is not the least disruptive answer to a DynamoDB hot-read problem. The scenario points to cache acceleration, which is what DAX provides.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.