1Z0-1067-25 Question 138
Single answerYou have deployed a microservice behind an OCI Load Balancer that exposes both a liveness endpoint (e.g., /health/live) and a readiness endpoint (e.g., /health/ready). The readiness endpoint returns HTTP 200 only when the service has completed initialization, and 503 if it is not ready. However, you notice the load balancer continues sending requests to instances that return 503. Which configuration change should you make so that the load balancer correctly marks unready instances as unhealthy?
- A
Configure an HTTP health check on the readiness endpoint, expecting a 200 response code before sending traffic to the backend.
- B
Enable the 'Accelerated Routing' feature on the load balancer so it immediately attempts to connect to another backend when it encounters a 503.
- C
Set the load balancer's health check to use the liveness endpoint only, because liveness checks are more reliable than readiness checks.
- D
Increase the overall connection timeout in the load balancer's backend set so that instances have more time to finish initialization.
Show answer and explanation
Correct answer: A
Explanation
In Oracle Cloud Infrastructure, health checks let you specify an endpoint path, protocol, and expected return code. A readiness endpoint (returning 503 if the service is not ready) helps ensure that only fully initialized instances receive traffic. For details, refer to the OCI documentation on Load Balancer health checks: https://docs.oracle.com/en-us/iaas/Content/Balance/Tasks/managingloadbalancerhealthcheck.htm
- A. Correct.
Correct. By configuring the load balancer to check the readiness endpoint with an expected 200 response, you ensure that only instances reporting readiness are marked healthy. This allows your service to finish initialization before receiving live traffic.
- B. Incorrect.
Incorrect. There is no 'Accelerated Routing' feature that bypasses health checks upon a status code like 503. This distractor plays on the misconception that you can automatically fail over instantly without appropriate health check configuration.
- C. Incorrect.
Incorrect. Relying solely on the liveness check can cause traffic to be routed to instances that are alive but not fully ready to handle requests. A dedicated readiness check is best practice when you have a multi-stage initialization process.
- D. Incorrect.
Incorrect. Increasing the connection timeout does not solve the underlying issue of sending traffic to an unready instance. The correct approach is to configure a proper health check on the readiness endpoint so that instances are marked unhealthy until they are fully initialized.