SOA-C02 Cost and Performance Optimization Practice Question

A company runs a production Amazon DynamoDB table with provisioned capacity of 1000 write capacity units (WCU). The table experiences unpredictable spikes up to 2000 WCU, causing throttling. The SysOps administrator wants to minimize cost while handling the spikes. Which solution should be used?

⚠ Common exam trap

Many exam-takers choose DynamoDB Auto Scaling (Option C) thinking it handles spikes instantly, but they overlook the inherent scaling delay and the fact that it still requires a maximum capacity setting that may not cover sudden bursts, leading to throttling.

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

✓

Switch to on-demand capacity mode.

Switching to on-demand capacity mode eliminates throttling during unpredictable spikes by automatically scaling write capacity up to the required 2000 WCU without any manual intervention or pre-provisioning. This minimizes cost because you pay only for the actual reads and writes consumed, avoiding the fixed cost of over-provisioning for peak capacity that may be rarely used.

Answer analysis

Option-by-option breakdown

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

✓
Switch to on-demand capacity mode.
Why this is correct
Switch to on-demand capacity mode: On-demand mode instantly accommodates usage spikes without requiring capacity planning or pre-provisioning. You pay per request, so there is no charge for unused provisioned capacity, making it highly cost-effective for unpredictable write traffic. It eliminates throttling errors because DynamoDB automatically scales write and read capacity to match your application's actual demand, even during sudden bursts.
✗
Increase provisioned WCU to 2000 to cover the peak.
Why it's wrong here
Increase provisioned WCU to 2000 to cover the peak: This approach forces you to continuously pay for 2,000 write capacity units even when the average workload is far below that peak. Since provisioned capacity is billed per hour regardless of actual consumption, the excess capacity is wasted and inflates operational costs. It does not adapt to fluctuating demand and provides no mechanism to reduce capacity when the spike subsides, making it a financially inefficient solution.
✗
Enable DynamoDB Auto Scaling with minimum 1000, maximum 2000 WCU.
Why it's wrong here
Auto Scaling adjusts capacity based on utilization, but it can take several minutes to scale up. Sudden spikes may cause throttling before capacity increases. It also requires careful configuration and does not guarantee no throttling.
✗
Use a DynamoDB Accelerator (DAX) cache.
Why it's wrong here
Use a DynamoDB Accelerator (DAX) cache: DAX is an in-memory cache that primarily minimizes read latency and reduces read request costs by offloading repeated reads from the table. It has no effect on write throughput; write requests are still processed by DynamoDB itself and still consume WCUs, leaving your write throttling and scaling problems completely unresolved. Therefore, adding a DAX cluster would not prevent or mitigate write capacity exceedances.

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question