Overview
Application Observability and Maintenance is the troubleshooting domain for developers. You add liveness, readiness and startup probes using httpGet, tcpSocket, exec or grpc checks and tune their timing fields. You find which Pods use the most CPU or memory with kubectl top, scan events sorted by time, and read logs from a specific container, from a crashed previous instance or across Pods selected by label. Debugging tasks start from a broken workload, such as a CrashLoopBackOff, an ImagePullBackOff or a Pod stuck Pending, and you trace the cause through describe, events and logs.
Maintenance adds API deprecations. Kubernetes removes beta API versions on a published schedule, so old manifests stop applying after an upgrade. You identify the served versions with kubectl api-resources and kubectl explain, then rewrite the manifest for the current version.
How it's tested
Observability tasks either ask you to add something, such as a probe with exact timing, or to find something, such as the Pod using the most memory or the error a container logged before crashing. Answers are often written to a file path the task gives, so the format and location of your output matter.
-
Probe configuration
An existing Deployment gains a liveness, readiness or startup probe with a given path, port, command, initialDelaySeconds and periodSeconds.
-
Find and record
Identify the highest-consuming Pod, a failing container's last error or a recent event, and write the name or line to a stated file.
-
Fix a broken workload
A Pod is crashing or Pending and you find the cause, such as a wrong image tag, command, port or missing ConfigMap, and correct it.
A Pod restarts every few seconds and kubectl logs shows nothing useful. Running kubectl logs pod --previous prints the output of the crashed instance, which shows a missing environment variable. Describing the Pod would show the CrashLoopBackOff reason and exit code but not the application's own message, so the previous logs are the faster route to the cause.
Competencies 5
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
3.1 Understand API deprecationsRecognising removed API versions and updating manifests.
- What it means
- Kubernetes graduates APIs from alpha to beta to stable and removes older versions after a deprecation period. A manifest that names a removed apiVersion is rejected by the API server.
- What to understand
- Check served versions with kubectl api-versions, kubectl api-resources and kubectl explain resource --api-version. Deprecated versions trigger a warning when used. Well-known removals include extensions/v1beta1 Ingress (v1.22), batch/v1beta1 CronJob and policy/v1beta1 PodDisruptionBudget (v1.25). Updating usually means changing apiVersion and adapting changed fields, such as Ingress backend.service.name. The kubectl convert plugin can rewrite manifests when installed.
- How it shows up
- Expect a manifest that fails to apply and must be updated to a current apiVersion.
- Common confusion
- Changing apiVersion alone when the newer schema also renamed or restructured fields.
3.2 Implement probes and health checksLiveness, readiness and startup probes and their timing fields.
- What it means
- Probes let the kubelet test a container. Liveness failures restart the container, readiness failures remove the Pod from Service endpoints, and a startup probe delays the other two until slow initialization finishes.
- What to understand
- Handlers are httpGet with path and port, tcpSocket, exec with a command, and grpc. Timing fields are initialDelaySeconds, periodSeconds, timeoutSeconds, successThreshold and failureThreshold. A startup probe allowing failureThreshold times periodSeconds protects slow starters without a long liveness delay. Readiness successThreshold can exceed 1; liveness and startup must use 1. Probes are set per container.
- How it shows up
- You may add a probe with exact path, port and timing values to an existing Deployment.
- Common confusion
- Using a liveness probe where readiness is needed, so a busy app is restarted instead of taken out of rotation.
3.3 Use built-in CLI tools to monitor Kubernetes applicationskubectl top, get with watch, describe and events.
- What it means
- kubectl can show live status, resource use and recent events without extra tools. kubectl top needs the metrics-server add-on, which exam clusters normally include.
- What to understand
- Use kubectl top pod -n ns --sort-by=cpu or memory, add --containers for per-container figures, and kubectl top node for node load. kubectl get pods -w streams changes, -o wide shows node and IP, and custom-columns or jsonpath extract fields. kubectl events -n ns or kubectl get events --sort-by=.lastTimestamp lists recent activity, and field selectors narrow it to one object.
- How it shows up
- Expect to find the Pod with the highest CPU or memory in a namespace and write its name to a file.
- Common confusion
- Reading kubectl top numbers as requests or limits; they are current usage.
3.4 Utilize container logsReading current, previous and multi-Pod container logs.
- What it means
- Containers should log to stdout and stderr, which the kubelet keeps and kubectl logs returns. Logs are the first place to find application-level errors.
- What to understand
- Use -c to choose a container in multi-container Pods, --previous for the last terminated instance, -f to follow, --tail and --since to limit output, --timestamps, -l with a label selector for many Pods, and --all-containers. kubectl logs deploy/name picks one Pod of the Deployment. Logs written to files inside the container are invisible to kubectl unless a sidecar streams them.
- How it shows up
- A task may ask you to save a container's error lines to a file or find which Pod logged a message.
- Common confusion
- Forgetting -c on a Pod with a sidecar and reading the wrong container's output.
3.5 Debugging in KubernetesDiagnosing Pending, crashing and unreachable workloads.
- What it means
- Debugging means moving from a symptom, such as a Pod status or failed request, to the cause using status fields, events, logs and interactive access to the container.
- What to understand
- Map statuses to causes: ImagePullBackOff means a wrong image name, tag or pull secret; CrashLoopBackOff means the process exits; Pending usually means unschedulable resources, node selectors or an unbound claim; CreateContainerConfigError points to a missing ConfigMap or Secret key. Use kubectl describe, exec, port-forward and kubectl debug to add an ephemeral container with tools to a running Pod.
- How it shows up
- Expect a broken Deployment and a requirement that its Pods reach Running and Ready.
- Common confusion
- Deleting and recreating a failing Pod without fixing the spec that caused the failure.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Liveness probe
Restarts the container when checks fail.
- Remember
- Use it for hangs and deadlocks, not slow startup.
- Tested as
- Probe tasks give exact values to set.
- Trap
- Pointing it at a dependency, so an outage elsewhere restarts healthy Pods.
-
Readiness probe
Controls whether the Pod receives Service traffic.
- Remember
- Failure removes the Pod from endpoints without restarting it.
- Tested as
- Also gates rolling updates.
- Trap
- Expecting a failed readiness probe to restart the container.
-
Startup probe
Holds liveness and readiness checks until the app has started.
- Remember
- Total startup allowance is failureThreshold times periodSeconds.
- Tested as
- Fits slow-starting applications.
- Trap
- Raising initialDelaySeconds on liveness instead, which slows recovery later.
-
kubectl top
Shows current CPU and memory use from metrics-server.
- Remember
- --sort-by=cpu or memory ranks results.
- Tested as
- Common find-and-record task.
- Trap
- Expecting it to work without metrics-server.
-
kubectl logs --previous
Prints logs from the previous terminated container instance.
- Remember
- Essential when a crashing container restarts too fast to read.
- Tested as
- Finds the reason behind CrashLoopBackOff.
- Trap
- Reading current logs, which may be empty after a restart.
-
Events
Short records of scheduling, pulls, probe failures and kills.
- Remember
- kubectl events or get events --sort-by=.lastTimestamp.
- Tested as
- Fastest view of what Kubernetes did to a Pod.
- Trap
- Assuming events last forever; they expire after about an hour by default.
-
kubectl debug
Adds an ephemeral container to a running Pod or copies the Pod.
- Remember
- Use --target to share the process namespace with one container.
- Tested as
- Useful when the image has no shell.
- Trap
- Trying to exec into a distroless image.
-
Exit code 137
Container was killed by SIGKILL, often for exceeding its memory limit.
- Remember
- describe shows Last State Terminated with reason OOMKilled.
- Tested as
- Links debugging to resource limits.
- Trap
- Treating it as an application bug and ignoring the limit.
-
Deprecated apiVersion
A version scheduled for removal or already removed.
- Remember
- kubectl explain and api-resources show what the cluster serves.
- Tested as
- Maintenance tasks fix old manifests.
- Trap
- Updating apiVersion without checking changed field names.
-
Output to a file
Many tasks ask for answers saved at a given path.
- Remember
- Use shell redirection and check the file content afterwards.
- Tested as
- The grader reads the file, not your terminal.
- Trap
- Writing extra headers or wrong formatting into the answer file.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Probe types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Liveness | Is the process still working? | Failure restarts the container | Using it to wait for dependencies |
| Readiness | Can the Pod serve requests now? | Failure removes it from Service endpoints | Expecting a restart |
| Startup | Has the app finished starting? | Suspends the other probes until it succeeds | Leaving it out for apps that start slowly |
Where to look first
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| kubectl describe | Status, conditions, last state and recent events | Shows Kubernetes-level causes | Skipping the Events section at the bottom |
| kubectl logs | Application stdout and stderr | Shows application-level causes | Missing -c or --previous |
| kubectl events | Namespace-wide timeline of actions | Covers objects other than the Pod | Not sorting by time |
| kubectl debug / exec | Interactive access inside the Pod | Tests network and files from the container's view | Using exec on an image without a shell |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Probe type swapped
- What candidates pick
- Adding livenessProbe for a 'take out of service' requirement.
- Why it looks right
- Liveness is the best-known probe.
- Why it's wrong
- Liveness restarts the container; only readiness removes the Pod from Service endpoints while leaving it running.
Clue to watch for Phrases such as 'should not receive traffic until'.
-
Probe on the wrong port
- What candidates pick
- Using the Service port number in httpGet.
- Why it looks right
- The Service port appears in the task text.
- Why it's wrong
- The kubelet probes the container directly, so the port must be the containerPort or its name.
Clue to watch for A Service port that differs from the container port.
-
top without sorting
- What candidates pick
- Reading the default kubectl top output and picking by eye.
- Why it looks right
- Small lists look easy to scan.
- Why it's wrong
- Values can be close or in different units; --sort-by gives the correct order.
Clue to watch for 'Highest' or 'most' in the task.
-
Logs from the wrong container
- What candidates pick
- kubectl logs pod without -c.
- Why it looks right
- kubectl picks a default container.
- Why it's wrong
- In multi-container Pods the default may be the sidecar, so the error line is missed.
Clue to watch for A Pod listed with READY 1/2 or 2/2.
-
Fixing the symptom
- What candidates pick
- Deleting a crash-looping Pod.
- Why it looks right
- A fresh Pod sometimes starts.
- Why it's wrong
- The controller recreates it from the same broken template, so the failure returns.
Clue to watch for Pods owned by a Deployment or ReplicaSet.
-
Stale apiVersion kept
- What candidates pick
- Adding --validate=false to force apply.
- Why it looks right
- It silences the error.
- Why it's wrong
- The API server still does not serve the removed version, so the object cannot be created.
Clue to watch for An error saying no matches for kind in version.
Answer framework
Follow these steps when a workload misbehaves or a task asks you to observe it.
- Read the status column first and map it to a likely cause such as a bad image, a failing command, scheduling limits or missing configuration.
- Run kubectl describe on the Pod and read its conditions, last state, exit codes and the events list at the bottom.
- Read logs from the right container, adding --previous when the container has restarted.
- Fix the owning object, such as the Deployment template, ConfigMap or probe definition, rather than the individual Pod, which its controller would simply replace.
- Confirm Pods reach Running and Ready, then write any requested answer to the exact file path and check its contents.
Practice question
Want more like this? The CKAD practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Build a small broken-workload lab. Write five Deployments, each with one fault: a bad image tag, a command that exits, a missing ConfigMap key, an impossible resource request and a wrong probe port. Fix each one using only describe, events and logs, and time yourself. Repeat with the faults shuffled until you name the cause from the status column alone.
Then practise probes on an app with a slow start, such as an nginx container whose command sleeps before launching. Add a liveness probe that kills it, then rescue it with a startup probe and compare the two configurations. Add a readiness probe and watch kubectl get endpoints change as it passes and fails.
Finally, cover monitoring and maintenance. Run kubectl top with sorting and container breakdowns, and write answers to files exactly as a task would ask. Take three old manifests that use removed API versions, apply them to see the errors, and update each using kubectl explain to confirm the current schema.
FAQ
How much of the CKAD exam is Application Observability and Maintenance?
Application Observability and Maintenance is 15% of the CKAD according to the CNCF curriculum, the smallest share of the five domains. Expect two or three tasks.
Is metrics-server available for kubectl top?
Monitoring tasks that need resource figures are set on clusters where kubectl top works. In your own lab, install metrics-server so you can practise the same commands.
Do I need Prometheus or Grafana for the CKAD?
No. The competency names built-in CLI tools, so focus on kubectl top, get, describe, events and logs.
What is the difference between a readiness and a liveness probe?
A failing readiness probe stops traffic to the Pod but leaves it running. A failing liveness probe makes the kubelet restart the container.
How do I debug a container image without a shell?
Use kubectl debug to attach an ephemeral container, for example a busybox image, to the running Pod, optionally targeting the app container's process namespace.
How do I check whether an apiVersion still exists?
Run kubectl api-resources or kubectl api-versions, or kubectl explain with --api-version. If the version is missing, the cluster no longer serves it.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
Work through timed tasks on probes, kubectl top, container logs, API version fixes and broken workloads in this 15% domain.