SOA-C02 Cost and Performance 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.

• ✓

  Enable DynamoDB Accelerator (DAX).

  Why this is correct

  DynamoDB Accelerator (DAX) is an in-memory cache that sits in front of your DynamoDB table, serving reads at microsecond latency by avoiding disk access and the complexity of managing a separate caching tier. As a justified correct answer, it directly addresses read latency for even the most frequently accessed items, offloading repeated read traffic from the table's provisioned capacity and reducing the time each request takes from the database engine itself.

• ✓

  Use DynamoDB global tables.

  Why this is correct

  DynamoDB global tables replicate your data across multiple AWS Regions and allow you to read and write from the replica in the Region closest to your users. Its correct classification here stems from the fact that network round-trip time is a dominant factor in perceived latency, so serving reads from a local replica dramatically reduces end-to-end delay for geographically distributed clients, while also improving fault tolerance.

• ✗

  Enable Auto Scaling for read capacity.

  Why it's wrong here

  Auto Scaling for read capacity adjusts your provisioned read capacity units based on actual traffic patterns, but it does not change the fundamental latency of individual DynamoDB requests. It is wrong for improving performance in this scenario because its purpose is to prevent throttling at scale, not to reduce the per-request response time; if latency is due to hot partitions or large item sizes, Auto Scaling can even allocate capacity unevenly and leave bottlenecks unresolved.

• ✗

  Use Time to Live (TTL) to delete old items.

  Why it's wrong here

  Time to Live (TTL) is a cost- and storage-efficiency feature that automatically deletes expired items without consuming write capacity, yet it has no bearing on read latency. It is incorrect as a performance improvement because it simply removes stale data asynchronously in the background; it does not prefetch, cache, or optimize the path your active read requests take, and could actually delay a read if the expired item hasn't yet been purged and DynamoDB must evaluate its TTL status.

• ✓

  Increase the provisioned read capacity units.

  Why this is correct

  Increasing provisioned read capacity units grants more RCUs per second, which can eliminate throttling that inflates p95 and p99 latency when your application exceeds its current allotment. This is correct as a capacity-based remedy because throttled requests are rejected with HTTP 400 and must be retried, and raising the cap reduces queueing and retry delays; however, it is a scaling fix that assumes the bottleneck is throughput, not a substitute for caching or geo-replication if the table already supplies enough capacity.

Go deeper

Related to this question