mediumMultiple ChoiceObjective-mapped
Google ACE Practice Question: Refer to the exhibit
Exhibit
$ gcloud compute health-checks describe http-health-check healthCheckType: HTTP timeoutSec: 5 unhealthyThreshold: 2 healthyThreshold: 2 checkIntervalSec: 5 port: 80 requestPath: /healthz
Refer to the exhibit. You have set up an HTTP load balancer with this health check. Your backend instances are running a web server on port 80, and the /health endpoint returns 200 OK. However, the health check marks all instances as unhealthy. What is the most likely cause?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The requestPath is /healthz but the application does not have that endpoint
The health check is configured with requestPath /healthz, but the application only serves /health. This mismatch causes the health check to receive a non-200 response, marking instances unhealthy.
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 unhealthyThreshold is too low
Why it's wrong here
The unhealthyThreshold parameter controls how many consecutive health check failures must occur before the backend instance is marked unhealthy. A low value (like 2) would indeed cause the instance to be flagged quickly, but it does not change the fact that each probe to /healthz is returning a 404. Since the application has no /healthz endpoint, every check fails regardless of the threshold, so lowering the threshold is not the root cause; it merely accelerates the inevitable.
- ✗
The health check port is 80 but the web server is on port 80
Why it's wrong here
The health check port and the web server port both being 80 means that the TCP connection to the instance succeeds and the health check request is actually reaching the web server. If the port were mismatched, the probe would fail to connect, but here the absence of the /healthz route is what triggers the HTTP 404. Therefore, the port configuration is working as intended and cannot explain why the instance is continuously reported unhealthy.
- ✗
The checkIntervalSec is too high
Why it's wrong here
checkIntervalSec determines how frequently the health check probe is sent, not the outcome of the probe itself. Setting a high interval (for example, 60 seconds) would make the load balancer wait longer before updating the instance's health status, but because the /healthz path always returns 404, every individual probe still fails. A high interval would only delay the detection of an already-failing endpoint, so it is not the reason the instance is persistently unhealthy.
- ✓
The requestPath is /healthz but the application does not have that endpoint
Why this is correct
Google Cloud's HTTP health check issues a GET request to the exact requestPath configured, and the instance is considered healthy only if it responds with a 2xx or 3xx status code. Since this application does not expose a /healthz endpoint, the server returns a 404 Not Found, which the health checker treats as a failure. To fix this, the application should serve a 200 OK at /healthz, or the requestPath should be changed to match an existing endpoint, such as / or /index.html.
Go deeper
Related to this question
About these practice questions
This ACE question is part of Courseiva's 769-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.