DOP-C02 Resilient Cloud Solutions 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) to cache frequently read data.

  Why this is correct

  DAX is a fully managed, in-memory caching service placed in front of DynamoDB, returning cached items with microsecond latency. By writing through and caching the frequently read flash-sale items, it absorbs the burst of read traffic before it reaches the table, which directly reduces consumed read capacity units and throttling events. This requires no costly rearchitecture or constantly adjusting provisioned throughput, making it the most appropriate solution for unpredictable read spikes.

• ✗

  Increase the read capacity units for the table during flash sale events.

  Why it's wrong here

  Raising the table's read capacity units for the flash sale is a short-term, cost-heavy measure that only addresses the symptom of throttling rather than the cause of bursty read load. You would need to provision for the absolute peak demand, which means paying continuously for far more capacity than the baseline requires, and any unexpected traffic above that still gets throttled. It also does not reduce the amount of work DynamoDB must perform per read, nor does it mitigate hot partitions that might limit a single partition's throughput.

• ✗

  Use DynamoDB Streams to replicate reads to a separate table.

  Why it's wrong here

  DynamoDB Streams captures a time-ordered sequence of item-level changes (creates, updates, deletes) for change data capture, and is meant for event-driven workflows like fanning out to Lambda or replicating to another data store. Reading from a separate table created via streams requires changing your application to point all read traffic to that replica, and the replica consumption still counts against the source or replica's capacity—it does not offload the existing table's read load. Streaming item changes does nothing to address the immediate read burst against the primary table or provide low-latency caching.

• ✗

  Implement Global Tables to distribute read traffic across multiple regions.

  Why it's wrong here

  Global Tables automatically replicate data across multiple AWS Regions for low-latency writes and disaster recovery scenarios, not for alleviating read throttling from a single-Region flash sale. Even with multi-region reads, the total provisioned read capacity in the source Region remains unchanged unless you explicitly add more, and the added complexity and replication lag make it an overkill approach. The root issue is the burst of read traffic on one table in one region, which DAX solves directly, whereas Global Tables would only help if traffic were intentionally distributed across geographic locations.

Go deeper

Related to this question