AWS Certified Solutions Architect Professional SAP-C02 Practice Question

The correct answer is to use an Application Load Balancer (ALB) with a multi-AZ Auto Scaling group and an Amazon ElastiCache for Redis cluster. This approach effectively decouples the application's state from the compute instances. By moving the session data to a centralized, highly available ElastiCache for Redis cluster, any EC2 instance in any AZ can handle any user request, as the session data is no longer stored locally. The multi-AZ Auto Scaling group ensures that the application is resilient to both instance failures (by automatically replacing unhealthy instances) and AZ failures (by distributing instances across multiple zones). The ALB distributes traffic across these healthy instances. This solution requires only a configuration change in the application to point to the Redis endpoint, rather than a full re-architecture.

Using a Network Load Balancer (NLB) with sticky sessions is incorrect because if the specific instance a user is 'stuck' to fails or the AZ it is in becomes unavailable, the user's session data is lost. Sticky sessions do not provide resiliency for the session state itself.

Using AWS Backup with a manual or scripted restore process is a disaster recovery (DR) strategy, not a high availability (HA) solution. This approach would result in significant downtime while new instances are provisioned and restored from a snapshot, failing to meet the requirement for high availability.

Using AWS Global Accelerator to fail over between two standalone instances is not ideal. This is an active-passive setup which is less resilient than an active-active load-balanced architecture. More importantly, it does not solve the core problem of session state. When a failover occurs to the standby instance, the in-memory session data from the primary instance is lost.