DVA-C02 Troubleshooting and Optimization 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.

• ✗

  Contact AWS Support to increase the DynamoDB service limits.

  Why it's wrong here

  DynamoDB service limits typically refer to account-level maximums, such as the total number of tables or the aggregate provisioned throughput across all tables in a region. Exceeding provisioned throughput on a *specific* table indicates that the table's configured RCU/WCU are insufficient for the current workload, not that an account-wide service limit has been hit. Therefore, increasing service limits would not automatically adjust the individual table's capacity or prevent throttling due to insufficient *provisioned* capacity for that particular table.

• ✗

  Reduce the read and write capacity units.

  Why it's wrong here

  Reducing the provisioned read and write capacity units (RCU/WCU) for a DynamoDB table would directly exacerbate the problem of throttling. Throttling occurs precisely because the application's request rate already exceeds the currently provisioned capacity. Decreasing this capacity further would only make the table *more* susceptible to throttling, leading to an even higher frequency of `ProvisionedThroughputExceededException` errors and degraded application performance.

• ✓

  Implement exponential backoff and retry in the application code.

  Why this is correct

  Implementing exponential backoff and retry logic in the application code is a standard best practice for gracefully handling transient errors like `ProvisionedThroughputExceededException` in DynamoDB. This mechanism automatically retries failed requests after progressively longer delays, allowing the throttled table time to recover or for its burst capacity to replenish. It prevents a flood of immediate retries from overwhelming the table further, enabling the application to adapt to temporary capacity limitations.

• ✗

  Switch the table to on-demand capacity mode.

  Why it's wrong here

  Switching the table to on-demand capacity mode would indeed prevent `ProvisionedThroughputExceededException` errors by automatically scaling capacity to meet demand. However, the question specifically describes a scenario where the developer *is using* provisioned throughput and needs to handle the existing throttling error. Changing the capacity mode is a configuration change to *avoid* the error type in the future, not a runtime strategy to *handle* the error when it occurs within the provisioned mode context.