DOP-C02 Resilient Cloud Solutions 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.

• ✗

  Use Amazon SQS to buffer the requests and have Lambda pull from the queue with a reserved concurrency limit.

  Why it's wrong here

  While Amazon SQS buffers incoming requests and can smooth out traffic spikes, it does not increase DynamoDB's provisioned write capacity or affect how much the table can absorb. The Lambda consumer will still encounter ProvisionedThroughputExceededException when the table's write capacity is exhausted, and a reserved concurrency limit merely caps the number of concurrent consumers. Without a dead-letter queue, messages that failed due to throttling could be permanently lost after the SQS visibility timeout expires.

• ✗

  Increase the DynamoDB provisioned read and write capacity units to a high fixed value.

  Why it's wrong here

  Raising provisioned read and write capacity to a high fixed value forces you to pay for capacity that may remain idle during quiet periods, which is inefficient and expensive for variable workloads. It also sets a static ceiling: if a genuine spike exceeds that arbitrary value, DynamoDB will still throttle requests, and you cannot dynamically scale down when traffic drops. Auto scaling or on-demand capacity is far more cost-effective and responsive than manual, fixed provisioning.

• ✗

  Provision DynamoDB Accelerator (DAX) to cache reads and reduce throttling.

  Why it's wrong here

  DynamoDB Accelerator (DAX) is an in-memory cache that only offloads read requests, so it has no effect on the write-path throttling that occurs when your table's write capacity is consumed. Even if the workload were read-heavy, DAX would not prevent write throttle events; writes always pass directly to the underlying table and are subject to its capacity. For write-heavy applications, focus on capacity management and retry logic rather than adding a read cache.

• ✓

  Configure DynamoDB auto scaling and implement a dead-letter queue in Lambda to retry failed events.

  Why this is correct

  DynamoDB auto scaling adjusts provisioned capacity based on actual usage, preventing most throttling, but it cannot anticipate sudden one-off spikes because it relies on trends. A Lambda dead-letter queue, combined with the function's built-in retries and exponential backoff, ensures that any event which still fails due to a throttle is safely captured for manual or automated replay rather than silently dropped. This two-tier approach balances elasticity with data durability, which is why it is the recommended solution for unpredictable write spikes.

Go deeper

Related to this question