SAA-C03 Design Cost-Optimized Architectures 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.

• ✓

  DynamoDB on-demand capacity mode

  Why this is correct

  DynamoDB on-demand capacity mode automatically scales read/write capacity to match actual traffic, so you never have to estimate peaks or pre-commit throughput. You pay only for the requests you actually make, which is ideal for unpredictable, spiky workloads because sudden bursts are absorbed without throttling or manual intervention. This mode eliminates both the risk of under-provisioning and the over-provisioning cost waste of fixed capacity plans, making it the most cost-effective and operationally simple choice for this scenario.

• ✗

  Reserved capacity for maximum daily traffic

  Why it's wrong here

  Reserved capacity (or a DynamoDB Savings Plan) requires an upfront commitment to a specific throughput level, which is cost-efficient only for steady, predictable usage. If you reserve for the maximum daily traffic of an unpredictable workload, you will pay for that peak throughput even during idle hours, and you may still violate the commitment if a spike exceeds the reserved amount. This approach not only wastes money but also fails to adapt dynamically to the workload's variability.

• ✗

  Provisioned capacity set for peak traffic

  Why it's wrong here

  Setting provisioned capacity to the peak traffic level means you explicitly allocate and pay for the highest read/write capacity units you expect, regardless of actual demand. Since the batch analytics job has unpredictable traffic, the table would be idle or low-usage most of the time, yet you would still incur the full cost of that peak provisioning. You would also need to manually adjust capacity or rely on autoscaling, which lags behind spiky bursts, making on-demand a better fit.

• ✗

  Global tables in every Region

  Why it's wrong here

  Global tables in every Region replicate the same DynamoDB table across multiple AWS Regions to provide low-latency access and high availability for disaster recovery. However, this does nothing to address the core problem of unpredictable traffic or capacity planning — each replica still requires its own capacity configuration and incurs write-replication costs. Scaling the number of regions multiplies infrastructure cost and operational overhead without providing any elastic throughput benefit, so it is an irrelevant and expensive solution for this scenario.

Go deeper

Related to this question