DVA-C02 Development with AWS Services Practice Question

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 point-in-time recovery

  Why it's wrong here

  Enabling point-in-time recovery (PITR) provides continuous backups of a DynamoDB table, allowing restoration to any second within the last 35 days. While crucial for data durability and disaster recovery, this feature does not address performance issues stemming from a hot partition caused by a single customer generating excessive traffic. PITR is unrelated to distributing read/write workload across multiple partitions to prevent throttling.

• ✗

  Reduce item size by removing attributes

  Why it's wrong here

  Reducing item size by removing unnecessary attributes can decrease the consumed read and write capacity units (RCUs/WCUs) per operation. While this might slightly increase the total number of operations a table can handle within its overall provisioned throughput, it does not fundamentally resolve a hot partition issue. A single partition key value still has a hard limit on its throughput, and reducing item size won't distribute the concentrated workload from one "hot" customer across multiple partitions.

• ✗

  Use strongly consistent reads only

  Why it's wrong here

  Using strongly consistent reads only would consume twice the read capacity units (RCUs) compared to eventually consistent reads for the same data. This approach would actually worsen a hot partition problem, as it would cause the single overloaded partition to hit its throughput limits even faster. The consistency model choice does not help in distributing a concentrated workload from a single customer across multiple physical partitions to prevent throttling.

• ✓

  Add write sharding or redesign the partition key to distribute that customer's workload

  Why this is correct

  A hot partition occurs when a single partition key value receives disproportionately high read or write traffic, leading to throttling. To mitigate this, one can implement write sharding by appending a random or calculated suffix to the `customerid` (e.g., `customerid-001`, `customerid-002`), effectively distributing that single customer's operations across multiple logical partitions. Alternatively, redesigning the partition key entirely to include a more granular attribute alongside `customerid` can achieve similar workload distribution.

Go deeper

Related to this question