SAA-C03 Design High-Performing 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.

• ✗

  Increase the table's provisioned capacity (read/write units) to handle the promotion peak.

  Why it's wrong here

  More overall capacity can help with table-wide limits, but hot-partition throttling is caused by one physical partition becoming saturated by a single partition key value. Even with higher total table capacity, the tenantId = "ACME" partition can still hit its per-partition limits and continue throttling. It also tends to be costly for temporary spikes.

• ✓

  Change the partition key to include an additional sharding attribute derived from a hash of eventId.

  Why this is correct

  When all traffic targets one partition key value, that partition becomes the bottleneck regardless of total table capacity. Adding a shard/salt attribute to the partition key (for example, tenantId + shardId where shardId = hash(eventId) mod N) spreads writes across multiple partition key values, increasing partition-level parallelism. Because the scenario allows slight reordering across partitions, losing strict single-partition time ordering is acceptable while improving throughput and reducing throttling.

• ✗

  Enable DAX caching for all reads but keep the same partition key and item layout.

  Why it's wrong here

  DAX can reduce read latency and help offload repeat reads from DynamoDB, but it does not change where writes land. During a promotion, throttling is typically driven by heavy write demand as well, so the same hot partition remains a write hotspot. DAX effectiveness depends on having a high degree of repeated reads to the same keys.

• ✗

  Switch the table to eventually consistent reads for queries to lower read throttling.

  Why it's wrong here

  Eventually consistent reads reduce read request unit consumption for reads, which can help if throttling is purely read-related. However, it does not address write hot-partition throttling, and the scenario states throttling during a promotion where write and read load may both be high. Also, it does not increase partition-level parallelism.