nerdexam
AmazonAmazon

SOA-C02 · Question #605

SOA-C02 Question #605: Real Exam Question with Answer & Explanation

The correct answer is B: Add Elastic Load Balancing (ELB) health checks to the Auto Scaling group.. Why B is correct: The Auto Scaling group is only configured for EC2 status checks, which only verify that the instance is running at the infrastructure level - not that the application itself is healthy. Adding ELB health checks tells Auto Scaling to also consider whether the ALB

Submitted by haru.x· Mar 30, 2026Reliability and Business Continuity

Question

A company's ecommerce application is running on Amazon EC2 instances that are behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. Customers report that the website is occasionally down. When the website is down, the website returns an HTTP 500 (server error) status message to customer browsers. The Auto Scaling group's health check is configured for EC2 status checks, and the instances are healthy. Which solution will resolve the problem?

Options

  • AReplace the ALB with a Network Load Balancer.
  • BAdd Elastic Load Balancing (ELB) health checks to the Auto Scaling group.
  • CUpdate the target group configuration on the ALB. Enable session affinity (sticky sessions).
  • DInstall the Amazon CloudWatch agent on all the instances. Configure the agent to reboot the

Explanation

Why B is correct: The Auto Scaling group is only configured for EC2 status checks, which only verify that the instance is running at the infrastructure level - not that the application itself is healthy. Adding ELB health checks tells Auto Scaling to also consider whether the ALB can successfully reach and get a valid response from the instance; when an instance returns HTTP 500s, the ELB health check fails, Auto Scaling terminates that instance and launches a replacement.

Why the distractors are wrong:

  • A - Switching to a Network Load Balancer operates at Layer 4 (TCP), not Layer 7 (HTTP), so it has no awareness of HTTP 500 errors and wouldn't solve the problem.
  • C - Sticky sessions route a user to the same instance repeatedly; this doesn't fix unhealthy instances returning 500s and could actually make the problem worse by pinning users to a broken instance.
  • D - The CloudWatch agent collects metrics/logs but doesn't inherently reboot instances based on HTTP errors; this is a reactive band-aid and not the correct architectural solution.

Memory tip: Think of it as "two layers of health" - EC2 checks confirm the server is on, ELB checks confirm the app is answering. Whenever you see "instances are healthy but the app is failing," that's the signal that EC2-only health checks are missing the application layer.

Topics

#Auto Scaling Group#ALB Health Checks#Application Reliability#EC2 Health Checks

Community Discussion

No community discussion yet for this question.

Full SOA-C02 PracticeBrowse All SOA-C02 Questions