DOP-C02 Incident and Event Response Practice Question

An e-commerce platform uses Amazon DynamoDB as its primary database. During a flash sale, the application experiences throttling errors. The operations team needs to implement a solution to handle sudden traffic spikes while keeping costs under control. Which TWO actions should the team take? (Choose two.)

⚠ Common exam trap

Watch out — candidates often confuse DynamoDB Streams with read replicas, or assume that provisioned capacity with auto scaling is always cost-effective for spikes, when in fact on-demand capacity is designed for unpredictable traffic and avoids the cold-start throttling risk of auto scaling.

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

✓

Implement DynamoDB Accelerator (DAX) to cache read-intensive data.

DynamoDB Accelerator (DAX) is an in-memory cache that reduces read latency from milliseconds to microseconds, offloading read requests from the main DynamoDB table. During a flash sale, caching read-intensive data (e.g., product details) with DAX reduces the number of read capacity units consumed, helping to avoid throttling while keeping costs under control by not requiring a permanent increase in provisioned capacity.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Increase the read and write capacity units manually before the sale.
Why it's wrong here
Increasing read and write capacity units manually before the sale is reactive admin overhead: you must predict peak traffic, and DynamoDB capacity changes take time to propagate. If the sale traffic exceeds the manually set values, you still get throttled until another manual change completes, and if you set capacity too high you waste money after the surge ends. For a flash sale, use on-demand capacity or auto scaling with conservative targets instead of a one-time manual adjustment.
✗
Switch from on-demand to provisioned capacity with auto scaling.
Why it's wrong here
Switching from on-demand to provisioned capacity with auto scaling is counterproductive for a sale with unpredictable spikes. Auto scaling adjusts capacity only after CloudWatch utilization metrics are observed, so a sudden burst can exhaust the table's burst capacity and return ProvisionedThroughputExceededException before the scaling action takes effect. On-demand mode is designed to absorb instantaneous traffic spikes without capacity planning, making it a better fit for flash-sale load.
✓
Implement DynamoDB Accelerator (DAX) to cache read-intensive data.
Why this is correct
Implementing DynamoDB Accelerator (DAX) is correct because it puts a write-through, in-memory cache directly in front of your DynamoDB table. DAX intercepts repeated read requests—such as product details, pricing, or inventory views during a sale—and serves them in microseconds, dramatically reducing the read capacity units consumed by the table. This offloading lowers the chance of throttling your primary table while keeping latency low for read-heavy traffic.
✓
Use application-level retry logic with exponential backoff to handle throttling gracefully.
Why this is correct
Application-level retry logic with exponential backoff is a correct resilience technique for transient throttling. When DynamoDB returns ProvisionedThroughputExceededException, retrying immediately can worsen the bottleneck; exponential backoff spreads the retries over time so the table recovers without a synchronized thundering herd. However, retries alone cannot compensate for a severely under-provisioned table, so they must be combined with sufficient capacity or a cache to handle the actual peak demand.
✗
Enable DynamoDB Streams and replicate data to a read replica.
Why it's wrong here
Enabling DynamoDB Streams and replicating to a read replica is invalid because DynamoDB does not offer native read replicas. Streams is a change-data-capture mechanism that records item-level INSERT, MODIFY, and DELETE events, commonly used for event-driven workflows or to feed external stores, but it does not serve point reads or reduce load on the primary table. Offloading reads requires DAX, ElastiCache, or Global Tables for cross-region use, as appropriate for your consistency and latency requirements.

Go deeper

DOP-C02 Incident and Event Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question