Probes are tested on every CKAD exam, and they’re a domain where small details cost real points. The exam doesn’t just ask you to add a probe — it asks for the right kind of probe with the right timing and the right action. Pick the wrong probe type or set initialDelaySeconds too low and you’ll have a pod that crashes itself in a loop.
This guide covers every probe variant the CKAD tests, with copy-paste YAML, when to use each kind, and how to debug a probe that isn’t behaving as expected.
The Three Probe Types and What Each One Does
Kubernetes supports three probe types, each with a distinct job:
| Probe | What it controls | What happens on failure |
|---|---|---|
| Liveness | Is the container alive and able to make progress? | Container is killed and restarted |
| Readiness | Is the container ready to serve traffic? | Pod is removed from service endpoints |
| Startup | Is the container finished starting up? | Treated like liveness; protects slow-starting apps |
The exam tests all three. Mixing them up costs points — a readiness failure shouldn’t restart the container; a liveness failure should.
When to Use Each Probe
Liveness
Use when the app can hang or deadlock and the only fix is a restart. Watch for question phrases:
- “the app sometimes hangs and needs to be restarted”
- “if the app is unresponsive for X seconds, restart it”
- “detect a deadlocked container”
Readiness
Use when the app needs time to warm up before serving traffic, or when it depends on external services that may be temporarily unavailable. Watch for:
- “the app should not receive traffic until it’s connected to the database”
- “remove the pod from the service when it can’t process requests”
- “the app loads a large cache before it can serve requests”
Startup
Use for slow-starting apps that would otherwise fail liveness during boot. Watch for:
- “the app takes 5 minutes to initialize”
- “prevent liveness from killing the app during startup”
- “the existing liveness probe restarts the app before it finishes loading”
The startup probe runs first and disables liveness/readiness until it passes. Once it passes, liveness and readiness take over.
Probe Action Types: HTTP, TCP, Exec, gRPC
Each probe must have an action — what Kubernetes runs to check health. The CKAD tests four:
HTTP GET
livenessProbe:
httpGet:
path: /healthz
port: 8080
scheme: HTTP
initialDelaySeconds: 5
periodSeconds: 10Probe passes if the HTTP response is 200-399. Use for HTTP-serving apps. Most common probe action on the exam.
TCP Socket
readinessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 10
periodSeconds: 5Probe passes if the TCP connection succeeds. Use for non-HTTP services (databases, message queues).
Exec
livenessProbe:
exec:
command: ["cat", "/tmp/healthy"]
initialDelaySeconds: 5
periodSeconds: 10Probe passes if the command exits with code 0. Use when the app uses a heartbeat file, or when you need custom health logic.
gRPC (Newer, Less Common)
livenessProbe:
grpc:
port: 9000
service: "myservice"
periodSeconds: 10Probe passes if the gRPC health check returns SERVING. Use for gRPC services. The CKAD has started including this in 2025/2026.
The Timing Fields You Must Know
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5 # wait this long before first probe
periodSeconds: 10 # how often to probe (default 10)
timeoutSeconds: 1 # how long to wait for response (default 1)
failureThreshold: 3 # how many failures before action (default 3)
successThreshold: 1 # consecutive successes to pass (default 1, must be 1 for liveness/startup)Choosing Initial Delay
initialDelaySeconds must exceed the app’s typical startup time. If your app takes 10 seconds to start and you set initialDelaySeconds: 3, the probe will fail and the app will be killed before it’s ready. Common safe defaults:
- Simple web apps: 5-10 seconds
- Apps with DB connections: 15-30 seconds
- Java apps: 30-60 seconds
When to Use a Startup Probe Instead of a Long Initial Delay
If your app takes 5+ minutes to start, don’t use a 300-second initialDelaySeconds on liveness — use a startup probe with a generous failureThreshold:
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30 # 30 failures × 10s period = 5 minutes
periodSeconds: 10The startup probe blocks liveness until it passes. Once it passes, liveness takes over with normal timing.
Complete Pod with All Three Probes
This is what an exam-quality pod with all probes looks like:
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: web
image: nginx
ports:
- containerPort: 80
startupProbe:
httpGet:
path: /healthz
port: 80
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 3
periodSeconds: 5Notice that liveness and readiness use different paths (/healthz vs /ready). This is intentional — readiness should fail when the app is up but unable to serve (e.g., DB not connected); liveness should only fail when the app is genuinely broken.
How to Build Probes Quickly on the Exam
There’s no clean imperative shortcut. Generate a base pod with --dry-run and add the probe in vim:
k run web --image=nginx --port=80 $do > pod.yaml
vim pod.yamlThen add the probe block under the container. Memorize the YAML shape — you’ll write it from memory under time pressure.
Adding Probes to Existing Resources
The CKAD often asks you to add probes to an already-running deployment, not create a new one.
# Edit in place
kubectl edit deploy web
# Or apply a YAML patch
kubectl patch deploy web --patch '
spec:
template:
spec:
containers:
- name: web
livenessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 10
'After editing, watch the rollout:
kubectl rollout status deploy web
kubectl get pods -wVerifying That Probes Are Working
# Confirm the probe is configured
kubectl describe pod <pod> | grep -A 5 "Liveness\|Readiness\|Startup"
# Watch pod restarts (liveness failures)
kubectl get pod <pod> -w
# RESTARTS column increments on liveness failure
# Watch readiness (READY column)
kubectl get pod <pod> -w
# READY 0/1 means readiness is failing
# Inspect Events
kubectl describe pod <pod>
# Look for "Liveness probe failed" or "Readiness probe failed"If a probe fails repeatedly, the Events section explicitly says why — wrong path, connection refused, timeout.
Common Probe Question Variants
Variant 1: Add a Liveness Probe to an Existing Deployment
“Add a liveness probe to deployment
webthat hits/healthzon port 80 every 10 seconds, with an initial delay of 5 seconds.”
kubectl edit deploy webAdd under the container:
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10Variant 2: Combine Readiness and Liveness for a DB-Backed App
“Pod
apiconnects to a database. The pod should be removed from service when the DB is unavailable, but should not be restarted unless the API process itself crashes.”
The key insight: readiness for DB connectivity, liveness for process health.
livenessProbe:
httpGet:
path: /alive # responds 200 as long as the process is up
port: 8080
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready # returns 503 when DB is unreachable
port: 8080
periodSeconds: 5Variant 3: Use Exec Probe for a File Heartbeat
“Pod
workerwrites a heartbeat file at/tmp/healthyevery 5 seconds. Add a liveness probe that restarts the container if the file is missing for more than 30 seconds.”
livenessProbe:
exec:
command: ["test", "-f", "/tmp/healthy"]
periodSeconds: 10
failureThreshold: 3 # 3 × 10s = 30sVariant 4: Startup Probe for a Slow App
“App takes up to 4 minutes to fully initialize. Existing liveness probe restarts it during startup. Add a startup probe to prevent this.”
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 24 # 24 × 10s = 4 minutes
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 10Probe Anti-Patterns (the Exam Tests These)
Anti-Pattern 1: Same Endpoint for Liveness and Readiness Without Distinct Logic
If both probes hit /healthz and the app returns 503 when the DB is down, liveness will trigger a restart — but a restart won’t reconnect to the DB any faster. Use a separate path for liveness that only checks the process, not its dependencies.
Anti-Pattern 2: Aggressive Liveness on a Slow App
A 30-second initialDelaySeconds and periodSeconds: 5 may seem reasonable, but for a Java app that takes 60 seconds to warm up, it’ll restart the pod twice during boot. Use a startup probe instead.
Anti-Pattern 3: Exec Probe Doing Heavy Work
Probes run frequently. An exec probe that runs curl against an external service every 10 seconds adds load. Keep probes lightweight — cat, test -f, simple HTTP checks.
Anti-Pattern 4: Wrong Port Number
Probes hit the container port, not the service port. If the container listens on 8080 but you set port: 80, the probe will fail with “connection refused.”
Debugging a Probe That’s Failing
# 1. Confirm the probe is configured the way you expect
kubectl describe pod <pod> | grep -A 5 Liveness
kubectl describe pod <pod> | grep -A 5 Readiness
# 2. Check Events for the actual failure reason
kubectl describe pod <pod> | grep -A 5 Events
# Look for "Liveness probe failed: HTTP probe failed with statuscode: 404"
# 3. Test the probe endpoint manually from inside the pod
kubectl exec -it <pod> -- wget -O- http://localhost:8080/healthz
# Or:
kubectl exec -it <pod> -- nc -zv localhost 8080
# 4. Watch live restarts
kubectl get pod <pod> -wThe most common failure modes:
- Wrong path → 404 in Events
- Wrong port → “connection refused” or “no route to host”
- App slow to start → “failed to connect” only on initial probes
- App responding 5xx → wrong handler or app error; check
kubectl logs
For broader application debugging, see our CKAD application troubleshooting guide.
How to Practice Probes
Build a pod with a slow-starting test app on a kind cluster. Drill these scenarios:
- Add a basic HTTP liveness probe; trigger a failure by changing the path to one that doesn’t exist; observe the restart.
- Add a TCP readiness probe; block the port temporarily and watch READY flip to 0/1.
- Add an exec probe with a heartbeat file; remove the file and watch the restart.
- Add a startup probe with a tight failureThreshold and watch it kill a slow-starting app.
- Combine all three probes on one pod and verify they coexist.
If you can build any of those in under 4 minutes from a blank pod spec, this domain won’t slow you down on exam day.
Validate Your Probe Speed Under Exam Conditions
The CKAD tests probes inside larger questions where you must also build the deployment, expose a service, and verify the result. Take a full-length scored simulator with our CKAD Mock Exam Bundle — every simulator includes probe questions in realistic context with the same UI as the real exam.
Frequently Asked Questions
Q: How many probe questions are on the CKAD? A: Typically 2-4 questions. Probes also appear inside other questions (deployments, multi-container pods). Total weight: ~10-15%.
Q: What’s the difference between liveness and readiness in one sentence? A: Liveness restarts the container; readiness removes it from service endpoints.
Q: Do I need to know gRPC probes? A: It’s listed in the curriculum as of 2026. Recognize the YAML shape; you may not be tested on it directly.
Q: Can a pod have liveness without readiness? A: Yes. Without a readiness probe, the pod is considered ready as soon as the container is running. Most production deployments use both.
Q: What’s the maximum failureThreshold? A: There’s no hard limit, but practical use is 1-30. For very slow apps, use a startup probe instead of pushing failureThreshold past ~30 on liveness.
Q: Why does my pod stay 0/1 forever?
A: Readiness is failing. Run kubectl describe pod <pod> and read the Events section. Most often: wrong path, wrong port, or the app isn’t actually ready.
Q: Can I use the same path for liveness and readiness? A: You can, but it’s an anti-pattern. They have different jobs and should usually have different paths.
Ready to make probes automatic points on your CKAD? Run a scored full-length simulator with our CKAD Mock Exam Bundle and find out exactly where you stand.