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 . What is the MOST…

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 Health Check Path setting is correct.
• CSet up Amazon ElastiCache to track the EC2 instances as they scale in and out.
• DConfigure an Amazon API Gateway health check to ensure custom checks on all of the EC2

• A
  3% (2)
• B
  89% (58)
• C
  2% (1)
• D
  6% (4)

Explanation

Option B is correct because the Application Load Balancer has a built-in health check mechanism that natively monitors EC2 instances - you simply configure a Health Check Path (e.g., /health) on the target group, and the ALB periodically sends HTTP requests to that path to determine instance health. This is purpose-built, requires no additional infrastructure, and integrates directly with Auto Scaling to remove unhealthy instances automatically.

Why the distractors are wrong:

• A (S3): Writing health status to S3 is a manual, home-grown solution that introduces complexity and latency - nothing automatically acts on that data without additional tooling.
• C (ElastiCache): ElastiCache is an in-memory caching service; it has no capability to track or evaluate EC2 instance health.
• D (API Gateway): API Gateway is a managed API frontend service, not a health monitoring tool - using it for health checks adds unnecessary cost and architectural complexity.

Memory tip: When a question involves an ALB and EC2 health checks, the answer is almost always "configure it on the ALB/target group." The rule of thumb is: use the native feature of the service already in the architecture before reaching for an external tool.

No community discussion yet for this question.