The kubectl CLI has hundreds of subcommands, flags, and output options. In day-to-day work — and especially under exam pressure — what matters is knowing which dozen or so commands give you the most leverage. The list below is focused on commands that are either genuinely underused or have flags that most engineers never discover until they search at 2 AM during an incident.

Visibility & Inspection

01 Show which node a pod is running on

The default kubectl get pods output hides node assignment and pod IP. Add -o wide to expose both instantly — essential when debugging network issues or node-level problems.

kubectl get pods -o wide

02 Find your memory hogs

kubectl top requires the Metrics Server to be installed, but when it is, this one-liner ranks pods by memory consumption across a namespace. Swap memory for cpu to find CPU spikes instead.

kubectl top pods --sort-by=memory

03 Read logs from a crashed container

When a container restarts due to OOMKill or a crash loop, the current container’s logs are empty. The --previous flag pulls logs from the last terminated container — where the actual error lives. Combine with -f on a running container to stream in real time.

# Stream logs from a running container
kubectl logs -f deployment/myapp

# Read the logs from the container that just crashed
kubectl logs deployment/myapp --previous

04 Get a shell inside a running container

The classic one-liner for live debugging. Use /bin/sh for minimal images (Alpine, distroless-adjacent) or /bin/bash when available. Replace myapp-pod with the actual pod name from kubectl get pods.

kubectl exec -it myapp-pod -- /bin/sh

05 Access a service locally without exposing it

Port-forward tunnels a local port to a port inside the cluster. This works for Services, Deployments, and even individual Pods. It is the fastest way to hit an internal HTTP endpoint from your laptop during debugging.

kubectl port-forward svc/myservice 8080:80

06 See cluster events in chronological order

Events are the cluster’s audit trail: failed image pulls, OOMKills, failed scheduling, readiness probe failures. By default they are printed in creation order, which is rarely what you want. Sort by lastTimestamp to see what happened most recently.

kubectl get events --sort-by='.lastTimestamp'

# Scope to a single namespace and only show warnings
kubectl get events -n mynamespace --field-selector type=Warning --sort-by='.lastTimestamp'

Safe Changes & Rollouts

07 Preview what a manifest change will actually do

kubectl diff compares your local YAML against the live state in the cluster and prints a unified diff. Run it before every kubectl apply in production — it has saved more than a few teams from accidentally deleting an environment variable or changing a replica count.

kubectl diff -f manifest.yaml

08 Roll back a broken deployment in one command

When a deployment rolls out a bad image, kubectl rollout undo reverts to the previous ReplicaSet immediately. You can also target a specific revision with --to-revision=N after checking kubectl rollout history.

# Check the rollout history first
kubectl rollout history deployment/myapp

# Roll back to the previous revision
kubectl rollout undo deployment/myapp

# Roll back to a specific revision
kubectl rollout undo deployment/myapp --to-revision=3

13 Patch a resource without editing the full manifest

When you need to make a surgical change — update a replica count, change an image tag, toggle a label — kubectl patch is faster than kubectl edit and scriptable. The --type=merge flag uses JSON Merge Patch semantics.

# Scale a deployment to 5 replicas without opening an editor
kubectl patch deployment myapp -p '{"spec":{"replicas":5}}'

# Update the container image
kubectl patch deployment myapp -p '{"spec":{"template":{"spec":{"containers":[{"name":"myapp","image":"myapp:v2.1"}]}}}}'

Cluster Exploration

09 Debug directly on a node

kubectl debug node spins up a privileged pod on the target node with host filesystem access. This is how you investigate node-level issues — disk pressure, OOM events in dmesg, rogue processes — without needing SSH access. Available since Kubernetes 1.23.

kubectl debug node/my-node-name -it --image=busybox

10 Read the built-in Kubernetes API docs

kubectl explain is the offline reference that is always available in the exam terminal. Drill into nested fields with dot notation. You will never need to memorize the exact path to livenessProbe again.

# Describe the top-level pod spec
kubectl explain pod.spec

# Drill into container fields
kubectl explain pod.spec.containers

# See liveness probe options
kubectl explain pod.spec.containers.livenessProbe

11 Discover every resource type the cluster knows about

Custom Resource Definitions (CRDs) add new resource types at runtime. kubectl api-resources lists everything — built-in and custom — along with short names and whether the resource is namespaced. Invaluable when working with an unfamiliar cluster.

# List all resource types
kubectl api-resources

# Filter to only namespaced resources
kubectl api-resources --namespaced=true

# Find short names (e.g. "po" for pods, "svc" for services)
kubectl api-resources -o wide

Filtering & Bulk Operations

12 Find failed pods across every namespace

--field-selector filters on server-side before any data is sent to the client, making it fast even in large clusters. Combining -A (all namespaces) with a phase filter is the fastest way to audit cluster health.

# All Failed pods across all namespaces
kubectl get pods -A --field-selector=status.phase=Failed

# All pods NOT in the Running state
kubectl get pods -A --field-selector='status.phase!=Running'

14 Trigger a CronJob manually for testing

Waiting for a CronJob’s schedule to fire just to test it is painful. kubectl create job with --from creates an immediate one-off Job using the exact same pod template as the CronJob — including environment variables, volumes, and image.

kubectl create job test-run --from=cronjob/my-cronjob

15 Check what a ServiceAccount is allowed to do

kubectl auth can-i tests RBAC permissions for the current user or for any other identity via --as. This is the correct way to verify that a ServiceAccount only has the access it should have — and to debug Forbidden errors before opening a ticket.

# Check what the current user can do
kubectl auth can-i create pods

# Impersonate a ServiceAccount to test its permissions
kubectl auth can-i create pods --as=system:serviceaccount:mynamespace:mysa

# List everything a ServiceAccount can do in a namespace
kubectl auth can-i --list --as=system:serviceaccount:mynamespace:mysa -n mynamespace

Why this matters for CKA and CKAD

Both the CKA and CKAD exams are fully hands-on: you are given a live cluster and a set of tasks to complete in two hours. There is no multiple-choice safety net. Every minute you spend hunting for the right flag is a minute you are not solving the next task.

Commands 3, 4, 6, 8, and 10 appear in some form in almost every CKA scenario. Commands 7 (kubectl diff) and 15 (kubectl auth can-i --list) are the kind of shortcuts that separate candidates who finish with time to spare from those who submit with seconds remaining.

A few exam-specific habits worth building:

The cluster doesn’t know you’re in an exam. It just responds to commands. The more fluent you are at the CLI, the more the exam feels like any other Tuesday.

Practise with real questions

Command-line fluency comes from repetition, but understanding why you run a command matters just as much in an exam context. If you are preparing for the CKA or CKAD, test your scenario knowledge with the free question packs on CertQuests — 60 scenario-based questions per exam, covering every domain from cluster architecture to network policies and supply chain security.