SAP-C02 Design for New Solutions Practice Question

A company is designing a new application that will use Amazon DynamoDB as its primary data store. The application requires consistent low-latency read and write performance at any scale, and the company wants to minimize operational effort. The data model includes a table with a partition key and a sort key. The workload is expected to have highly uneven access patterns, with some items being accessed much more frequently than others. Which design approach should a solutions architect recommend to meet these requirements?

⚠ Common exam trap

The trap here is assuming that DAX can solve all performance issues, but DAX only accelerates reads and does not help with write scalability or hot partitions.

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

✓

Use DynamoDB on-demand capacity mode and design the partition key to distribute traffic evenly across partitions.

On-demand capacity mode removes the burden of capacity planning and automatically scales with workload, minimizing operational effort. A well-distributed partition key is essential to avoid hot partitions and ensure consistent performance, especially when access patterns are uneven. Together, they provide low-latency reads and writes at any scale without manual intervention.

Answer analysis

Option-by-option breakdown

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

✓
Use DynamoDB on-demand capacity mode and design the partition key to distribute traffic evenly across partitions.
Why this is correct
On-demand capacity mode automatically scales to handle workload changes, eliminating capacity planning and minimizing operational effort. Designing a partition key that distributes traffic evenly prevents hot partitions, ensuring consistent low-latency performance even with uneven access patterns. This combination meets the requirements for scalability and low operational overhead.
✗
Use DynamoDB provisioned capacity mode with auto scaling and choose a partition key that includes a timestamp to ensure even distribution.
Why it's wrong here
Provisioned capacity with auto scaling still requires some capacity planning and can react slowly to sudden spikes, potentially causing throttling. Including a timestamp in the partition key may not evenly distribute traffic if access patterns are skewed, and it can complicate queries. This approach increases operational effort and does not guarantee consistent performance for uneven access patterns.
✗
Use DynamoDB Accelerator (DAX) in front of the table to cache frequently accessed items and absorb read traffic.
Why it's wrong here
DAX improves read performance for eventually consistent reads but does not address write scalability or uneven access patterns. It adds operational overhead and cost, and does not eliminate the need for a well-distributed partition key. While it can help with hot reads, it does not meet the requirement to minimize operational effort for writes and overall scaling.
✗
Use a global secondary index (GSI) with a different partition key to spread the load and enable queries on alternate attributes.
Why it's wrong here
A GSI can provide alternate query patterns but does not solve hot partition issues on the base table. It also introduces additional write costs and potential throttling if the GSI's partition key is not well-distributed. This approach adds complexity and does not directly address the need for consistent low-latency performance under uneven access patterns.

Go deeper

SAP-C02 Design for New Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question