SAA-C03 Design High-Performing Architectures Practice Question

A service performs many repeated read requests for the same DynamoDB items. The reads are latency-sensitive, but the application can tolerate slightly stale data. Which AWS service is the best fit to reduce read latency?

⚠ Common exam trap

A common mix-up: candidates confuse caching services (DAX) with data retrieval services (S3 Select) or assume that a queue (SQS) or compute optimization (Lambda provisioned concurrency) can solve read latency issues, when only a purpose-built in-memory cache like DAX directly addresses repeated DynamoDB reads with stale data tolerance.

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

✓

Amazon DAX (DynamoDB Accelerator)

Amazon DAX (DynamoDB Accelerator) is an in-memory cache specifically designed for DynamoDB. It reduces read latency from single-digit milliseconds to microseconds by caching frequently accessed items, and it supports eventually consistent reads, which aligns with the application's tolerance for slightly stale data. DAX handles repeated read requests without additional DynamoDB read capacity unit consumption, making it the optimal choice for this latency-sensitive workload.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Amazon DAX (DynamoDB Accelerator)
Why this is correct
Amazon DAX is an in-memory cache for DynamoDB. It reduces latency for repeated reads by caching results and serving subsequent read requests from the DAX cluster rather than repeatedly calling DynamoDB. Because it provides cached reads that may be slightly stale, it matches the scenario’s tolerance.
✗
Amazon S3 Select
Why it's wrong here
Amazon S3 Select is a service for running SQL-like queries directly on objects stored in S3, returning only a filtered subset of the data to reduce data transfer and processing cost. It does not provide any in-memory caching or low-latency read acceleration for DynamoDB items, and it cannot act as a front-end layer to intercept database access. Instead, it optimizes access to objects within S3 itself, which is fundamentally different from serving a high volume of repeated DynamoDB reads.
✗
Amazon SQS FIFO queue
Why it's wrong here
Amazon SQS FIFO queues provide ordered, exactly-once message delivery for decoupled application components, ensuring strict ordering and preventing duplicate processing. They are a messaging system, not a low-latency cache or a data store, so they have no mechanism to serve or cache DynamoDB item reads. A FIFO queue would add significant latency and complexity if used for database read acceleration, and it cannot reduce the number of DynamoDB read operations.
✗
AWS Lambda provisioned concurrency
Why it's wrong here
AWS Lambda provisioned concurrency keeps a specified number of function execution environments pre-initialized, eliminating cold starts and thereby reducing invocation latency. While this improves the performance of the calling code, it does not affect the latency of DynamoDB calls between Lambda and DynamoDB, nor does it cache any data fetched from DynamoDB. Each individual Lambda invocation still performs its own Read operation against DynamoDB, so provisioned concurrency does nothing to accelerate repeated identical reads.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question