Q31 — AWS SAA-C03 Ch.17
Question 31 of 89 | ← Chapter 17
Q1331. A company deployed a serverless application that uses Amazon DynamoDB as a database layer. The application has experienced a large increase in users. The company wants to improve database response time from milliseconds to microseconds and to cache requests to the database. Which solution will meet these requirements with the LEAST operational overhead?
- A. Use DynamoDB Accelerator(DAX). ✓
- B. Migrate the database to Amazon Redshift.
- C. Migrate the database to Amazon RDS.
- D. Use Amazon ElastiCache(Redis OSS).
Correct Answer: A. Use DynamoDB Accelerator(DAX).
Explanation
Correct Answer: AUse DynamoDB Accelerator (DAX).Why This Solution Meets the Requirements with the Least Operational Overhead? The company wants to improve DynamoDB response times from milliseconds to microseconds and cache frequent requests with minimal operational effort.Key Requirements:Ultra-low latency (microseconds) for DynamoDB reads.Caching layer to reduce direct database calls.Minimal operational overhead (no manual scaling, patching, or complex setup).Option A (DAX) is the best choice because:DynamoDB Accelerator (DAX) is a fully managed, in-memory cache designed specifically for DynamoDB. Reduces read latency from milliseconds to microseconds by caching frequently accessed data. No operational overhead--AWS manages scaling, patching, and failover. Seamless integration--works with existing DynamoDB APIs (no code changes needed for read operations). Cost-effective--pay only for the DAX cluster nodes (no need for separate caching infrastructure).Why Other Options Fail?B. Migrate to Amazon RedshiftRedshift is an OLAP (analytics) database, not optimized for low-latency OLTP (transactional) workloads. High operational overhead--requires manual tuning, vacuuming, and scaling. Not a caching solution--would not improve read latency for DynamoDB.C. Migrate to Amazon RDSRDS (MySQL, PostgreSQL, etc.) is a relational database, not a NoSQL solution like DynamoDB. Migrating would require significant code changes and rearchitecting the application. Does not provide microsecond latency out of the box (would need ElastiCache on top).D. Use Amazon ElastiCache (Redis OSS)ElastiCache (Redis/Memcached) is a general-purpose caching solution but requires manual integration with DynamoDB.Higher operational overhead--needs application-level caching logic (e.g., invalidation, write-through/write- behind).Not as seamless as DAX--DAX is purpose-built for DynamoDB, while ElastiCache requires more setup.How DynamoDB Accelerator (DAX) WorksDAX sits between your application and DynamoDB, caching frequently read items. Read requests are served from DAX (microsecond latency) if the data is cached.Uncached reads still go to DynamoDB (millisecond latency).Write operations are written to DynamoDB first, then invalidated in DAX (eventually consistent).Architecture DiagramApplication LayerDynamoDB Accelerator (DAX)(In-Memory Cache Cluster)Amazon DynamoDB TableKey TakeawaysDAX is the best choice for ultra-low-latency DynamoDB reads with minimal effort. Avoid migrating to Redshift/RDS--they are not designed for this use case. ElastiCache is a good alternative but requires more work than DAX.This solution ensures microsecond read performance with zero operational overhead.