The kubectl Fluency Baseline

Every one of this course's five CNCF exams — KCNA, KCSA, CKA, CKAD, CKS — assumes you can already operate kubectl, and none of them teaches it to you from scratch. What "operate" means differs sharply by exam: the two knowledge exams only need you to recognize a command's shape on a multiple-choice page, while the three performance exams need you to produce the right command, cold, inside a per-task time budget. This page is the floor underneath both versions of that assumption — not a full tool guide (that's the separate kubectl tool guide, which this page assumes and points back to for mechanics) but the compressed set of reflexes worth owning before you open any blueprint page: setting a context and namespace without thinking, generating a manifest instead of typing one from memory, and reading describe, logs and events in the order that actually finds the fault. It closes with a two-tier self-test, so you find the gaps here, in twenty minutes, rather than mid-task on exam day.

Why this is a separate page from the kubectl tool guide

☺ Like you're 10: One page teaches you how the remote control works. This one is just the quiz that checks you can already use it without looking.

The kubectl tool guide explains the mechanics in full: the three ways to manage an object and why mixing them causes real incidents, how a kubeconfig's clusters/users/contexts actually fit together, kubectl explain against the live OpenAPI schema, and extending the CLI with krew plugins. Read it once, understand it, and you're done with it — it's reference material, not a drill. This page is different on purpose: it's narrower, it repeats itself less, and it exists to be re-run as a self-test every few weeks while you're actively preparing for one of the five exams. Where the tool guide explains why a mechanism works, this page only cares whether you can produce the command for it inside a few seconds, because that's the actual thing being graded.

Two different fluencies, and why the difference matters more than the commands

☺ Like you're 10: Two of these five tests watch what you type; three of them watch what you build. The same commands matter to both — just not in the same way.

The how-to-study page covers this split for the whole course; here it's worth restating narrowly, because it's the single fact that decides how you should drill. KCNA and KCSA are closed-book multiple choice — there is no terminal in the room, so a question about kubectl logs --previous is testing whether you know what that flag does, never whether you can type it fast. CKA, CKAD and CKS are performance-based: a live terminal against real clusters, roughly 15–20 tasks inside a two-hour window, graded purely on the cluster's end state when the clock stops. Nobody reads your keystrokes and nobody cares if you paste a command from the allowed documentation — but every second spent hesitating over syntax is a second that task's budget didn't have.

That distinction is why the self-test at the end of this page has two tiers instead of one: a recognition tier for KCNA/KCSA, and a speed tier — timed, cold, no docs — for CKA/CKAD/CKS. Marking a speed-tier item "known" because you could explain it is exactly the mistake the study-method page warns about at greater length.

Contexts and namespaces: set them before you touch anything

☺ Like you're 10: Before you press any button on the remote, check which TV it's pointed at. Skip that check and you might turn off the wrong room's television.

This is the single most expensive reflex to skip, on every one of the three performance exams. Each task typically hands you a fresh kubectl config use-context line, and solving task 11 perfectly against task 10's cluster scores exactly zero — the grader checks the cluster the task named, not the one you happened to be looking at. Build the habit of running the context command first, every single task, before reading past the first sentence.

# the four commands that should be reflexive before anything else
kubectl config get-contexts                            # every context, current one marked with *
kubectl config current-context                          # just the pointer, nothing else
kubectl config use-context k8s-c1-H730593                # flip it — copy the exact name from the task
kubectl config set-context --current --namespace=shop    # default namespace for every bare command that follows

# confirm both at once, without scrolling a whole file
kubectl config view --minify | grep -E 'current-context|namespace'

Two habits close the rest of the gap. First, don't trust your eyes on a shared terminal — a shell prompt that prints the live context and namespace (most prompt frameworks have a Kubernetes segment) catches a stale pointer before you type the destructive command, not after. Second, once a namespace is set for the task, drop -n from every subsequent command rather than re-typing it and risking a typo that silently switches you elsewhere — that's the entire point of set-context --current --namespace=. The full kubeconfig structure — how clusters, users and contexts actually fit together, and the ctx/ns krew plugins that make switching faster still — is in the tool guide's contexts section; this page only needs you to be able to run the four commands above without a pause.

The dry-run reflex: your manifest generator wall

☺ Like you're 10: Instead of typing a whole recipe from memory, you say what dish you want and the kitchen hands you a starting recipe card — correct format, right sections, nothing missing.

The tool guide explains why --dry-run=client -o yaml works and how it differs from --dry-run=server; this page is the wall of generators worth having cold, because CKAD and CKS in particular expect you to scaffold a wide range of object kinds fast, not just Deployments. Set the shorthand up before task one, then never hand-type YAML boilerplate again:

alias k=kubectl
export do='--dry-run=client -o yaml'
source <(kubectl completion bash)          # or zsh — tab-complete every resource and flag
complete -o default -F __start_kubectl k    # completion follows the alias too

k create deployment web --image=nginx:1.27 --replicas=3 $do > deploy.yaml
k create service clusterip web --tcp=80:8080 $do > svc.yaml
k expose deployment web --port=80 --target-port=8080 $do              # Service scaffolded FROM an existing object
k create configmap app-cfg --from-literal=LOG_LEVEL=debug $do
k create secret generic db-cred --from-literal=password=s3cr3t $do
k create serviceaccount builder $do
k create role reader --verb=get,list,watch --resource=pods $do
k create rolebinding reader-binding --role=reader --serviceaccount=shop:builder $do
k create clusterrole node-reader --verb=get,list --resource=nodes $do
k create clusterrolebinding node-reader-binding --clusterrole=node-reader --serviceaccount=shop:builder $do
k create job one-off --image=busybox $do -- echo hello
k create cronjob nightly --image=busybox --schedule="0 2 * * *" $do -- echo hi
k create ingress web-ing --rule="shop.example.com/=web:80" $do
k create namespace team-a $do

One trap sits inside that list on purpose: k create deployment scaffolds a Deployment, but kubectl run scaffolds a bare Pod — the imperative pod/RC/deployment "generator" flags were removed years ago, so kubectl run web --image=nginx today always means "just a Pod." Reaching for run when a task actually wants a Deployment is a fast, silent way to fail a task that looked easy. If you genuinely want a lone Pod for a quick test, run is exactly right; if you want anything self-healing, reach for create deployment instead.

describe, logs, events: the triage order

☺ Like you're 10: Three different questions, three different tools. Ask "why won't it start," "what did it say before it died," and "what's been happening around here" in that order, and you'll almost never guess wrong.

This triage order carries most of CKA's Troubleshooting domain — the single largest domain on that exam at 30% — and it's just as central to CKAD and CKS once something in a task doesn't come up the way it should. Each of the three commands answers a genuinely different question, and reaching for the wrong one first is how a five-minute fix turns into fifteen.

# 1. the object's own story, resolved spec plus its recent events
kubectl describe pod checkout-7d9f4c-x8k2q

# 2. the dead container's last words — --previous is the whole trick for a crash loop
kubectl logs checkout-7d9f4c-x8k2q -c app --previous
kubectl logs -f checkout-7d9f4c-x8k2q --since=10m        # tail the live container instead

# 3. the neighborhood, newest last, narrowed to one object if you have a suspect
kubectl get events -n shop --sort-by=.lastTimestamp
kubectl get events -n shop --field-selector involvedObject.name=checkout-7d9f4c-x8k2q

describe's events section and get events are drawing on the same underlying objects, but they're not interchangeable: describe shows only the events attached to the one object you named, in a stable snapshot at the moment you ran it, while get events --sort-by=.lastTimestamp shows everything in the namespace, newest last, including things that happened to other objects that might be the actual cause — a full disk on the node, a failing admission webhook, a NetworkPolicy that just got applied. When describe comes back clean and the symptom persists, that's the signal to widen the net rather than staring at the same object harder.

Beyond read-and-generate: edit, patch, verify, roll back

☺ Like you're 10: Once you know how to look and how to build, you need to know how to change something that already exists, prove the change worked, and undo it if it didn't.

A handful of commands round out the reflex set, mostly by letting you change or verify a live object without re-writing its whole manifest:

# targeted edits without opening the whole file again
kubectl set image deployment/web web=nginx:1.28
kubectl scale deployment/web --replicas=5
kubectl patch deployment web -p '{"spec":{"replicas":5}}'                     # strategic merge, the default
kubectl patch deployment web --type=json -p='[{"op":"replace","path":"/spec/replicas","value":5}]'
kubectl edit deployment web                                                    # opens the live object in $EDITOR

# did the change actually land, and would a re-apply be safe?
kubectl rollout status deployment/web --timeout=90s
kubectl rollout history deployment/web
kubectl rollout undo deployment/web --to-revision=2
kubectl diff -f deploy.yaml                                                    # what apply WOULD change, before it changes it
kubectl get pods -l app=web -w                                                  # watch it converge instead of polling

# proving an RBAC grant works, rather than trusting that it applied cleanly
kubectl auth can-i list secrets -n shop --as=system:serviceaccount:shop:builder
kubectl auth can-i --list -n shop --as=system:serviceaccount:shop:builder

kubectl explain belongs on this list too — kubectl explain deployment.spec.strategy --recursive is faster than a search engine and always matches the exact API version the cluster is running — but the tool guide already covers it at full depth, so it isn't repeated here. The one habit worth adding on top of all of the above: a task on a performance exam is complete when you've proved it, not when you've applied it. rollout status came back clean, auth can-i said yes, get -o jsonpath printed exactly the value the task asked for — budget the last twenty seconds of every task for that check, because applying a manifest and immediately moving on is how candidates walk out confident and score lower than they expected.

What KCNA and KCSA actually need from all of this

☺ Like you're 10: If there's no terminal in the room, you don't need fast fingers — you need to be able to picture what the command would do and pick the true sentence about it.

It's tempting to skip this whole page if you're only sitting KCNA or KCSA — after all, neither hands you a terminal. That's a real mistake, just not the one it looks like. Both exams draw heavily on scenario questions that describe a symptom and ask which command or which cause explains it: "a Pod is stuck in Pending — which of the following would kubectl describe most likely reveal?" You don't need to type the command, but you absolutely need to know what output it produces and why, which means the fastest route to a correct answer is having actually run it enough times that the shape of its output is familiar rather than abstract. KCSA leans further into auth can-i and RBAC verification specifically, because "how would you confirm this ServiceAccount cannot read Secrets" is a natural security-knowledge question even with no terminal to run the check in.

So the honest instruction for KCNA/KCSA candidates is: work through every command block on this page on a real cluster — kind or minikube both make this free — not to build typing speed, but so the multiple-choice options stop being abstract vocabulary and start being things you recognize on sight, the way a recipe reads differently once you've actually cooked it.

Self-test: two tiers, scored honestly

☺ Like you're 10: Tick a box only if you could actually do the thing right now, with nobody helping. An empty box just found you twenty minutes of useful practice.

Tier 1 is the recognition floor every exam on this ladder needs, KCNA and KCSA included. Tier 2 is the speed floor, and it's specific to CKA, CKAD and CKS — read each item as a literal instruction with an implied stopwatch, and only tick it if you could do it cold, on a live cluster, right now.

• ① Tier 1 — recognition (every exam)
• Name what kubectl describe, kubectl logs --previous and kubectl get events each answer, and how the three differ
• Explain the difference between kubectl run and kubectl create deployment, and which one actually creates a Deployment
• Say what --dry-run=client versus --dry-run=server each actually check
• Explain what kubectl config set-context --current --namespace= changes, and what it leaves alone
• Say what kubectl auth can-i --as= proves that reading a RoleBinding's YAML does not
• ② Tier 2 — speed, cold, on a live cluster (CKA / CKAD / CKS)
• Set a context and namespace, then generate and apply a Deployment, a ConfigMap and a Secret — under two minutes, no docs
• Generate a Role and a RoleBinding for a named ServiceAccount, apply both, and verify with auth can-i --as= — under ninety seconds
• Given a crash-looping Pod, run the full triage — describe, logs --previous, get events --sort-by=.lastTimestamp — and state the root cause, without pausing between commands
• Patch a live Deployment's image with kubectl set image, watch rollout status confirm it, then rollout undo it back — without opening a text editor once
• Expose an existing Deployment as a ClusterIP Service with one command, and confirm it resolves with a throwaway debug Pod

Anything left unticked in Tier 2 is your next practice session — not a reading assignment, a stopwatch session on a real cluster. The flashcards and self-check quiz reinforce Tier 1; nothing but repetition on a live cluster builds Tier 2.