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.

• ✓

  Switch to provisioned capacity with auto scaling to handle the spikes.

  Why this is correct

  For a workload with a predictable baseline and only occasional spikes, on-demand capacity's per-request pricing leads to unnecessary cost during the sustained baseline. Provisioned capacity bills a fixed hourly rate per read/write capacity unit, and DynamoDB auto scaling adjusts the provisioned units based on target utilization (e.g., 70%), so you pay for the baseline plus a small margin instead of paying each time a request occurs. This approach significantly reduces costs when the baseline traffic is steady, as the auto-scaling can scale up during known spike windows and scale down afterward. Because the question highlights cost reduction for recurring spikes, this is the correct action.

• ✗

  Enable DynamoDB Accelerator (DAX) to cache reads.

  Why it's wrong here

  DAX is an in-memory cache that serves read-heavy workloads by reducing the number of read requests that reach the underlying table, lowering read capacity consumption. However, it does not affect write capacity units or the per-request cost of writes, and it introduces an extra cluster cost that may outweigh the read savings. If your business pain is expensive write requests, DAX only adds cost and complexity without addressing the root cause. Therefore, it is not a solution here.

• ✗

  Create a global table to distribute write traffic.

  Why it's wrong here

  A global table replicates every write to each additional AWS Region, and each replica consumes write capacity units both in the originating Region and in all replica Regions. This actually increases total write costs by a factor roughly equal to the number of replica Regions, rather than distributing or reducing the load. It also adds cross-region replication latency and complexity, and does nothing to lower the per-request cost of a single-region write. Because the goal is to reduce write costs, global tables are counterproductive.

• ✗

  Use Amazon ElastiCache to buffer write requests.

  Why it's wrong here

  Amazon ElastiCache is a distributed in-memory cache commonly used to speed up application reads, but it is not integrated with DynamoDB to act as a write buffer or write queue. Any write to ElastiCache is still a separate call to DynamoDB, and that write still consumes write capacity units and incurs on-demand charges. While some architectures use Amazon SQS or Kinesis Data Streams to decouple and buffer writes, ElastiCache does not buffer DynamoDB writes in any way. As a result, it neither smooths spikes nor lowers write-related costs.

Go deeper

Related to this question