A gaming leaderboard uses DynamoDB with 80% repeated reads of the same player profiles and suffers throttling during tournaments despite overprovisioned capacity. P99 latency must stay under 5 ms without changing application queries. Which data caching strategy optimizes DynamoDB read performance?

DynamoDB Accelerator is correct because it adds a fully managed read-through item and query cache in front of the table that requires only an endpoint change, automatically absorbing the stated 80% repeated reads, eliminating hot-key throttling even when provisioned throughput is already high, and delivering microsecond performance that keeps P99 under 5 ms without query rewrites. An ElastiCache for Redis cluster fails by integration model because while it can store profiles with microsecond retrieval and reduce backend reads, it is application-managed and forces the client to implement lookup, population, TTL and invalidation logic, violating the explicit no-change constraint. Increasing provisioned read capacity with auto scaling fails by performance mechanism because it adds throughput but provides no caching layer, so repeated keys still hit storage, hot partitions can still throttle despite higher limits, and baseline DynamoDB single-digit millisecond latency cannot guarantee sub-5 ms P99. Configuring DAX for strongly consistent reads fails by cache semantics because DAX accelerates eventually consistent item and query caching, whereas strongly consistent reads bypass the item cache and are passed through to DynamoDB, preserving freshness but forfeiting throttling relief and microsecond latency. For the exam, treat without application changes as the decisive discriminator between DAX and ElastiCache, and remember strongly consistent or transactional reads do not benefit from DAX caching. In practice, validate HitRate, ItemCacheHits, QueryCacheHits, ThrottledRequests and read P99 in CloudWatch during a tournament load test to confirm repeated profiles are served from cache.