Health checks configuration in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding HTTP Health Check Behavior

You configure an HTTP health check for a Google Cloud Load Balancer with the following settings:

• Request path: /status
• Port: 8080
• Check interval: 10 seconds
• Timeout: 5 seconds
• Unhealthy threshold: 3
• Healthy threshold: 2

If your backend service responds with HTTP 200 to /status for 1 check, then returns HTTP 500 for the next 3 checks, what will be the health status of the backend after these 4 checks?

A The backend becomes unhealthy after 3 consecutive unhealthy responses.

B The backend remains healthy because only 1 unhealthy response occurred.

C The backend becomes unhealthy immediately after the first unhealthy response.

D The backend status is unknown because the healthy threshold is 2.

💡 Hint

Consider how the unhealthy threshold affects status changes.

The backend must fail 3 consecutive health checks to be marked unhealthy. After 1 healthy and then 3 unhealthy responses, the backend becomes unhealthy.

❓ Configuration

intermediate

Configuring a TCP Health Check in GCP

You want to create a TCP health check for a backend service that listens on port 3306. Which of the following YAML snippets correctly defines this health check in a Deployment Manager template?

A

type: compute.v1.healthCheck
properties:
  name: tcp-health-check
  tcpHealthCheck:
    port: "3306"
  checkIntervalSec: 10
  timeoutSec: 5
  unhealthyThreshold: 3
  healthyThreshold: 2

B

type: compute.v1.healthCheck
properties:
  name: tcp-health-check
  httpHealthCheck:
    port: 3306
  checkIntervalSec: 10
  timeoutSec: 5
  unhealthyThreshold: 3
  healthyThreshold: 2

C

type: compute.v1.healthCheck
properties:
  name: tcp-health-check
  tcpHealthCheck:
    port: 3306
  checkIntervalSec: 10
  timeoutSec: 5
  unhealthyThreshold: 3
  healthyThreshold: 2

D

type: compute.v1.healthCheck
properties:
  name: tcp-health-check
  tcpHealthCheck:
    port: 3306
  checkIntervalSec: "10"
  timeoutSec: 5
  unhealthyThreshold: 3
  healthyThreshold: 2

💡 Hint

Check the correct health check type and data types for port and intervals.

The TCP health check must use tcpHealthCheck with port as an integer. The check interval and timeout must also be integers, not strings.

❓ Architecture

advanced

Designing Health Checks for Multi-Region Backends

You have a multi-region backend service deployed in two Google Cloud regions. You want to ensure that the load balancer only sends traffic to healthy backends in each region. Which health check design best supports this goal?

A Create separate health checks for each region's backend with region-specific settings.

B Disable health checks and rely on backend logs to detect failures.

C Use a single global health check shared by all backends in both regions.

D Use a single health check but configure it to check multiple ports on all backends.

💡 Hint

Think about how health checks can reflect regional backend health independently.

Separate health checks per region allow the load balancer to detect and route traffic only to healthy backends in each region, improving reliability and performance.

❓ security

advanced

Securing Health Check Endpoints

Your backend service exposes an HTTP health check endpoint at /health. To improve security, you want to restrict access so only Google Cloud health check probes can reach it. Which approach is best?

A Disable health checks and rely on backend logs for health monitoring.

B Configure firewall rules to allow traffic to <code>/health</code> only from Google Cloud health check IP ranges.

C Require a username and password on the <code>/health</code> endpoint for all requests.

D Make the <code>/health</code> endpoint publicly accessible without restrictions.

💡 Hint

Consider how to limit network access to trusted sources.

Google publishes IP ranges for health check probes. Restricting access by firewall rules to these IPs protects the health check endpoint from unauthorized access.

✅ Best Practice

expert

Optimizing Health Check Configuration for Cost and Performance

You manage a backend service with many instances behind a Google Cloud Load Balancer. You want to optimize health check settings to reduce cost and avoid false positives without sacrificing reliability. Which combination of settings is best?

A Set check interval to 1 second, timeout to 1 second, unhealthy threshold to 1, healthy threshold to 1.

B Set check interval to 5 seconds, timeout to 1 second, unhealthy threshold to 1, healthy threshold to 1.

C Set check interval to 10 seconds, timeout to 10 seconds, unhealthy threshold to 3, healthy threshold to 3.

D Set check interval to 30 seconds, timeout to 5 seconds, unhealthy threshold to 5, healthy threshold to 2.

💡 Hint

Balance frequency and thresholds to reduce load and avoid flapping.

Longer intervals and higher thresholds reduce health check traffic and avoid marking backends unhealthy due to transient issues, balancing cost and reliability.

Practice

1.

What is the main purpose of a health check in Google Cloud Platform?

easy

A. To increase server storage capacity

B. To monitor if servers are working properly

C. To speed up network traffic

D. To backup data automatically

Solution

1. Step 1: Understand health check function

   Health checks regularly test if servers respond correctly to requests.

2. Step 2: Identify main purpose

   This helps detect unhealthy servers so they can be fixed or replaced.

3. Final Answer:

   To monitor if servers are working properly -> Option B

4. Quick Check:

   Health check = Monitor server health [OK]

Hint: Health checks watch server health, not storage or speed [OK]

Common Mistakes:

• Confusing health checks with backups
• Thinking health checks increase speed
• Assuming health checks add storage

2.

Which of the following is the correct way to specify a TCP health check in a Google Cloud load balancer configuration?

{
  "type": "TCP",
  "port": 80,
  "checkIntervalSec": 5
}

easy

A. { "type": "TCP", "port": 80, "checkIntervalSec": 5 }

B. { "type": "HTTP", "port": 80, "checkIntervalSec": 5 }

C. { "type": "UDP", "port": 80, "checkIntervalSec": 5 }

D. { "type": "ICMP", "port": 80, "checkIntervalSec": 5 }

Solution

1. Step 1: Identify correct health check type

   TCP health checks use "type": "TCP" to test TCP connections on the port.

2. Step 2: Match correct JSON syntax

   The example matches the correct syntax with type TCP, port 80, and interval 5 seconds.

3. Final Answer:

   { "type": "TCP", "port": 80, "checkIntervalSec": 5 } -> Option A

4. Quick Check:

   TCP type with port 80 = { "type": "TCP", "port": 80, "checkIntervalSec": 5 } [OK]

Hint: TCP health check uses type "TCP" exactly [OK]

Common Mistakes:

• Using HTTP instead of TCP for TCP check
• Using unsupported types like UDP or ICMP
• Wrong JSON syntax or missing fields

3.

Given this health check configuration snippet, what will happen if the server does not respond within 10 seconds?

{
  "type": "HTTP",
  "port": 8080,
  "timeoutSec": 10,
  "unhealthyThreshold": 3
}

medium

A. The server is marked unhealthy after 3 failed checks

B. The server is immediately removed after 1 failed check

C. The server is marked healthy regardless of response time

D. The server is restarted after 10 seconds

Solution

1. Step 1: Understand timeout and threshold

   The timeoutSec of 10 means the check waits 10 seconds for a response before failing.

2. Step 2: Apply unhealthyThreshold logic

   The server must fail 3 consecutive checks to be marked unhealthy.

3. Final Answer:

   The server is marked unhealthy after 3 failed checks -> Option A

4. Quick Check:

   Timeout + 3 failures = unhealthy after 3 tries [OK]

Hint: Unhealthy threshold counts failures before marking unhealthy [OK]

Common Mistakes:

• Thinking server is removed immediately after 1 failure
• Ignoring unhealthyThreshold setting
• Assuming server restarts automatically

4.

Identify the error in this health check configuration snippet:

{
  "type": "HTTP",
  "port": "eighty",
  "requestPath": "/health",
  "checkIntervalSec": 5
}

medium

A. checkIntervalSec must be at least 10 seconds

B. requestPath cannot be used with HTTP type

C. Port must be a number, not a string

D. type "HTTP" is invalid

Solution

1. Step 1: Check port field type

   The port value is "eighty" as a string, but it must be a numeric value like 80.

2. Step 2: Validate other fields

   requestPath is valid for HTTP, checkIntervalSec can be 5, and type "HTTP" is correct.

3. Final Answer:

   Port must be a number, not a string -> Option C

4. Quick Check:

   Port number must be numeric [OK]

Hint: Port must be a number, not words [OK]

Common Mistakes:

• Using string instead of number for port
• Thinking requestPath is invalid for HTTP
• Assuming checkIntervalSec minimum is 10

5.

You want to configure a health check that verifies your web app responds with HTTP 200 on path /status every 15 seconds, and marks the server unhealthy after 2 failures. Which configuration is correct?

hard

A. { "type": "HTTP", "port": 8080, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 }

B. { "type": "TCP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 }

C. { "type": "HTTP", "port": 80, "requestPath": "/health", "checkIntervalSec": 10, "unhealthyThreshold": 3 }

D. { "type": "HTTP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 }

Solution

1. Step 1: Match health check type and path

   The app uses HTTP checks on path "/status" so type must be "HTTP" and requestPath "/status".

2. Step 2: Verify timing and thresholds

   Check interval is 15 seconds and unhealthyThreshold is 2, matching requirements.

3. Step 3: Confirm port number

   Port 80 is standard for HTTP, so it fits the web app default.

4. Final Answer:

   { "type": "HTTP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 } -> Option D

5. Quick Check:

   HTTP + /status + 15s + 2 failures = { "type": "HTTP", "port": 80, "requestPath": "/status", "checkIntervalSec": 15, "unhealthyThreshold": 2 } [OK]

Hint: Match type, path, interval, and threshold exactly [OK]

Common Mistakes:

• Using TCP type for HTTP path
• Wrong requestPath or port
• Incorrect checkIntervalSec or unhealthyThreshold