Exam AWS Certified SysOps Administrator - Associate topic 1 question 239 discussion

Answer B https://www.examtopics.com/discussions/amazon/view/6364-exam-aws-sysops-topic-1-question-698-discussion/

This issue arises when there's a discrepancy between the health checks of the Auto Scaling Group (ASG) and the Application Load Balancer (ALB): Auto Scaling Group health checks (by default) use EC2 status checks — these only verify that the instance is running and reachable at a system level. ALB health checks, however, are application-level — they check a specific port and path (e.g., /healthcheck) on the instance.

By default, Auto Scaling groups use EC2 status checks only, which verify that the instance is running and reachable. These basic checks don't validate if the application running on the instance is functioning properly. Meanwhile, the ALB target group performs more thorough health checks that validate if the application is responding correctly on the specified port and path. It's checking the actual application health, not just if the instance is running.

D. id the port or path is incorrect, ALB will always show unhealthy. ECS auto scaling is healthy because the ec2 instances are running fine, however ALB is not routing to the healthy EC2 instance via TG, that is why ALB doesn't show healthy.

Auto Scaling group health checks by default only check for EC2 status checks (e.g., instance availability or hardware issues). If the EC2 instance is running but the application on it is not functioning properly, the instance can still show up as healthy in the Auto Scaling group but unhealthy in the ALB target group. ALB target group health checks monitor the health of the application on a specific port or path. If the application on the EC2 instance is not responding correctly to these health checks, the instance will be marked as unhealthy in the ALB, even though it is still considered healthy by the Auto Scaling group. It's B

I think the keyword here is "some of" If the Target group health check is configured with an incorrect port or path, all EC2s in ASG should show unhealthy.

Health-checks configuration issue.

Answer is D. There is no such a thing as AutoScaling group Health check. Health check belongs to Target Groups which are attached to ALB. Auto Scaling health check is for EC2 instances not the AutoScaling group

option D

If an EC2 instance is healthy according to the Auto Scaling group but unhealthy according to the ALB target group, it could be because the security groups are not allowing traffic between the ALB and the EC2 instances. The Auto Scaling group health check might be passing because it only checks that the EC2 instance is running, not that it can accept traffic from the ALB. A is correct

1. EC2 instances show up as healthy in the Auto Scaling group - So out of the question. 2. but show up as unhealthy in the ALB target group. - D it is.

If ALB is configured with incorrect path alle the instances should fail, so i vote d

This one is tricky doing some research i found the following: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-healthchecks.html https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html Cant be sec group, otherwise ALL would fail, and only a few are failing. So B is the the one that applies here.

Health checks are in a ALB target group. "The load balancer sends a health check request to each registered target every HealthCheckIntervalSeconds seconds, using the specified port, protocol, and ping path." https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html

I can't understand why A is wrong. ALBs perform Health Checks on their targets by accessing each target using HTTP/HTTPS over the port specified in Health Check settings. Clearly an improperly configured Security Group on an ASG instance could block an ALB health check over HTTP(S). https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html

alb health check failed

D is correct