DVA-C02 Development with AWS Services 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 on-demand capacity mode to pay per request, avoiding provisioned capacity costs.

  Why this is correct

  On-demand capacity mode is optimal for web applications with unpredictable or spiky traffic patterns because it automatically scales capacity up or down based on actual request volume. This pay-per-request model eliminates the need for capacity planning and avoids the costs associated with over-provisioning RCUs and WCUs that sit idle during low traffic periods. Consequently, it often results in significant cost savings for variable workloads, as you only pay for the reads and writes your application actually performs.

• ✗

  Use provisioned capacity with 1 RCU per item, since eventually consistent reads consume half the RCUs.

  Why it's wrong here

  This option incorrectly assumes a fixed '1 RCU per item' for calculating read capacity. DynamoDB RCUs are consumed based on item size in 4KB blocks, not per item count. Specifically, an eventually consistent read consumes 0.5 RCU for an item up to 4KB in size, meaning larger items require more RCUs, making a blanket '1 RCU per item' an inaccurate and potentially costly miscalculation.

• ✗

  Use provisioned capacity with sufficient RCUs to handle strongly consistent reads, as they consume the same as eventually consistent.

  Why it's wrong here

  This statement is fundamentally incorrect regarding DynamoDB's read consistency models and RCU consumption. Strongly consistent reads consume twice the read capacity units (RCUs) compared to eventually consistent reads. A strongly consistent read requires 1 RCU for an item up to 4KB, whereas an eventually consistent read requires only 0.5 RCU for the same item size, making them distinct in cost and performance implications.

• ✗

  Use provisioned capacity with enough RCUs for peak traffic, and use DynamoDB Accelerator (DAX) for caching.

  Why it's wrong here

  While DAX can significantly improve read performance by caching, its primary purpose is not cost minimization, and it introduces additional infrastructure costs. Provisioning for peak traffic in provisioned capacity mode means paying for unused capacity during off-peak hours, which is inherently inefficient for variable workloads. Combining this with the extra expense of DAX would lead to a higher overall cost compared to leveraging DynamoDB's cost-effective on-demand capacity mode for unpredictable traffic.