Caching and content delivery: SAA-C03 study notes and practice questions
What to know about Caching and content delivery for the SAA-C03 exam, from the Design High-Performing Architectures domain (24% of the exam guide), then 3 free questions to test it. Part of the SAA-C03 study guide.
Caching questions describe repeated reads that are slow or expensive. The scenario tells you where the repetition happens, which tells you which cache.
Which cache
Repeated reads of
Use
Notes
Static or cacheable web content, for users far from the origin
Amazon CloudFront
Edge locations worldwide; works with S3, ALB, API Gateway or any HTTP origin
Database query results or computed data
Amazon ElastiCache (Valkey, Redis OSS or Memcached)
Sub-millisecond reads; needs application code to use the cache
DynamoDB items
DynamoDB Accelerator (DAX)
Microsecond reads with almost no code change (DAX client is API-compatible); only caches eventually consistent reads
API responses
API Gateway caching (REST APIs)
Per-stage cache with a TTL
Session state
ElastiCache or DynamoDB
Makes web servers stateless
Caching strategies
Lazy loading (cache-aside): read from the cache; on a miss, read the database and write the result to the cache. Only requested data is cached, but a miss is slow and data can be stale. Add a TTL to limit staleness.
Write-through: the application writes to the cache whenever it writes to the database. Data is always fresh, but you cache things nobody reads, and it doesn’t work when something else writes to the database directly.
Most real designs use lazy loading with a TTL that matches how stale the business can tolerate.
CloudFront details
Origin access control keeps S3 origins private.
Cache behaviors set different rules per path (/images/* cached for a day, /api/* not cached).
Cache key and TTLs: fewer headers, cookies and query strings in the cache key means a higher hit ratio.
Invalidations remove objects before they expire; versioned file names avoid the need.
Origin Shield adds a central caching layer to cut load on the origin.
CloudFront Functions (lightweight, at the edge) and Lambda@Edge (more powerful) change requests and responses.
ElastiCache choices
Valkey or Redis OSS: replication, Multi-AZ failover, persistence, rich data types (sorted sets for leaderboards), pub/sub.
Memcached: simple, multi-threaded, no replication or persistence.
ElastiCache Serverless removes capacity planning.
Common traps
Adding read replicas when the same few queries repeat. A cache is cheaper and faster.
DAX for strongly consistent reads. Those bypass DAX and go to the table.
Write-through when an external process updates the database. The cache would miss those writes; use a TTL.
B. Right: Correct. CloudFront caches popular files at edge locations near readers, so repeat requests no longer cross continents. With origin access control, the bucket policy allows only the CloudFront service principal for that distribution, so the bucket stays private. Learn more: Restrict access to an Amazon S3 origin (opens in a new tab)
C. Wrong: Copies closer to readers would help latency, but this triples storage, adds replication charges and needs website logic to pick a bucket and sign requests for private objects. Readers far from all three Regions still wait. A CDN gives wider coverage with less to manage. Learn more: Replicating objects within and across Regions (opens in a new tab)
D. Wrong: This can work, but the team would have to build, patch and scale its own caching fleet in three Regions. Global Accelerator speeds up the network path to endpoints such as load balancers and EC2 instances; it does not cache content itself. CloudFront provides the caching as a managed service. Learn more: Endpoints for standard accelerators in AWS Global Accelerator (opens in a new tab)
Explanation
Repeated downloads of the same files by readers far from the origin Region are what a content delivery network is for. CloudFront caches the files at edge locations worldwide, and origin access control keeps the bucket private by allowing reads only from the distribution. The other options either do not cache, or need the team to run its own replicas or proxies.
An online retailer's product catalog runs on Amazon RDS for PostgreSQL.
The same few thousand product queries run tens of thousands of times a minute, and database CPU stays above 85%. The team wants these reads served in well under a millisecond.
A supplier feed updates prices directly in the database several times a day, and customers must see a new price within 5 minutes. The team can change how the application reads data but cannot change the supplier feed.
Which solution meets these requirements?
Choose one answer.
AA. Add Amazon ElastiCache, and change the application to cache query results on a cache miss with a 5-minute time to live (TTL).
BB. Add Amazon ElastiCache, and change the application to cache query results on a cache miss with no expiry, so popular items stay warm.
CC. Add three read replicas of the DB instance, and change the application to spread the catalog queries evenly across the replicas.
DD. Put Amazon RDS Proxy in front of the DB instance, and change the application to send all the catalog queries through the proxy endpoint.
Show the answer and explanation
Answer: A
A. Right: Correct. Repeated queries are answered from memory with microsecond-level latency, which takes most of the load off the database. Because the feed writes straight to the database, the cache cannot be updated on write; a 5-minute TTL makes each cached price expire and reload within the allowed delay. Learn more: Caching strategies for Memcached (opens in a new tab)
B. Wrong: This gives fast reads and removes the database load, but lazy loading with no expiry never refreshes an entry after the database changes. Prices updated by the supplier feed would stay stale indefinitely. A TTL is needed to bound how old a cached price can be. Learn more: Caching strategies for Memcached (opens in a new tab)
C. Wrong: Replicas would share out the CPU load, but every read is still a full database query, so latency stays at database speeds rather than in-memory speeds. Replication is also asynchronous, and the company pays for three more database instances. An in-memory cache meets the latency goal. Learn more: Working with DB instance read replicas (opens in a new tab)
D. Wrong: RDS Proxy pools and reuses database connections, which helps when many connections strain the database. It does not cache query results, so every query still runs on the database and CPU stays high. A cache is needed to avoid running the queries at all. Learn more: Amazon RDS Proxy (opens in a new tab)
Explanation
Very fast repeated reads point to an in-memory cache, but the freshness rule decides how to use it. The supplier feed writes straight to the database, so write-through caching is not possible; lazy loading with a TTL of 5 minutes or less bounds how stale a price can get. Read replicas and RDS Proxy still run every query on a database engine.
A mobile game stores tournament leaderboards in an Amazon DynamoDB table.
During live tournaments, the same few thousand items are read millions of times per minute, and the application reads them with strongly consistent GetItem calls. The product owner confirms that leaderboard scores up to a few seconds old are acceptable.
The team needs read latency in microseconds and wants the FEWEST changes to the application code.
Which solution meets these requirements?
Choose one answer.
AA. Add a DynamoDB Accelerator (DAX) cluster, swap the DynamoDB client for the DAX client, and keep the strongly consistent reads unchanged.
BB. Add a DAX cluster, swap the DynamoDB client for the DAX client, and change the leaderboard reads to eventually consistent.
CC. Add an Amazon ElastiCache cluster, and write cache-aside code that checks the cache first and loads items from DynamoDB on a miss.
DD. Switch the table to on-demand capacity mode so that it absorbs the read spikes, and keep the strongly consistent GetItem calls unchanged.
Show the answer and explanation
Answer: B
A. Wrong: DAX is API-compatible with DynamoDB, so the client swap is small. However, DAX passes strongly consistent reads straight through to DynamoDB and does not cache the results, so reads would stay at millisecond latency. Learn more: DAX and DynamoDB consistency models (opens in a new tab)
B. Right: Correct. DAX serves eventually consistent reads from memory in microseconds and suits a small set of hot items read very often. Because it uses the DynamoDB API, the only code changes are the client and the consistency flag, and slightly stale scores are acceptable. Learn more: In-memory acceleration with DynamoDB Accelerator (DAX) (opens in a new tab)
C. Wrong: ElastiCache can serve hot items from memory very quickly, so it could meet the latency goal. However, the team would have to write and maintain caching logic, including loading and expiring items, which is more code change than DAX needs. Learn more: Common ElastiCache use cases (opens in a new tab)
D. Wrong: On-demand capacity removes the need to plan read capacity for spikes, but every read is still served by DynamoDB itself. DynamoDB reads take single-digit milliseconds, so this cannot reach microsecond latency. Learn more: DynamoDB on-demand capacity mode (opens in a new tab)
Explanation
Microsecond reads of hot DynamoDB items with minimal code change point to DAX, but DAX only caches eventually consistent reads; strongly consistent reads go straight to the table. Because slightly stale scores are acceptable, switching the reads to eventually consistent lets DAX serve them. ElastiCache needs custom caching code, and on-demand capacity does not change latency.
Want more on Caching and content delivery? The 5 full-length practice sets have 11 more Caching and content delivery questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →