SOA-C02 Reliability and Business Continuity Practice Question

A team of developers is deploying a new microservice that uses Amazon DynamoDB as its data store. The SysOps administrator must ensure that the application can handle a sudden spike in read traffic without throttling. Which DynamoDB feature can be used to automatically handle increases in read capacity?

⚠ Common exam trap

Many candidates confuse DynamoDB Accelerator (DAX) with a scaling solution, thinking its caching automatically handles capacity increases, but DAX only reduces read load and does not modify provisioned capacity or prevent throttling from a sudden spike in uncached reads.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

DynamoDB Auto Scaling

DynamoDB Auto Scaling is the correct feature because it automatically adjusts the provisioned read and write capacity based on actual traffic patterns, preventing throttling during sudden spikes. The SysOps administrator can define a target utilization percentage (e.g., 70%), and DynamoDB Auto Scaling uses the Application Auto Scaling service to increase capacity before requests are throttled, ensuring consistent performance without manual intervention.

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 Global Tables
Why it's wrong here
DynamoDB Global Tables provide multi-region replication for high availability and disaster recovery, but they do not manage or adjust the table's provisioned read/write capacity. Each replica table maintains its own separate capacity settings, so while Global Tables can replicate data worldwide, they have no mechanism to scale throughput based on demand. They are therefore not the correct service for addressing capacity scaling needs.
✗
DynamoDB Time to Live (TTL)
Why it's wrong here
DynamoDB Time to Live (TTL) is a lifecycle feature that automatically deletes items after a specified expiry timestamp, primarily to manage storage costs and comply with data-retention policies. It does not influence the table's provisioned throughput or any dynamic scaling behavior, and it cannot respond to changes in traffic patterns. TTL simply removes stale data, so it is unrelated to capacity scaling.
✓
DynamoDB Auto Scaling
Why this is correct
DynamoDB Auto Scaling is the correct solution because it continuously adjusts a table's provisioned read and write capacity in response to actual traffic using the Application Auto Scaling target-tracking policy. By monitoring CloudWatch metrics like consumed capacity, it scales out before throttling occurs and scales in when traffic declines, all within user-defined minimum and maximum limits. This gives the microservice a fully automated way to handle variable load without manual capacity planning.
✗
DynamoDB Accelerator (DAX)
Why it's wrong here
DynamoDB Accelerator (DAX) is an in-memory cache that sits in front of DynamoDB, reducing read latency by serving repeated reads from memory, but it does not alter the table's provisioned capacity. Writes still consume write capacity units, and cache misses still consume read capacity units, so DAX cannot prevent capacity saturation or scale the underlying table. It improves performance only for read-heavy workloads, not for general capacity scaling.

Go deeper

SOA-C02 Reliability and Business Continuity Practice Question

Why each option matters

Option-by-option breakdown

Related to this question