Black Friday · 27 Nov 2026

Up to 90% off selected certifications.

One time only offer for a very precious career goal. Limited coupons, waitlist first.

Free lesson · CKA Prep Program · Module 6: Troubleshooting

Apply Observe, Narrow, Verify Under Time Pressure

Troubleshooting is a discipline, not talent: observe without theorizing, narrow by halves, and verify the cause rather than celebrating the recovery. Thirty percent of the exam is this loop wearing different symptoms.

11 min reading

Objectives

  • State the current symptom in one falsifiable sentence before touching anything
  • Narrow with binary-split tests that eliminate half the system each
  • Verify the fix proves the cause instead of coinciding with recovery
  • Write the incident record that makes the next occurrence a five-minute job

Why this matters

Under the clock, engineers either flail (restarting things at random) or freeze (reading every log). The method beats both by bounding each step: one symptom sentence, one split test, one proof. Most CKA failures are not knowledge gaps but method collapses: the candidate knew the commands and applied them to the wrong layer.

Concepts

Observe means describing the failure precisely: which pods, since when, what changed, what the events say. Write it down; memory edits itself under stress. Narrow means binary splits: app versus platform (exec plus logs versus events), DNS versus network (name versus raw IP), one pod versus all pods (single versus fleet). Each test must eliminate a whole branch, never confirm a hunch.

Verify means proving causation: the fix applied, the symptom gone, the fix reverted in staging (or reasoned through) with the symptom returning. Recovery without proof is superstition that fails the next identical incident. The incident record is four lines: symptom, tests run with results, cause, fix plus prevention. Future you reads it at 3 AM.

Worked example

Checkout errors since 14:05, deploys at 14:00, one suspect:

# observe: symptom sentence
# "POST /pay returns 500 from all checkout pods since 14:05, after the 14:00 deploy; events show no kills."
# narrow 1: platform or app?
kubectl get events --sort-by=.lastTimestamp | tail -10   # quiet: app side
# narrow 2: new code or new config?
kubectl rollout history deployment/checkout              # revision 7 at 14:00
kubectl exec deploy/checkout -- printenv | grep -i PAY_  # new var PAY_API_V2=1
# narrow 3: does the old revision still serve?
kubectl rollout undo deployment/checkout --to-revision=6
# errors stop: cause proven, not coincidental
# verify: re-apply revision 7 in staging, errors return -> causation confirmed

The record writes itself from the commands: symptom, three splits with outputs, cause (unmigrated flag in revision 7), fix (migration plus re-roll) and prevention (flag-gated deploys).

Exam notes

The symptom sentence is the highest-value minute: vague symptoms breed vague tests. Never skip the verify step under time pressure; the exam grades the fix, and fixes without proof are reverted guesses. And change one variable per test: parallel changes make every result unreadable.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Log in and complete the lesson to leave feedback.

Exercise

Take a fictional symptom (all pods of one service CrashLooping after a node reboot) and write the observe sentence plus three binary-split tests with the branch each eliminates. Name the verify step that would prove your final cause.

Pass criteria

Symptom sentence falsifiable with scope plus time plus change; three splits each eliminating a branch; verify step names the reverted-or-reasoned proof.

Sources

Log in to track progressFree account: stores only your lesson progress and quiz results.