DEA-C01 Data Store Management Practice Question

A data engineer maintains an Amazon DynamoDB table that stores IoT telemetry. The table uses a partition key of deviceId and a sort key of timestamp, with on-demand capacity. A few very active devices generate millions of writes per hour while thousands of other devices write sporadically. The engineer observes throttling on writes for the active devices and wants to reduce it with the least application change. Which action should the engineer take?

⚠ Common exam trap

The trap here is thinking that switching to provisioned capacity or raising WCUs fixes throttling, when the real constraint is the per-partition write limit on a single hot partition key.

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 a random suffix to the partition key to spread writes across partitions

Throttling from a few high-volume partition keys is a hot-partition problem, not a capacity problem. DynamoDB partitions have a fixed write ceiling regardless of table-level capacity mode. Write sharding by adding a suffix to the partition key spreads a single device's writes across many partitions, each with independent throughput. Provisioned capacity, streams, and GSIs do not raise the per-partition write limit, so they fail to address the observed throttling.

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 Streams and process writes asynchronously
Why it's wrong here
DynamoDB Streams captures item-level changes after they are written and does not absorb or buffer incoming write traffic. Enabling streams does not increase the write capacity available to a hot partition, so throttling caused by a single high-volume partition key continues. Streams are useful for downstream processing and replication, but they are not a mechanism for mitigating partition-level write throttling in this scenario.
✗
Switch the table to provisioned capacity with a high write capacity unit setting
Why it's wrong here
Provisioned capacity with a high WCU setting raises the table-level throughput ceiling, but DynamoDB still distributes capacity across partitions. A single partition key such as one very active deviceId maps to one partition, and that partition has a hard write limit. Increasing table-level WCUs does not remove the per-partition ceiling, so the hot device would still be throttled. This does not address the root cause.
✓
Add a random suffix to the partition key to spread writes across partitions
Why this is correct
Write sharding by appending a random or calculated suffix to the partition key distributes a hot device's writes across multiple partitions, each with its own throughput budget. This directly relieves the per-partition write limit that causes throttling for high-volume devices. Queries must then fan out across the shards and aggregate results, but the change is confined to the key composition and read logic, keeping application change moderate and targeted.
✗
Create a global secondary index on timestamp and write through the index
Why it's wrong here
Global secondary indexes are read-side constructs for alternate query patterns; they do not replace the base table write path. Writes still land on the base table partitions first, so a hot partition key remains hot. Additionally, GSIs consume their own write capacity, and a poorly chosen index partition key can itself become a bottleneck. This option does not reduce throttling on the base table writes for the active devices.

Go deeper

DEA-C01 Data Store Management Practice Question

Why each option matters

Option-by-option breakdown

Related to this question