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.

• ✗

  Disable auto scaling to provision fixed capacity

  Why it's wrong here

  Disabling auto scaling to provision fixed capacity is generally detrimental to performance optimization in variable workloads. While it provides a predictable baseline, it fails to dynamically adjust throughput to actual demand. This often results in under-provisioning during peak traffic, leading to throttling and degraded performance, or over-provisioning during off-peak times, incurring unnecessary costs without improving performance. It lacks the responsiveness needed for optimal DynamoDB operation.

• ✓

  Enable DynamoDB Accelerator (DAX) for caching

  Why this is correct

  Enabling DynamoDB Accelerator (DAX) significantly improves read performance by providing an in-memory cache for frequently accessed data. DAX intercepts read requests before they reach the DynamoDB table, serving cached items with microsecond latency. This drastically reduces the read load on the underlying DynamoDB table, effectively mitigating read-related throttling issues and enhancing application responsiveness for read-intensive workloads.

• ✗

  Increase the read capacity units (RCUs) of the table

  Why it's wrong here

  Increasing the total read capacity units (RCUs) of the table does not inherently resolve performance issues caused by a hot partition. DynamoDB distributes provisioned throughput across its physical partitions. If a single partition is receiving a disproportionately high volume of read requests, it will continue to throttle because its individual capacity limit is exceeded, regardless of the overall table's increased RCU count. The problem lies in uneven access patterns, not insufficient total capacity.

• ✓

  Add a random suffix to the partition key values

  Why this is correct

  Adding a random suffix to partition key values is an effective strategy to improve write performance by distributing writes more evenly across multiple physical partitions. By appending a random number or string to the original partition key (e.g., originalKey#random_suffix), you create a larger set of logical partition keys. This forces DynamoDB to spread write operations across a greater number of underlying partitions, preventing any single partition from becoming a write "hot spot" and experiencing throttling.

• ✗

  Use a global secondary index (GSI) with a different partition key

  Why it's wrong here

  Using a global secondary index (GSI) with a different partition key primarily improves query flexibility and can offload specific query patterns from the base table. However, a GSI has its own independent provisioned throughput and does not directly address or improve the performance of the base table's primary key access patterns. Writes to the base table still consume its write capacity, and reads directly against the base table's primary key will still be subject to the base table's capacity and partitioning limitations, potentially leading to throttling.

Go deeper

Related to this question