Google ACE Practice Question: A company recently deployed a web application on…

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 instances are overloaded and failing health checks intermittently.

  Why it's wrong here

  Overloaded instances usually exhibit broad performance degradation: user requests time out or return 5xx errors, not just health-check probes. If CPU or memory were saturated, the load balancer would also report elevated error rates for real traffic, whereas the symptoms here are specifically false negative health checks after a code update. Additionally, the health check's 1-second timeout is the direct trigger—overload alone would not explain why a response arriving at 1.5 seconds is classified as failed.

• ✓

  The health check response timeout is too low for the application's increased response time.

  Why this is correct

  A managed instance group health check has a configurable timeout that defines how long the probe waits for a response before marking the instance unhealthy. After the change, the application's /health endpoint consistently returns 200 but only after ~1.5 seconds, which exceeds the 1-second timeout. This creates false negatives: the instance is healthy, but the probe gives up too early and the instance is removed from load balancing. Increasing the timeout (or reducing endpoint latency) resolves the issue.

• ✗

  The health check firewall rule is missing or misconfigured.

  Why it's wrong here

  Health check probes come from Google's well-known ranges such as 35.191.0.0/16 and 130.211.0.0/16, so a missing firewall rule would block all probes and make the instance unhealthy from the very beginning, regardless of code changes. A misconfigured firewall also typically causes connection timeouts or resets rather than a 200 response that arrives after the timeout threshold. Since the issue appeared only after the deployment and the /health endpoint returns 200, a firewall problem is not the root cause.

• ✗

  The health check is checking the wrong port.

  Why it's wrong here

  A wrong port setting would cause the health check to attempt a TCP connection or HTTP request to a port the application doesn't listen on, producing immediate connection refused or timeout errors on every probe. This failure mode would be present before and after the code deployment, and it would not depend on the application's response time. Because the /health endpoint returns 200 on the configured port, the port number is correct and this option cannot explain the post-update behavior.

Go deeper

Related to this question