AWS Certified Solutions Architect Professional SAP-C02 Practice Question

The correct solution is to deploy an Amazon ElastiCache for Redis cluster with Multi-AZ enabled. ElastiCache for Redis is an in-memory data store that provides sub-millisecond latency for both reads and writes, which is ideal for a high-performance, real-time bidding application's session store. By enabling the Multi-AZ feature, ElastiCache automatically provisions and maintains a replica in a different Availability Zone and will automatically fail over to it in the event of a primary node or AZ failure, thus meeting the high-availability requirement.

Storing session data in an Amazon DynamoDB table is a plausible but less optimal solution. While DynamoDB is highly available and durable, it is a disk-based database service that typically has single-digit millisecond latency, which is higher than an in-memory solution like ElastiCache. Although DynamoDB Accelerator (DAX) can reduce read latency to microseconds, it is a write-through cache, meaning writes still incur the latency of the underlying DynamoDB table, and it adds complexity and cost. For a real-time application where both read and write latency are critical, ElastiCache for Redis is the more performant choice.

Enabling sticky sessions on the Application Load Balancer is incorrect because it binds a user's session to a single EC2 instance. This directly contradicts the requirement to withstand an AZ failure, as the session data stored on that instance would be lost if the instance or its entire AZ fails.

Using Amazon S3 for session storage is not appropriate for this use case. S3 is an object storage service designed for durability and scalability, not for the low-latency, high-frequency read and write operations required for a session store. The latency of S3 would be far too high for a real-time bidding platform.