SOA-C02 High Availability Practice Question
A company runs a stateful web application on a single Amazon EC2 instance. The SysOps administrator needs to implement a high availability architecture that can tolerate an Availability Zone (AZ) failure. The application stores session state in memory and also writes critical data to an Amazon EBS volume. The administrator wants to use an Auto Scaling group and an Application Load Balancer (ALB). Which combination of steps is required to make the application highly available?
⚠ Common exam trap
Candidates often assume EBS volumes can be shared across instances or AZs, or that a single-instance setup with an ALB provides high availability, when in fact EBS is a single-AZ resource and the ALB requires multiple healthy targets to tolerate failures.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Migrate session state to Amazon ElastiCache for Redis, store critical data in Amazon EFS, create an Auto Scaling group across multiple AZs, and place it behind an ALB.
It addresses both the stateless requirement for horizontal scaling and the persistence of critical data across AZ failures. Migrating session state to ElastiCache for Redis removes the dependency on local instance memory, allowing any instance to handle any request. Storing critical data on Amazon EFS provides a shared, NFS-based file system that is accessible from all instances across multiple AZs, unlike EBS which is tied to a single AZ. Combining these with a multi-AZ Auto Scaling group and an ALB ensures the application can survive an entire AZ outage.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create an Auto Scaling group that spans at least two Availability Zones, attach the existing EBS volume to the new instances, and use an ALB to distribute traffic.
Why it's wrong here
An EBS volume can only be attached to one instance at a time. To share data, use a distributed file system like Amazon EFS or a database. This option does not solve the stateful issue.
- ✓
Migrate session state to Amazon ElastiCache for Redis, store critical data in Amazon EFS, create an Auto Scaling group across multiple AZs, and place it behind an ALB.
Why this is correct
This option makes the application stateless at the compute layer by externalizing session state to ElastiCache for Redis, which all instances can access, and storing critical application data on Amazon EFS, a shared regional file system. An Auto Scaling group spanning multiple Availability Zones ensures that an instance failure or entire AZ outage triggers replacement, while the ALB distributes traffic only to healthy instances and performs health checks. This architecture achieves both high availability and horizontal scalability because no unique state is tied to any individual EC2 instance.
- ✗
Place the EC2 instance in an Auto Scaling group with a minimum and maximum of 1 in the same AZ, and attach an Elastic IP to the instance.
Why it's wrong here
This approach confines the application to a single Availability Zone because the Auto Scaling group has both minimum and maximum set to 1 in the same AZ, so the instance cannot be replaced in another AZ during an outage. The Elastic IP simply provides a static public IP address; it does not monitor, fail over, or reattach to a replacement instance automatically. While the ASG can restart the instance, a zonal failure affecting the underlying hypervisor or network would still cause downtime, and the stateful local data remains inaccessible until the instance recovers.
- ✗
Use an ALB with the existing single instance as the target, and enable cross-zone load balancing.
Why it's wrong here
An ALB with a single instance as its target does not create any redundancy; if that instance's Availability Zone fails, the ALB has no other target to route to and returns an error. Enabling cross-zone load balancing only affects how traffic is distributed among targets that already exist in multiple AZs, but here there is only one target in one AZ, so it is ineffective. The stateful data stored on the instance's local disk remains a single point of failure, and the ALB does not address that persistence issue.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 247 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.