A developer has built an application that inserts data into an Amazon DynamoDB table. The table is configured to use provisioned capacity. The application is deployed on a burstable nano Amazon EC2…

Question

Options

• AMove the application to a larger EC2 instance.
• BIncrease the number of read capacity units (RCUs) that are provisioned for the DynamoDB table.
• CReduce the frequency of requests to DynamoDB by implementing exponential backoff.
• DIncrease the frequency of requests to DynamoDB by decreasing the retry delay.
• EChange the capacity mode of the DynamoDB table from provisioned to on-demand.

• A
  13% (5)
• B
  8% (3)
• C
  75% (30)
• D
  5% (2)

Explanation

ProvisionedThroughputExceededException means the application is sending write requests faster than the DynamoDB table's provisioned capacity allows - C (exponential backoff) and E (on-demand mode) both directly address this bottleneck. Exponential backoff reduces the request rate when throttling occurs, allowing DynamoDB to catch up, while switching to on-demand mode removes the fixed capacity ceiling entirely and lets DynamoDB auto-scale to any traffic volume.

Why the distractors are wrong:

• A is wrong because EC2 instance size has no bearing on DynamoDB throughput - the instance is just making API calls, and throttling happens on the DynamoDB side.
• B is wrong because the application is inserting data (writes), so increasing Read Capacity Units does nothing for a write-throttling error; you'd need to increase Write Capacity Units.
• D is the opposite of helpful - decreasing retry delay increases request frequency, which would amplify the throttling.

Memory tip: When you see ProvisionedThroughputExceededException, think "too fast, too fixed" - the fix is either slow down (backoff) or remove the ceiling (on-demand). Any answer that speeds things up (D) or targets the wrong resource type (B: RCUs for a write problem) is a trap.

No community discussion yet for this question.