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.

• ✓

  Use SQS to decouple write-heavy workloads and handle spikes.

  Why this is correct

  SQS acts as a buffer, decoupling the producer (application) from the consumer (DynamoDB). During write-heavy workloads or sudden traffic spikes, SQS queues the requests, allowing the application to continue processing without being throttled by DynamoDB's provisioned capacity. A separate worker process can then consume messages from SQS at a controlled rate, ensuring DynamoDB's write capacity units (WCUs) are not exceeded and operations are processed reliably. This prevents throttling errors and improves overall system resilience.

• ✓

  Use partition keys with high cardinality to distribute traffic evenly.

  Why this is correct

  A high-cardinality partition key ensures that data is distributed across many logical partitions within DynamoDB. This even distribution prevents "hot partitions," where a disproportionate amount of read or write traffic targets a single partition, leading to throttling even if the overall table capacity is sufficient. By spreading the load, DynamoDB can utilize its underlying physical resources more effectively, optimizing performance and avoiding bottlenecks.

• ✗

  Provision maximum write capacity units to handle any spike.

  Why it's wrong here

  Provisioning maximum write capacity units (WCUs) to handle every conceivable spike is an inefficient and costly strategy. While it might prevent throttling, it results in significant over-provisioning during periods of normal or low traffic, leading to unnecessary expenses for unused capacity. A more cost-effective and performant approach is to use DynamoDB Auto Scaling, which dynamically adjusts provisioned capacity based on actual usage patterns and defined target utilization, ensuring optimal performance without excessive costs.

• ✗

  Use Scan operations instead of Query for retrieving data.

  Why it's wrong here

  Scan operations are generally inefficient for retrieving specific data because they read every item in the table or secondary index, then filter the results. This consumes significant read capacity units (RCUs) and can be very slow for large tables, especially if only a small subset of data is needed. Query operations, conversely, are highly efficient as they directly retrieve items based on primary key values or secondary index keys, targeting specific partitions and minimizing resource consumption.

• ✗

  Enable strongly consistent reads for all read operations.

  Why it's wrong here

  Enabling strongly consistent reads for all operations is not a best practice for optimizing performance, as they are generally more expensive in terms of latency and potentially read capacity units (RCUs) compared to eventually consistent reads. Strongly consistent reads ensure that a read returns the most up-to-date data, but they require coordination across multiple storage nodes, which can introduce higher latency. For many use cases where immediate data consistency is not critical, eventually consistent reads offer better performance and lower cost by reading from any available replica.

Go deeper

Related to this question