DOP-C02 Resilient Cloud Solutions Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  The target group health check path is '/health' but the application does not serve that endpoint

  Why this is correct

  A 503 response from the ALB health check means the target instance accepted the TCP connection and returned an HTTP response, but the response status code was not a success (2xx/3xx). If the health check path is '/health' and the application does not define that route, the web server returns a 503 error because no handler matches the request. To resolve this, the health check path must be changed to an existing endpoint or the application must implement an endpoint that returns 200 OK on '/health'.

• ✗

  The CodeDeploy agent on the new instances is not running

  Why it's wrong here

  If the CodeDeploy agent on a newly launched instance were not running, the instance would never signal readiness to CodeDeploy, causing the deployment to hang or fail during the install or validation phase. However, the ALB health check is completely independent of the agent's state; it simply sends an HTTP request to the target IP:port and evaluates the response. Since the 503 indicates the application responded at the HTTP layer, the agent's absence is irrelevant to this specific health check outcome.

• ✗

  The security group for the ALB does not allow inbound traffic on port 80

  Why it's wrong here

  The ALB's security group controls inbound traffic from clients to the load balancer, not outbound health check requests from the ALB to the target instances. If inbound traffic were blocked on port 80, users would see connection timeouts because the ALB would never receive their requests, and health checks to targets would still work as long as the target security group allows traffic from the ALB. A 503 health check proves that the ALB successfully established a connection to the target on the health check port, so a security group misconfiguration is not the cause here.

• ✗

  The Auto Scaling group health check type is set to EC2 instead of ELB

  Why it's wrong here

  The Auto Scaling group's health check type (EC2 vs. ELB) determines how ASG monitors the health of its instances for auto-replacement actions, not how the ALB performs target health checks. Even if the health check type were EC2, the ALB would still use its own target group health check configuration to evaluate each instance's HTTP response. A 503 is generated by the application or web server in response to the ALB's health check request, and the ASG health check type has no bearing on that HTTP-level response.

Go deeper

Related to this question