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.

• ✗

  Change the health check port to 443 and use HTTPS

  Why it's wrong here

  Changing the health check to port 443 with HTTPS would not resolve a 503 status code. A 503 Service Unavailable response means the load balancer successfully reached the instance on the current health check port (80) and received an HTTP response, but the application itself is not ready to serve requests. Using HTTPS on 443 would change the negotiation protocol and port, but the underlying issue is that the application returns an error status, not a connectivity or protocol mismatch. Unless the application only listens on 443, this change would likely cause the health check to fail with a connection timeout or TLS error rather than address the 503.

• ✓

  Verify that the application on the unhealthy instance is configured to respond to '/' with a 200 status code

  Why this is correct

  A 503 status code from the health check endpoint indicates that the target instance is reachable at the HTTP layer, but the application logic serving the root path '/' is returning a Service Unavailable error. Elastic Load Balancing requires a 2xx or 3xx response for the health check to mark the instance healthy; any 4xx or 5xx status counts as unhealthy. Verify that the web server or application is configured to serve '/' with a 200 OK during normal operation and that there are no authentication, redirect, or maintenance-mode rules that cause a 503 on that specific path. This is the correct troubleshooting step because the health check is working as designed—it is detecting an application-level failure.

• ✗

  Increase the health check interval and timeout settings

  Why it's wrong here

  The health check is already receiving a 503 HTTP response, meaning the connection to the instance is established within the configured timeout and the server is actively responding. Increasing the interval or timeout would only affect situations where the health check times out due to network latency or resource exhaustion; it cannot change the HTTP status code returned by the application. A 503 is an explicit signal from the application that it is temporarily unable to handle the request, not that the load balancer gave up waiting. Tuning these timers would merely delay the detection of the underlying application problem, leaving the instance in an unhealthy state longer.

• ✗

  Check the security group rules for the target group to ensure port 80 is open

  Why it's wrong here

  A 503 response proves that the instance is reachable and that the security group and network path allow HTTP traffic on port 80; otherwise the health check would receive a connection timeout or an 'unavailable' error rather than an HTTP response. Security group rules control whether packets are allowed to reach the instance, but they do not influence what status code the application returns after accepting the connection. If the security group were blocking port 80, the health check would fail with a timeout or connection refused, not a 503 Service Unavailable. Therefore checking security groups is unnecessary in this scenario and would not address the root cause, which lies in the application's response to the '/' path.

Go deeper

Related to this question