SOA-C02 Reliability and Business Continuity Practice Question

A SysOps administrator is troubleshooting a high error rate on an Application Load Balancer (ALB). The ALB is configured with two target groups: one for EC2 instances and one for Lambda functions. The administrator notices that the EC2 target group is unhealthy. Which THREE steps should the administrator take to resolve the issue?

⚠ Common exam trap

The trap here is that candidates often focus on scaling or DNS issues (Options A and C) instead of recognizing that the most common cause of an unhealthy target group is either a security group misconfiguration or an incorrect health check path, both of which are directly addressed by Options B and D.

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

✓

Verify that the EC2 instances' security groups allow traffic from the ALB.

The ALB communicates with EC2 instances using the private IP addresses of the instances. If the EC2 instances' security groups do not explicitly allow inbound traffic from the ALB's security group (or the ALB's VPC CIDR), the health checks and actual traffic will be blocked, causing the target group to be marked unhealthy. This is a common misconfiguration when the ALB and instances are in the same VPC.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Review the ALB's DNS resolution for the target instances.
Why it's wrong here
Reviewing the ALB's DNS resolution for the target instances is a red herring: an Application Load Balancer never uses DNS endpoints to reach registered targets. The ALB maintains a map of target private IP addresses from the Auto Scaling group or manual registration, then sends health checks and forwarded traffic directly to those IP addresses via the VPC network. Therefore, inspecting DNS records or resolving instance hostnames would have no bearing on a high error rate, as internal load balancing does not rely on instance DNS resolution.
✓
Verify that the EC2 instances' security groups allow traffic from the ALB.
Why this is correct
When an ALB forwards traffic to EC2 instances, it connects from the security group attached to the ALB's elastic network interfaces. If the instance security group's inbound rules do not explicitly allow TCP traffic on the listener port and health check port from that ALB security group (or the VPC CIDR), the instance silently drops both health check probes and client connections. Because security groups are stateful, outbound responses are allowed automatically, but the inbound rule must exist; otherwise the ALB sees connection timeouts, marks the targets unhealthy, and routes only to remaining instances, skyrocketing error rates.
✗
Increase the size of the Auto Scaling group to distribute load.
Why it's wrong here
Increasing the size of the Auto Scaling group only adds more EC2 instances; it does not alter the security groups, target group health check path/interval, or application code that are causing the failures. Newly launched instances will be subject to the same health check logic and likely fail identically, so they will be marked unhealthy and remain out of service, or if they do become healthy, they will just absorb the same application-level errors that are already occurring. Scaling out is a mitigation for capacity shortages on healthy instances, not a remediation for configuration or application faults that generate a high error rate.
✓
Check the health check settings on the target group for correct path and interval.
Why this is correct
The target group's health check settings define exactly how the ALB determines an instance's liveness, including the protocol, port, path, and expected success code. If the path is incorrect (for instance, the ALB probes /health but the application only exposes /status), or the interval and unhealthy threshold are too aggressive, the ALB will falsely conclude the instances are unhealthy and stop sending traffic to them, leaving only a few instances to handle all requests and thus generating a high error rate. Verifying these settings isolates whether the problem is a load balancer configuration mismatch rather than an instance networking or application failure.
✓
Inspect the application logs on the EC2 instances for errors.
Why this is correct
High error rates often stem from application-level problems, such as the health check endpoint returning a 500 due to a database connection failure, or the application producing HTTP errors under specific conditions. Reviewing the application (e.g., web server, app server, or custom logs) on the EC2 instances will reveal stack traces, timeout messages, or status codes indicating that the application itself is failing even though the network path and health check configuration are correct. This diagnostic is essential because neither security group adjustments nor health check tweaks can resolve errors caused by bugs in the application code, and it helps differentiate symptoms from root causes.

Visual reference

Quick reference

Cloud Service Model Comparison

Model	You Manage	Provider Manages	Examples
IaaS	OS, runtime, apps, data	Hardware, hypervisor, networking	EC2, Azure VMs, GCP Compute Engine
PaaS	Apps and data	OS, runtime, middleware, hardware	Elastic Beanstalk, Azure App Service
SaaS	Data and settings only	Everything else	Microsoft 365, Salesforce, Workday
FaaS / Serverless	Function code only	Infra, scaling, runtime	Lambda, Azure Functions, Cloud Run
CaaS	Containers and apps	Kubernetes, OS, hardware	EKS, AKS, GKE

Go deeper

SOA-C02 Reliability and Business Continuity Practice Question

Why each option matters

Option-by-option breakdown

Cloud Service Model Comparison

Related to this question