A software company runs a workload on Amazon EC2 instances behind an Application Load Balancer (ALB). A SysOps administrator needs to define a custom health check for the EC2 instances. What is the…

Question

Options

• ASet up each EC2 Instance so that it writes its healthy/unhealthy status into a shared Amazon S3
• BConfigure the health check on the ALB and ensure that the HeathCheckPath setting s correct
• CSet up Amazon ElasticCache to track the EC2 instances as they scale in and out
• DConfigure an Amazon API Gateway health check to ensure custom checks on aw of the EC2

• A
  7% (2)
• B
  75% (21)
• C
  4% (1)
• D
  14% (4)

Explanation

Option B is correct because ALBs have a built-in health check mechanism - configuring HealthCheckPath to point to a custom endpoint (e.g., /health) on your EC2 instances is the native, purpose-built way to define custom health checks with zero additional infrastructure. This is operationally efficient because the ALB already sits in front of your instances and natively handles routing traffic away from unhealthy targets.

Why the distractors are wrong:

• A (S3): Writing health status to S3 requires custom code, doesn't integrate with ALB routing, and adds latency/complexity with no operational benefit.
• C (ElastiCache): ElastiCache is an in-memory caching service - it has no native ability to track EC2 health or influence ALB routing decisions.
• D (API Gateway): API Gateway is an API management service, not a health-check tool; adding it purely for health checks introduces unnecessary cost and architectural complexity.

Memory tip: Think "use the tool that's already in the path." The ALB is already inspecting every request to your EC2 instances - leverage its built-in HealthCheckPath rather than bolting on a separate system.

No community discussion yet for this question.