A lab feels successful when the command finishes. Troubleshooting begins when the result is not what you expected. For certification study, the valuable skill is not collecting more commands: it is choosing which observation will narrow the problem next.
Begin with a working baseline
Choose a small application and a Service you can already reach from a test client. Record the namespace, the request you made, and the response that proves the baseline works. Keep a copy of the relevant manifests. Without this baseline, a failed request may reflect your environment setup rather than the fault you meant to study.
Write a symptom before a diagnosis
'Networking is broken' is a conclusion, not an observation. Write something testable: a request from one client to a named Service times out, or name resolution fails before a connection is attempted. Include where the client runs. The same URL tested from a laptop and from inside the cluster is not the same experiment.
Trace the Service to its backends
The Kubernetes Service debugging guide works through separate checks for the application, Service definition, selectors, EndpointSlices, and ports. A Service selector must match the intended Pod labels. Inspect the associated EndpointSlices to see what backends are represented; do not treat an empty backend set and an application returning an error as the same failure.
- Observe: record the exact failing request and the current state without changing anything.
- Hypothesize: choose one explanation, such as a selector mismatch, and identify the observation that would support or reject it.
- Inspect: compare the Service definition with the intended workload and its endpoint information.
- Repair: change only the confirmed fault in your disposable exercise. Keep the original manifest so the change is reversible.
- Verify: repeat the original request, not merely the command used to apply the fix.
Introduce one controlled fault at a time
Starting from your working baseline, deliberately change one selector value, investigate the failure, and restore it. In a separate run, explore a port mismatch. Mixing several faults makes it harder to tell whether your reasoning worked. Keep the expected result out of sight while diagnosing, then compare it with your notes afterward.
For each run, save four short lines: the symptom, the evidence that mattered, the change made, and the verification result. Add one tempting but unsupported explanation you avoided. Those notes become better revision material than a long terminal transcript without a conclusion.
Connect the lab to your study plan
Use the Kubernetes learning paths for follow-on exercises and CKA practice for conceptual revision. Multiple-choice practice does not replace terminal work. When reviewing a question, ask which observation would distinguish its alternatives in a real environment, then try that observation in your lab.