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.

• ✗

  Reserved capacity for maximum daily traffic

  Why it's wrong here

  Reserved capacity requires a 1-year or 3-year commitment to fixed Read/Write Capacity Units (RCUs/WCUs) and offers cost savings only when usage is steady and highly predictable. A dev sandbox with long idle periods would waste money because reserved capacity bills continuously even when there is zero traffic, and the daily maximum may occur rarely. This option also locks you into a capacity forecast that the unpredictable workload cannot support, making it the least flexible and most expensive choice here.

• ✗

  Provisioned capacity set for peak traffic

  Why it's wrong here

  Provisioned capacity set to peak traffic ensures that even the highest bursts are served without throttling, but it forces you to pay for those peak-level RCUs/WCUs around the clock, including during long idle periods. DynamoDB bills provisioned capacity per hour regardless of actual usage, so you would pay for capacity you almost never use, dramatically increasing the sandbox's cost without a proportional benefit. You could manually scale down during idle, but that introduces operational overhead and still leaves you exposed if traffic picks up before you adjust.

• ✓

  DynamoDB on-demand capacity mode

  Why this is correct

  DynamoDB on-demand capacity mode charges only for the read and write requests you actually make, with no minimum capacity, no capacity planning, and no manual scaling. It can instantly scale from zero to any required throughput to absorb traffic spikes, making it ideal for unpredictable workloads like a development sandbox that may sit idle for hours or days. During idle periods your bill drops to near zero, and you never have to worry about throttle errors or forecasting demand—exactly matching the workload characteristics described in the question.

• ✗

  Global tables in every Region

  Why it's wrong here

  Global tables replicate your DynamoDB table to multiple AWS Regions for low-latency access or disaster recovery, but they do not change the underlying capacity billing model—each replica still uses its own provisioned or on-demand capacity. Adding replicas significantly increases cost because every write must be replicated to all replica Regions, plus you incur cross-Region data transfer charges. A dev sandbox has no multi-Region requirements, so this option only adds unnecessary complexity, latency for write traffic, and cost while doing nothing to address idle-capacity waste.

Go deeper

Related to this question