Bird
Raised Fist0
GCPcloud~30 mins

Health checks configuration in GCP - Mini Project: Build & Apply

Choose your learning style10 modes available
Health checks configuration
📖 Scenario: You are setting up a Google Cloud Platform (GCP) load balancer to distribute traffic to your web servers. To ensure traffic is only sent to healthy servers, you need to configure health checks that monitor the servers' status.
🎯 Goal: Build a health check configuration in GCP that checks the health of backend instances by sending HTTP requests to a specific path and port.
📋 What You'll Learn
Create a health check resource with a specific name
Set the health check to use HTTP protocol
Configure the health check to check a specific port and request path
Set the check interval and timeout values
💡 Why This Matters
🌍 Real World
Health checks are essential to ensure that load balancers only send traffic to servers that are working properly, improving reliability and user experience.
💼 Career
Cloud engineers and DevOps professionals regularly configure health checks to maintain high availability and fault tolerance in cloud infrastructure.
Progress0 / 4 steps
1
Create the initial health check resource dictionary
Create a dictionary called health_check with the key name set to "my-health-check".
GCP
Hint

Use a Python dictionary with the key name and value "my-health-check".

2
Add protocol and port configuration
Add the keys type with value "HTTP" and port with value 80 to the health_check dictionary.
GCP
Hint

Add "type": "HTTP" and "port": 80 inside the dictionary.

3
Add request path and timing settings
Add the keys requestPath with value "/health", checkIntervalSec with value 5, and timeoutSec with value 3 to the health_check dictionary.
GCP
Hint

Add the keys for the request path and timing inside the dictionary.

4
Complete the health check configuration
Add the key unhealthyThreshold with value 2 and healthyThreshold with value 3 to the health_check dictionary to complete the configuration.
GCP
Hint

Set the thresholds for healthy and unhealthy checks.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard