1Z0-1067-25 Question 133
Single answerYou manage an e-commerce application behind an Oracle Cloud Infrastructure (OCI) Load Balancer. The application provides a /store/health endpoint that returns a 200 status code when the application is healthy and a 500 status code when critical dependencies fail. However, you notice the load balancer� default health check still marks the backend as healthy even when /store/health returns 500. Which action should you take to ensure the load balancer correctly removes unhealthy backend servers from rotation?
- A
Configure an HTTP health check referencing /store/health, restricting health check success to 2xx response codes only.
- B
Switch to a TCP-based health check on the default port to detect any TCP failures.
- C
Increase the load balancer listener� idle timeout to allow the health check more time to detect failure.
- D
Configure a custom SSL certificate for SSL termination to generate accurate health check results.
Show answer and explanation
Correct answer: A
Explanation
OCI Load Balancers allow you to configure HTTP health checks that look for specific status codes and paths. When the backend returns a status code outside the configured success range, the load balancer marks the backend as unhealthy and removes it from rotation. By default, many health checks do not automatically check for a 500-coded response. For more details, refer to the Oracle documentation on Load Balancer health checks: https://docs.oracle.com/en-us/iaas/Content/Balance/Tasks/managinghealthchecks.htm.
- A. Correct.
Correct. By configuring an HTTP health check that points to /store/health and specifying valid response codes (e.g., 200�299), the load balancer knows to mark the backend healthy only if it receives a response in that range. A 500 response automatically indicates an unhealthy state.
- B. Incorrect.
Incorrect. A TCP-based health check only verifies that the TCP connection can be established; it does not check your application� HTTP response code. If your application still returns 500, the TCP health check could still mark it as �healthy� because it only checks connectivity, not HTTP content.
- C. Incorrect.
Incorrect. Increasing the idle timeout simply allows connections to remain open longer, which doesn�t address the core problem of identifying valid vs. invalid HTTP responses for health checking.
- D. Incorrect.
Incorrect. SSL termination (or providing a custom SSL certificate) is unrelated to how the load balancer interprets your application� HTTP status codes. It only secures the data in transit, but does not change the behavior of health checks.