Free SAA-C03 practice scenarios: ElastiCache

ElastiCache is an in-memory cache that serves repeated read results in microseconds, absorbing traffic that would otherwise hit the database — the standard way to relieve a read-bound database. Why not the others: scaling the instance up buys headroom but does not stop the repeated identical queries and hits a ceiling. S3 is object storage, not a query engine for a relational workload. Adding Availability Zones improves availability, not read throughput for repeated queries. Microsecond read offload is ElastiCache (or read replicas for more relational read capacity).

Redis supports replication, Multi-AZ with automatic failover, and persistence, so it is the engine when high availability and durability of the cache matter. Why not the others: Memcached is a simpler cache with no replication, failover, or persistence — that is the defining distinction between the two. So 'either engine' is wrong, and caches most certainly can be made highly available with Redis. When the requirement lists replication, failover, or persistence, it is Redis.

Memcached is a simple, multithreaded cache that scales out by sharding across nodes and uses multiple cores — ideal when you want plain caching with no persistence or replication. Why not the others: Redis is feature-rich and the right call when you need its extra capabilities, but it is more than 'the simplest cache' asks for. RDS read replicas scale relational reads, not an in-memory cache. DAX is a cache specifically for DynamoDB, not a general database offload. Simple, multithreaded, no-persistence caching is Memcached.

Storing sessions in an external ElastiCache for Redis store lets every stateless instance read and write the same session data, so any instance can serve any user — the standard pattern for a horizontally scaled web tier. Why not the others: local disk ties a session to one instance, breaking as soon as the load balancer routes the user elsewhere. A load balancer does not store application session state. Putting full server-side session data in a cookie is insecure and size-limited. Shared session state belongs in an external cache like Redis.

In lazy loading, the app checks the cache; on a miss it reads the database, returns the value, and populates the cache so subsequent reads hit — data is loaded only when actually requested, which keeps unused data out of the cache. Why not the others: writing every update into the cache on write is write-through, a different strategy. ElastiCache does not itself query the database; the application orchestrates the cache-aside flow. And a miss does not fail the request — it falls back to the database. Cache-miss-then-populate is lazy loading.

Redis provides rich data structures — sorted sets for leaderboards, pub/sub channels, and geospatial indexes — which is why it is chosen when the workload needs more than plain key-value caching. Why not the others: Memcached offers only simple key-value storage, with none of these structures. RDS is a relational database, not an in-memory structure store, and would be far slower for real-time ranking. Athena queries data in S3 with SQL and is unrelated. Rich in-memory data structures are Redis.