Courseiva

Google PCA Design and plan a cloud solution architecture Practice Question

A company has set up an external HTTP(S) load balancer with a backend service pointing to a managed instance group. Some instances are failing health checks. Which TWO actions should the company take to troubleshoot the issue?

⚠ Common exam trap

The trap here is that candidates often focus on load distribution or scaling solutions (options C and E) rather than the fundamental connectivity and application-level checks (options A and B) that directly determine health check success.

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

✓

Ensure the health check path specified in the backend service returns a 200 OK status.

Option A is correct because the health check probe only marks an instance healthy when the configured request path returns an HTTP 200 OK response; if the path returns 404, 500, or a redirect, the instance will be flagged unhealthy, so verifying the path is a primary troubleshooting step. Option B is correct because Google Cloud external HTTP(S) load balancer health checks originate from specific Google health check source IP ranges (e.g., 35.191.0.0/16 and 130.211.0.0/22), and firewall rules must permit ingress from these ranges to the instances on the health check port, otherwise probes are dropped and instances fail. Option C is not relevant because session affinity affects how client traffic is routed, not whether health check probes succeed. Option D is not a fix because lengthening the interval only delays detection and does not resolve the underlying cause of failed probes. Option E is not appropriate because adding instances does not correct failing health checks and may simply add more unhealthy instances.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Ensure the health check path specified in the backend service returns a 200 OK status.

    Why this is correct

    A failing health check often stems from the probe path returning a non-200 response, so verifying it returns 200 OK directly addresses the backend service's health check configuration. Google Cloud load balancer health checks mark instances unhealthy on any other status code, removing them from rotation, so confirming the path's response satisfies the stem's troubleshooting requirement.

  • ✓

    Verify that the firewall rules allow traffic from the load balancer health check IP ranges.

    Why this is correct

    Health checks originate from Google's fixed probe ranges (130.211.0.0/22 and 35.191.0.0/16), not from the load balancer's frontend address. If ingress firewall rules omit these source ranges, probes are dropped and instances report unhealthy despite serving traffic correctly. Verifying these rules directly addresses the stem's failing health checks.

  • ✗

    Disable session affinity to allow better distribution of traffic.

    Why it's wrong here

    Session affinity governs how the load balancer routes subsequent requests from a client, not whether health check probes succeed. Disabling it changes nothing about probe responses. Affinity is configured when sticky client sessions are required for stateful applications, which is unrelated to diagnosing failing health checks.

  • ✗

    Change the health check interval from 5 seconds to 30 seconds.

    Why it's wrong here

    Lengthening the health check interval only delays failure detection; it does not diagnose why instances fail probes. It is tempting to reduce false positives from transient blips, and it would be correct when probes time out under brief load spikes rather than a persistent configuration fault.

  • ✗

    Increase the number of instances in the instance group to distribute the load.

    Why it's wrong here

    Adding instances does not repair the health check configuration or application fault causing existing instances to fail; new instances would fail identically. Scaling out suits genuine capacity shortfalls under load, not troubleshooting probe failures, which require inspecting health check paths, firewall rules and backend logs.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

Courseiva writes every PCA question from scratch — 807 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This PCA 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 PCA exam.