SAP-C02 Design for New Solutions Practice Question

A startup is building a serverless application using AWS Lambda for business logic and Amazon DynamoDB for data storage. The application must process a high volume of writes to a single DynamoDB table. The development team is concerned about throttling due to hot partitions. Which design should the team implement to avoid throttling?

⚠ Common exam trap

Watch out — candidates often confuse caching (DAX) as a solution for write performance, not realizing DAX only accelerates reads, or they mistakenly believe that secondary indexes (GSI/LSI) can redistribute write load, when in fact they share the base table's partition key and do not solve hot partition issues.

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 a composite primary key with a partition key that has high cardinality, such as a user ID.

Using a partition key with high cardinality, such as a user ID, ensures that write requests are evenly distributed across all partitions in the DynamoDB table. This prevents any single partition from becoming a hot partition, which would otherwise lead to throttling when the partition's throughput capacity is exceeded. DynamoDB scales by splitting partitions based on the partition key's hash, so high cardinality is essential for avoiding throttling under high write volumes.

Answer analysis

Option-by-option breakdown

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

✗
Enable DynamoDB Accelerator (DAX) to cache write operations.
Why it's wrong here
DAX caches read operations; writes still travel to the table and consume partition throughput, so hot-partition throttling persists. DAX is the correct choice when read latency on eventually consistent GetItem or Query calls is the bottleneck, not write volume.
✓
Use a composite primary key with a partition key that has high cardinality, such as a user ID.
Why this is correct
A high-cardinality partition key such as user ID spreads writes across many physical partitions, preventing any single partition from becoming a hot spot. This directly addresses the throttling constraint caused by uneven write distribution in the single DynamoDB table.
✗
Use a global secondary index (GSI) as the primary index for writes.
Why it's wrong here
A GSI is a separate index with its own partition key; writes still target the base table's partition key, so hot partitions persist and index writes add load. Write sharding spreads keys across partitions. A GSI is right for querying on an alternate attribute, not for relieving write throttling.
✗
Add a local secondary index (LSI) to the table.
Why it's wrong here
An LSI shares the base table's partition key, so writes to a hot partition remain concentrated on the same physical partition. LSIs suit querying alternate sort keys within one partition key, not distributing write load across partitions.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAP-C02 Design for New Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question