HTTP probe configuration in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the result of this HTTP readiness probe configuration?

Given this Kubernetes pod snippet, what will be the HTTP probe's behavior when the container is starting?

Kubernetes

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

A The probe checks /healthz immediately on container start, then every 5 seconds; after 10 failures, it marks the pod as not ready.

B The probe waits 5 seconds before first check, then checks /healthz every 10 seconds; after 3 failures, it marks the pod as not ready.

C The probe waits 3 seconds before first check, then checks /healthz every 5 seconds; after 5 failures, it marks the pod as not ready.

D The probe waits 10 seconds before first check, then checks /healthz every 3 seconds; after 1 failure, it marks the pod as not ready.

💡 Hint

Look at initialDelaySeconds, periodSeconds, and failureThreshold values carefully.

initialDelaySeconds sets the wait before first probe; periodSeconds sets interval between probes; failureThreshold is how many failures before marking not ready.

❓ Configuration

intermediate

Identify the correct HTTP liveness probe configuration for port 80 and path /status

Which option correctly configures a liveness probe that checks HTTP path /status on port 80 every 15 seconds with a timeout of 5 seconds?

A

livenessProbe:
  httpGet:
    path: /status
    port: 80
  periodSeconds: 15
  timeoutSeconds: 5

B

livenessProbe:
  httpGet:
    path: /status
    port: 8080
  periodSeconds: 15
  timeoutSeconds: 5

C

livenessProbe:
  httpGet:
    path: /health
    port: 80
  periodSeconds: 10
  timeoutSeconds: 5

D

livenessProbe:
  tcpSocket:
    port: 80
  periodSeconds: 15
  timeoutSeconds: 5

💡 Hint

Check the port number and path carefully; also probe type must be HTTP.

Option A matches the required path /status, port 80, period 15s, and timeout 5s using httpGet.

❓ Troubleshoot

advanced

Why does this HTTP readiness probe always fail?

A pod has this readiness probe: readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5 failureThreshold: 1 The container starts but the pod never becomes ready. What is the most likely cause?

A The /ready endpoint is not responding with HTTP 200 status code, causing probe failures.

B The failureThreshold is too high, so the pod never marks ready.

C The initialDelaySeconds is too short, so the probe runs before container starts.

D The port 8080 is incorrect; readiness probes do not support ports above 8000.

💡 Hint

Check what the probe expects from the HTTP endpoint.

Readiness probes expect HTTP 200 response; if /ready returns other status, probe fails and pod stays not ready.

🔀 Workflow

advanced

Order the steps to add an HTTP liveness probe to a Kubernetes deployment

Put these steps in the correct order to add an HTTP liveness probe to a deployment YAML:

A 3,1,2,4

B 2,1,3,4

C 1,3,2,4

D 1,2,3,4

💡 Hint

Think about editing first, then applying, then verifying.

First edit YAML, then apply changes, then verify pod status, finally check logs for restarts.

✅ Best Practice

expert

Which HTTP probe configuration best balances fast failure detection and avoiding false positives?

Choose the HTTP liveness probe configuration that best balances detecting real failures quickly without causing unnecessary container restarts.

A initialDelaySeconds: 0, periodSeconds: 2, failureThreshold: 5, timeoutSeconds: 10

B initialDelaySeconds: 5, periodSeconds: 5, failureThreshold: 1, timeoutSeconds: 1

C initialDelaySeconds: 30, periodSeconds: 10, failureThreshold: 3, timeoutSeconds: 5

D initialDelaySeconds: 60, periodSeconds: 60, failureThreshold: 1, timeoutSeconds: 1

💡 Hint

Consider initial delay, probe frequency, failure tolerance, and timeout together.

Option C waits enough before probing, checks regularly, allows some failures, and has reasonable timeout to avoid false positives.

Practice

1. What is the main purpose of an HTTP probe in Kubernetes?

easy

A. To deploy new versions of the application automatically

B. To store application logs for debugging

C. To check if the application is running and responding to HTTP requests

D. To manage network traffic between pods

Solution

1. Step 1: Understand the role of HTTP probes

   HTTP probes send HTTP requests to the app to check if it is alive and ready.

2. Step 2: Identify the correct purpose

   Only To check if the application is running and responding to HTTP requests describes checking app health via HTTP requests.

3. Final Answer:

   To check if the application is running and responding to HTTP requests -> Option C

4. Quick Check:

   HTTP probe purpose = health check [OK]

Hint: HTTP probes test app health by sending HTTP requests [OK]

Common Mistakes:

• Confusing probes with deployment or logging
• Thinking probes manage network traffic
• Assuming probes store logs

2. Which of the following is the correct syntax to define an HTTP liveness probe in a Kubernetes pod spec?

easy

A. livenessProbe:
exec:
command: ["curl", "/healthz"]
initialDelaySeconds: 5
periodSeconds: 10

B. livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

C. livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

D. livenessProbe:
httpGet:
url: http://localhost:8080/healthz
initialDelaySeconds: 5
periodSeconds: 10

Solution

1. Step 1: Review HTTP probe syntax

   The correct HTTP probe uses httpGet with path and port keys.

2. Step 2: Identify the correct YAML structure

   livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 correctly uses httpGet with path and port. livenessProbe: httpGet: url: http://localhost:8080/healthz initialDelaySeconds: 5 periodSeconds: 10 is invalid because url is not a valid key.

3. Final Answer:

   Correct HTTP liveness probe syntax with httpGet, path, and port -> Option B

4. Quick Check:

   httpGet uses path and port keys [OK]

Hint: Use httpGet with path and port, not url [OK]

Common Mistakes:

• Using 'url' instead of 'path' in httpGet
• Confusing exec or tcpSocket probes with httpGet
• Wrong indentation or missing keys

3. Given this probe configuration snippet in a pod spec:

livenessProbe:
  httpGet:
    path: /status
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

What will Kubernetes do after the pod starts?

medium

A. Send an HTTP GET to /status only once after 10 seconds

B. Send an HTTP GET to /status immediately, then every 10 seconds

C. Wait 5 seconds, then send an HTTP GET to /status every 10 seconds

D. Wait 10 seconds, then send an HTTP GET to /status every 5 seconds

Solution

1. Step 1: Understand initialDelaySeconds

   This value tells Kubernetes to wait 10 seconds after pod start before first probe.

2. Step 2: Understand periodSeconds

   This value sets the interval between probes, here every 5 seconds.

3. Final Answer:

   Wait 10 seconds, then send an HTTP GET to /status every 5 seconds -> Option D

4. Quick Check:

   initialDelaySeconds = wait, periodSeconds = repeat interval [OK]

Hint: initialDelaySeconds = wait before first probe, periodSeconds = probe interval [OK]

Common Mistakes:

• Confusing initialDelaySeconds with periodSeconds
• Assuming immediate probe on pod start
• Mixing up timing values

4. You configured this HTTP readiness probe:

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 2

But Kubernetes marks the pod as not ready even though the app is healthy. What is the likely problem?

medium

A. The probe path /ready is incorrect or not handled by the app

B. initialDelaySeconds is too high, delaying readiness

C. timeoutSeconds is too long, causing probe to fail

D. periodSeconds is too short, causing probe overload

Solution

1. Step 1: Check probe path correctness

   If the app does not respond correctly to /ready, probe fails and pod is not ready.

2. Step 2: Evaluate timing parameters

   initialDelaySeconds of 5 is reasonable; timeoutSeconds of 2 is short but typical; periodSeconds of 10 is normal.

3. Final Answer:

   The probe path /ready is incorrect or not handled by the app -> Option A

4. Quick Check:

   Probe path must match app endpoint [OK]

Hint: Check if probe path matches app endpoint exactly [OK]

Common Mistakes:

• Ignoring probe path correctness
• Changing timing values unnecessarily
• Assuming timeoutSeconds causes readiness failure

5. You want to configure a Kubernetes HTTP readiness probe that waits 15 seconds after container start, then checks the path /health every 3 seconds, but fails the pod if no response within 1 second. Which is the correct probe configuration snippet?

hard

A. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 3
timeoutSeconds: 1

B. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 3
periodSeconds: 15
timeoutSeconds: 1

C. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 1
timeoutSeconds: 3

D. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 1
periodSeconds: 15
timeoutSeconds: 3

Solution

1. Step 1: Match initialDelaySeconds to 15 seconds

   The probe must wait 15 seconds before first check, so initialDelaySeconds: 15.

2. Step 2: Set periodSeconds to 3 seconds and timeoutSeconds to 1 second

   Checks happen every 3 seconds, and timeout is 1 second as required.

3. Final Answer:

   Correct probe with initialDelaySeconds 15, periodSeconds 3, timeoutSeconds 1 -> Option A

4. Quick Check:

   initialDelay=15, period=3, timeout=1 matches requirements [OK]

Hint: Match timing values exactly to requirements [OK]

Common Mistakes:

• Swapping initialDelaySeconds and periodSeconds
• Setting timeoutSeconds longer than periodSeconds
• Using wrong path or port