Health checks configuration in GCP - Commands & Configuration

Introduction

Health checks help Google Cloud know if your app or service is working well. They check your app regularly and tell Google Cloud if it needs to restart or stop sending traffic to a broken app.

When you want to make sure your app is ready before sending users to it.

When you want to automatically restart an app that stops working.

When you want to balance traffic only to healthy app instances.

When you want to monitor the health of your backend services.

When you want to avoid downtime by detecting problems early.

Config File - health-check.yaml

health-check.yaml

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeHealthCheck
metadata:
  name: example-health-check
spec:
  checkIntervalSec: 10
  timeoutSec: 5
  healthyThreshold: 3
  unhealthyThreshold: 3
  httpHealthCheck:
    port: 8080
    requestPath: /health
  type: HTTP

This file creates a health check resource in Google Cloud.

checkIntervalSec sets how often Google Cloud checks your app.

timeoutSec is how long it waits for a response.

healthyThreshold is how many successful checks in a row make the app healthy.

unhealthyThreshold is how many failed checks in a row make the app unhealthy.

httpHealthCheck defines the port and path to check your app's health.

type is the protocol used for the check.

Commands

This command creates the health check in Google Cloud using the configuration file.

Terminal

gcloud deployment-manager deployments create example-health-check --config health-check.yaml

Expected Output

Waiting for create [operations/operation-1234567890abcdef]...done.

Create operation operation-1234567890abcdef completed successfully.

→

--config - Specifies the configuration file to use for deployment.

This command shows the details of the health check to verify it was created correctly.

Terminal

gcloud compute health-checks describe example-health-check

Expected Output

checkIntervalSec: 10

timeoutSec: 5

healthyThreshold: 3

unhealthyThreshold: 3

httpHealthCheck:

  port: 8080

  requestPath: /health

type: HTTP

name: example-health-check

This command attaches the health check to a backend service so Google Cloud can monitor its health.

Terminal

gcloud compute backend-services update example-backend-service --health-checks example-health-check --global

Expected Output

Updated [https://www.googleapis.com/compute/v1/projects/my-project/global/backendServices/example-backend-service].

→

--health-checks - Specifies which health check to attach.

→

--global - Indicates the backend service is global.

This command checks the current health status of the backend service using the attached health check.

Terminal

gcloud compute backend-services get-health example-backend-service --global

Expected Output

healthStatus:

- healthState: HEALTHY

  instance: https://www.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/instances/example-instance

  ipAddress: 10.128.0.2

  port: 8080

→

--global - Indicates the backend service is global.

Key Concept

If you remember nothing else from this pattern, remember: health checks tell Google Cloud if your app is working so it can manage traffic and restarts automatically.

Common Mistakes

Setting the health check path to a URL that does not return success.

Google Cloud will mark the app as unhealthy and stop sending traffic to it.

Make sure the path used in the health check returns a simple success response like HTTP 200.

Using too short timeout or check intervals.

This can cause false failures if the app is slow to respond occasionally.

Set reasonable timeout and interval values that match your app's response times.

Not attaching the health check to the backend service.

Google Cloud will not monitor the service health and may send traffic to broken instances.

Always update your backend service to use the health check after creating it.

Summary

Create a health check configuration file defining how Google Cloud checks your app's health.

Deploy the health check using gcloud deployment-manager.

Attach the health check to your backend service to monitor its health.

Use gcloud commands to verify the health check and backend service status.

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