A company needs a caching layer that supports complex data structures (sorted sets, lists, pub/sub messaging), automatic Multi-AZ failover, and data persistence to disk. Which ElastiCache engine should they choose?
- AMemcached — simple key-value cache, no replication, no persistence, no complex data structures.
- BRedis — supports rich data structures, replication, Multi-AZ with automatic failover, and optional persistence (RDB/AOF).✓ Correct
- CDynamoDB Accelerator (DAX) — purpose-built for DynamoDB, not a general-purpose cache.
- DAmazon CloudFront — a CDN for HTTP caching, not an in-memory application cache.
Redis vs Memcached: Redis supports data structures (strings, hashes, lists, sets, sorted sets), pub/sub, replication, Multi-AZ failover, persistence, backup/restore, and Lua scripting. Memcached is simpler: multi-threaded, horizontally scalable, but no replication, no persistence, no complex data types. Use Redis for most production caching needs.
Which caching strategy loads data into the cache only when a cache miss occurs — the application queries the cache first, and if not found, fetches from the database and populates the cache?
- ALazy Loading (Cache-Aside) — only caches data that is actually requested; cache is populated on misses.✓ Correct
- BWrite-Through — writes data to the cache and the database simultaneously on every write.
- CWrite-Behind (Write-Back) — writes to cache first, then asynchronously flushes to the database.
- DCache Pre-warming — proactively populates the cache with anticipated data before requests arrive.
Lazy Loading pros: only requested data is cached (efficient memory use). Cons: cache miss penalty (three trips: cache, DB, then cache write), possible stale data. Write-Through pros: data is always fresh. Cons: unused data occupies cache, write latency increases. Combining both strategies is common in production.
A company uses ElastiCache Memcached with 5 cache nodes for session storage. One node fails. What happens to the user sessions stored on that node?
- ASessions are automatically replicated to the remaining 4 nodes and users are unaffected.
- BSessions stored on the failed node are lost — Memcached does not support replication or failover.✓ Correct
- CMemcached automatically promotes a replica node to replace the failed node.
- DSessions are backed up to S3 and restored to a new node automatically.
Memcached is a simple, distributed cache with no replication or persistence. Data on a failed node is permanently lost. For session data requiring high availability, use ElastiCache Redis (which supports replication and Multi-AZ) or store sessions in DynamoDB. This is a key exam differentiator between Memcached and Redis.
Which caching strategy writes data to both the cache and the database on every write operation, ensuring the cache is always up to date?
- ALazy Loading — only populates cache on read misses.
- BWrite-Through — updates cache and database simultaneously on every write; cache always has current data.✓ Correct
- CRead-Through — cache is populated automatically on reads via a cache provider plugin.
- DTime-To-Live (TTL) expiration — data expires automatically, not a write strategy.
Write-Through: every write updates both cache and database. Pros: data in cache is always fresh, no stale reads. Cons: write operations have additional latency, and the cache fills with data that may never be read (wasted memory). Best combined with a TTL to expire unused cached items.
An ElastiCache Redis cluster fails over from the primary to a replica. A small amount of data written to the primary just before the failure is not present on the new primary. Why does this happen?
- ARedis uses synchronous replication, so all data should always be on the replica.
- BRedis uses asynchronous replication — there is a small replication lag, and writes not yet replicated before failure are lost.✓ Correct
- CThe replica discards all data received in the last hour before becoming primary.
- DElastiCache does not support replication at all — each node is independent.
ElastiCache Redis replication is asynchronous, meaning the primary acknowledges writes before they are replicated to read replicas. During a failover, the newly promoted replica may be slightly behind the primary (replication lag), resulting in potential data loss of the most recent writes. This is a known trade-off in Redis Multi-AZ configurations.