Study Hub / Certified Kubernetes Application Developer (CKAD) / Domain 3.0
Certified Kubernetes Application Developer (CKAD) Domain 3.0: Application Observability & Maintenance — Explained
Domain 3.0 is about knowing what your app is doing once it's running: the probes that report health, the logs that tell stories, the metrics that trigger alerts, and the debugging workflow when it all goes sideways.
Probes: how Kubernetes checks health
- Liveness — "is it alive?" Failing liveness restarts the container. For deadlocks and wedged processes.
- Readiness — "is it ready for traffic?" Failing readiness removes the pod from service endpoints without restarting. For warm-up, dependency waits, deployments mid-rollout.
- Startup — "has it finished starting?" Defers liveness/readiness during slow initialization so slow starters aren't killed mid-boot.
- Probe types — HTTP GET (hit an endpoint), TCP socket (can it connect), exec (run a command in the container). Pick what the app actually supports.
Logs and metrics: the two signal types
- Logs — discrete events ("request failed: timeout").
kubectl logsreads container stdout/stderr; previous-container logs (-p) survive restarts. Apps should log to stdout/stderr — let the platform collect. - Metrics — numbers over time (request rate, latency percentiles, error rate). Prometheus is the ecosystem standard; the metrics server feeds HPA autoscaling.
- The golden signals — latency, traffic, errors, saturation. If a dashboard shows these four per service, most incidents are diagnosable.
- Distributed tracing — follow one request across microservices (OpenTelemetry). When "the request was slow" spans five services, traces show which one.
Debugging: the workflow
- Start with state —
kubectl get pods: Running? CrashLoopBackOff? Pending? The status line narrows everything. - Then describe — events reveal scheduling failures, image pull errors, failed probes, OOM kills. Events are the cluster's diary.
- Then logs — the app's own account of what went wrong. Current logs, then previous-container logs if it restarted.
- Then exec in — run a shell inside the container to inspect: DNS resolution, env vars, file contents, connectivity to dependencies.
- Common patterns — CrashLoopBackOff + OOMKilled = raise memory limit; ImagePullBackOff = wrong image name/tag or registry auth; Pending = no node fits (resources, affinity, taints); readiness failing = app started but isn't serving.
The must-memorize table: probe quick reference
Which probe does what on failure.
| Probe | Asks | On failure |
|---|---|---|
| Liveness | Is it alive? | Restart the container |
| Readiness | Ready for traffic? | Remove from service endpoints (no restart) |
| Startup | Finished starting? | Defer liveness/readiness; kill if never ready |
Try it: 4 sample questions
Sample questions to check your understanding of this domain. Answers and full reasoning are tucked under each one.
1. An app takes 90 seconds to warm its cache, but the liveness probe kills it at 30 seconds every time. What is the correct fix?
- A. A. Remove all probes
- B. B. Add a startup probe giving the app its warm-up window before liveness begins
- C. C. Make the readiness probe slower
- D. D. Add more replicas
Show answer & reasoning
B. The startup probe exists for exactly this: it gates liveness/readiness until initialization completes, so slow starters aren't murdered mid-boot. Removing probes (A) blinds the platform; readiness (C) doesn't affect liveness killing; replicas (D) just multiply the crash loop.
2. A pod shows CrashLoopBackOff and its events mention OOMKilled. What happened and what is the fix?
- A. A. The node ran out of disk — clean the node
- B. B. The container exceeded its memory limit and was killed — raise the memory limit (or fix the leak)
- C. C. The image is corrupted — rebuild it
- D. D. The scheduler is broken — restart it
Show answer & reasoning
B. OOMKilled = the kernel killed the container for breaching its memory limit; CrashLoopBackOff = Kubernetes keeps retrying. The fix is a higher limit (if legitimate usage) or fixing the memory leak (if not). Disk (A) and image (C) produce different errors entirely.
3. During a rolling update, new pods start but get traffic before their caches warm, causing user-facing errors. Which probe misconfiguration is this?
- A. A. Liveness is too aggressive
- B. B. Readiness isn't gating traffic until the pod is actually ready
- C. C. Startup probes are forbidden during updates
- D. D. Probes can't affect traffic at all
Show answer & reasoning
B. Readiness's job is exactly this: keep unready pods out of service endpoints. If new pods receive traffic while cold, readiness isn't checking real readiness (or isn't configured). Liveness (A) would restart them — a different failure mode.
4. An on-call engineer sees elevated error rates on one microservice but doesn't know which downstream call is failing. Which observability tool answers "which hop is slow/failing"?
- A. A. Container logs on the frontend pod
- B. B. Distributed tracing — following the request across services
- C. C. The deployment's replica count
- D. D. Node CPU metrics
Show answer & reasoning
B. One request crossing five services needs tracing: each hop timed and linked to the same trace ID, revealing exactly which downstream call fails or lags. Logs (A) show one service's view; node metrics (D) show infrastructure, not request paths.
This was one domain. The simulator drills all 5.
This free preview covered Application Observability & Maintenance (Domain 3.0, 15%). Not covered here: Application Deployment (Domain 2.0, 20%); Application Environment, Configuration & Security (Domain 4.0, 25%). Deployment patterns and the highest-weight environment/security domain stay in the paid guide and practice bank. The ByteBar Practice Exam Simulator drills every domain with 1,000 exam-style questions — $9.99 one-time unlocks all 28 exams. Prefer to read? The full CKAD Study Guide is in the ByteBar shop on Etsy.
Practice Exam Simulator — $9.99 one-time, all 28 exams Full Study Guides on Etsy