SOA-C02 Reliability and Business Continuity Practice Question
A company runs a stateless web application on EC2 instances behind an Application Load Balancer. The application is deployed in an Auto Scaling group with a minimum of 2 and maximum of 10 instances. During a traffic spike, the Auto Scaling group launches new instances, but the new instances are immediately marked as unhealthy by the ALB and terminated. What could be the cause? (Choose TWO.)
⚠ Common exam trap
The trap here is that candidates often overlook the security group requirement for inbound traffic from the ALB, assuming that the ALB can always reach instances, or they confuse IAM roles with network-level registration requirements.
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
✓
The health check path is misconfigured.
Option A is correct because if the ALB health check path is misconfigured (for example, pointing to a non-existent URL or wrong port), the target group health checks will fail and the ALB will mark the newly launched instances as unhealthy, causing the Auto Scaling group to terminate them. Option D is correct because the ALB must be able to reach the instances on the health check and traffic ports; if the instances' security group does not allow inbound traffic from the ALB's security group (or from the ALB subnet CIDRs), the health checks will time out and the instances will be marked unhealthy. Option B is not correct because insufficient capacity in a target AZ would prevent instances from launching at all, not cause them to launch and then be marked unhealthy by the ALB. Option C is not correct because EC2 instances do not need an IAM role to register with an ALB; target registration is handled by the Auto Scaling group or ELB service itself, not by instance-level IAM permissions. Option E is not correct because a larger instance type does not inherently cause ALB health checks to fail; instance size is unrelated to health check success.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The health check path is misconfigured.
Why this is correct
The ALB health check sends HTTP(S) requests to a configured path and expects a 2xx or 3xx response within a set timeout. If the path is incorrect (e.g., a missing endpoint or a route that returns 404), the health check fails, causing the ALB to mark the instance unhealthy and eventually terminate it. This is the most common cause of healthy-appearing instances being deregistered, and correcting the path to a verified reachable endpoint resolves the issue.
- ✗
The Auto Scaling group does not have sufficient capacity in the target AZ.
Why it's wrong here
Insufficient Auto Scaling Group capacity in the target Availability Zone would prevent the ASG from launching new instances or cause scaling failures, but it does not directly affect ALB health checks. Health check status is determined solely by the ALB's ability to reach the instance on the configured port and path, independent of the ASG's capacity. Even if the ASG cannot scale out, existing registered instances still receive health checks, so this option does not explain why the instances are marked unhealthy.
- ✗
The instances do not have the required IAM role to register with the ALB.
Why it's wrong here
An IAM role assigned to an EC2 instance grants permissions for API actions that the instance itself can perform, such as calling S3 or DynamoDB. However, the ALB registers and deregisters instances using its own service-linked role (AliyunSLBHealthCheckRole or AWSServiceRoleForElasticLoadBalancing), not the instance's IAM role. Health check requests are network probes that do not require any IAM identity, so missing or misconfigured IAM roles on the instances cannot cause health check failures.
- ✓
The security group for the instances does not allow inbound traffic from the ALB.
Why this is correct
ALB health checks originate from the ALB's network interfaces, and for them to succeed the instance's security group must allow inbound traffic on the health check port (typically 80 or 443) from the ALB's security group. A common best practice is to reference the ALB's security group as the source, rather than a blanket CIDR. If the inbound rule is missing or restricts the source to an unrelated range, the ALB's probes timeout and the instance is marked unhealthy, even though the application itself is running.
- ✗
The instances are launched with a larger instance type than expected.
Why it's wrong here
Choosing a larger instance type affects compute memory, CPU, and network performance, but has no bearing on the ALB's ability to perform an HTTP(S) health check. The health check evaluates whether the specified path returns a valid HTTP response, which is a function of the application and networking configuration, not the instance's hardware class. Unless the larger instance type causes the application to crash or the security group to be misconfigured, it remains an irrelevant factor in health check status.
Visual reference
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.