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.

• ✗

  Increase the read capacity units to avoid throttling.

  Why it's wrong here

  Increasing the read capacity units manually is an over-provisioning strategy: you pay hourly for every RCU regardless of whether a request actually consumes it. For a workload with fluctuating demand, this means sustaining charges for idle capacity just to avoid throttling. Auto scaling or on-demand capacity are designed to address throttling without the cost penalty, so simply cranking up RCU is not a cost-optimization approach.

• ✓

  Use provisioned capacity with auto scaling.

  Why this is correct

  Provisioned capacity with auto scaling is the most cost-effective approach for predictable workloads. DynamoDB uses CloudWatch alarms on utilization metrics (e.g., 70% of consumed capacity) to automatically increase or decrease your provisioned read and write capacity units, so you only pay for what your traffic actually requires. However, note that scaling happens gradually, so you must set sensible minimums and maximums to avoid both throttling and underused capacity.

• ✗

  Use DynamoDB global tables for multi-region replication.

  Why it's wrong here

  DynamoDB global tables replicate every write to each replica region as a separate write operation, and each replica maintains its own provisioned capacity and storage costs. If your application does not genuinely require multi-region low-latency reads and writes, enabling global replication multiplies your write capacity consumption and cross-region data transfer fees, making it a strictly more expensive choice rather than a cost optimization.

• ✓

  Use DynamoDB Accelerator (DAX) to cache read results.

  Why this is correct

  DAX provides a fully managed in-memory cache that intercepts read requests and serves them without consuming any table read capacity units. For read-heavy workloads where many requests hit the same hot items or query results, DAX can reduce the required RCU provisioning to a fraction of its original value, lowering the table's cost down by reducing the number of read capacity units you must purchase. The trade-off is that you must pay for the DAX cluster instance, but for steady read volumes that cluster cost is often far less than the RCU savings.

• ✗

  Use on-demand capacity mode.

  Why it's wrong here

  On-demand capacity mode offers pay-per-request pricing, meaning you never provision capacity and cannot throttle, but you pay a separate charge for every read and write request as well as for data stored. For workloads with steady or predictable usage, the per-request rate is generally higher than the equivalent hourly provisioned rate under provisioned mode, so the constant cost of on-demand will eventually exceed the cost of a properly sized provisioned table. Auto scaling with provisioned capacity is the better choice because it matches spend to actual demand without the premium associated with on-demand.

Go deeper

Related to this question