The Triage Playbook — diagnose & remediate fast

Almost every task on a performance-based platform exam has something broken in it — sometimes that is the task, and sometimes it is a quiet trap inside a task that looks like plain configuration. The people who pass are not the ones who have memorised the most YAML; they are the ones who run the same diagnostic sequence every single time, so that all their thinking is left over for the actual fix. This page is the entry point: first that universal sequence, then a symptom index that takes whatever you are staring at and sends you to the page covering it in depth. Drill the sequence until the first six commands are muscle memory, and use the index as a lookup table, not a reading list.

The universal triage order

☺ Like you’re 10: Before you guess what’s wrong, always look in the same six places, in the same order. Guessing first is how you waste ten minutes.

The single biggest time sink under exam pressure is forming a hypothesis before gathering evidence. You see CrashLoopBackOff, you decide it must be the config map, you spend six minutes on the config map, and the answer was in the Events the whole time. So: do not think. Run the sequence. The sequence takes ninety seconds and it very frequently hands you the literal answer in plain English.

The six steps, in order

Steps 1–4 are the general Kubernetes ladder; step 5 is the platform-engineering addition that matters enormously on this exam, because so much of the platform is expressed as custom resources whose status.conditions block is the real error message. Only at step 6 do you get to have an opinion.

# The 90-second opener. Run this on every broken thing, every time.
kubectl config current-context                     # am I even on the right cluster?
kubectl get pods -n "$NS" -o wide                  # 1. wide list
kubectl describe pod -n "$NS" "$POD" | tail -30    # 2. Events live at the BOTTOM
kubectl get events -n "$NS" --sort-by=.lastTimestamp | tail -25   # 3. everything else that failed
kubectl logs -n "$NS" "$POD" --previous --tail=50  # 4. why the process exited
kubectl logs -n "$NS" "$POD" -c "$INIT" --previous # 4b. init containers need -c

# Cluster-wide sweep when you do not yet know where the damage is:
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | grep -i -E 'warn|fail|error' | tail -30

The decision flow

The flow below is what the six steps look like as a shape. Notice that almost every branch terminates in “read Events / read Conditions” — because in a well-built control plane, every controller is contractually obliged to explain itself in one of those two places. Notice too that the three branches map exactly onto the three detailed playbooks this page routes you to.

Symptom index

☺ Like you’re 10: Find the words you can actually see on your screen in the left column. The right column says which page to open.

Once the sequence has produced evidence, this is the lookup. Scan the left column for the string in front of you, read the middle column for the cause to test first, and follow the link for the full symptom → cause → command → fix treatment.

The three playbooks

☺ Like you’re 10: The detail lives in three pages: things that won’t start, things that can’t talk, and things that won’t deliver.

Each page recaps the six-step order, then goes deep with matrices, commands and worked fixes. Between them they cover every row of the index above.

If the symptom spans two of them — a rollout stuck because the new pods fail a readiness probe, say — start at the layer closest to the evidence you already have, and follow the signals outward.

When you are stuck

☺ Like you’re 10: If you’ve been stuck a while, stop and check the boring things: are you in the right room, and did you read the question properly?

Every experienced operator has lost twenty minutes to a problem that did not exist. The checks below cost fifteen seconds and resolve a surprising share of “impossible” failures — and being in the wrong namespace is one of the most common ways to fail a task you knew how to do.

# 1. Am I where I think I am?
kubectl config current-context
kubectl config view --minify -o jsonpath='{..namespace}{"\n"}'
kubectl config use-context cluster-prod
kubectl config set-context --current --namespace=app

# 2. Does the object exist, spelled that way?
kubectl get <kind> -A | grep -i <name>

# 3. Is the control plane healthy? (rules out a class of ghosts)
kubectl get nodes
kubectl get apiservices | grep -v True      # a broken aggregated API breaks unrelated commands

1. Re-read the task wording. Verbatim. People solve the problem they remember rather than the one on screen — fixing staging when the task named prod, or creating a ClusterRoleBinding where namespace-scoped access was asked for. The wording names the exact resource, namespace and context you are meant to use.
2. Verify cluster and namespace. Multi-cluster environments switch context between tasks, so a task beginning “on cluster staging” means the previous task’s context is now wrong.
3. Time-box hard. Past five to seven minutes with no visible progress, flag it and move on — partial credit is real, and three finished easy tasks beat one heroically half-finished hard one. Drill that against Practice Tasks and the Exam Guide, with the Command Reference within reach.

Triage is a habit, not a talent. The order never changes and the commands never change; all that changes is which drawer you open once the evidence is in.