Home / devops-containers / Certified Kubernetes Administrator / Cheat Sheet
Certified Kubernetes Administrator· Exam reference card · 2026 · Edureify AI
Certified Kubernetes Administrator

Certified Kubernetes Administrator Cheat Sheet

CKA Is a Hands-On Exam — Knowing kubectl Commands Isn't Enough, You Must Execute Under Pressure

The CKA is a performance-based exam with 15–20 tasks to complete in a live Kubernetes cluster within 2 hours. Speed, accuracy, and documentation navigation are as critical as knowledge.

Check Your Readiness →
Among the harder certs
Avg: Approximately 66% pass rate (CNCF data)
Pass: 750 / 1000
Most candidates understand Certified Kubernetes Administrator concepts — and still fail. This exam tests how you apply knowledge under pressure.
Core Framework

CKA Domain Coverage

CKA is performance-based — you perform tasks in a live Kubernetes environment. Troubleshooting is the most heavily weighted domain (30%). Know how to diagnose cluster failures, fix misconfigured deployments, and restore broken networking.

  1. 01
    Cluster Architecture, Installation & Configuration — 25% of exam
  2. 02
    Workloads & Scheduling — 15%
  3. 03
    Services & Networking — 20%
  4. 04
    Storage — 10%
  5. 05
    Troubleshooting — 30% (highest weighted domain)
Scenario Traps

Wrong instinct vs correct approach

A Pod is stuck in CrashLoopBackOff
✕ Wrong instinct

Delete and recreate the Pod

✓ Correct approach

Diagnose first: kubectl describe pod to see events and configuration, kubectl logs for application errors, kubectl logs --previous for logs from the crashed container — fix the root cause, not just the symptom

A Service is not routing traffic to its Pods
✕ Wrong instinct

Delete and recreate the Service

✓ Correct approach

Verify the Service selector matches the Pod labels (kubectl describe service), check the Pod is Running and Ready, verify the target port matches the container port, check NetworkPolicies that might block traffic

A node shows NotReady status
✕ Wrong instinct

Drain and delete the node

✓ Correct approach

SSH into the node, check kubelet status (systemctl status kubelet), check kubelet logs (journalctl -u kubelet), check container runtime status — NotReady is almost always a kubelet or CNI issue

Quick Rules

Know these cold

  • ▸ Set the kubectl context before every task — wrong context = wrong cluster
  • ▸ Use kubectl ... --dry-run=client -o yaml to generate manifest templates
  • ▸ Open documentation is allowed — use it for field names and examples
  • ▸ Troubleshooting order — ode → Pod → Container logs → Events
  • ▸ kubectl describe + kubectl logs are the two most important troubleshooting tools
  • ▸ etcd backup before any cluster modification — TCDCTL_API=3 etcdctl snapshot save
  • ▸ Imperative commands save time — ubectl create/run/expose are faster than writing YAML from scratch
Self Check

Can you answer these without checking your notes?

In this scenario: "A Pod is stuck in CrashLoopBackOff" — what should you do first?
Diagnose first: kubectl describe pod to see events and configuration, kubectl logs for application errors, kubectl logs --previous for logs from the crashed container — fix the root cause, not just the symptom
In this scenario: "A Service is not routing traffic to its Pods" — what should you do first?
Verify the Service selector matches the Pod labels (kubectl describe service), check the Pod is Running and Ready, verify the target port matches the container port, check NetworkPolicies that might block traffic
In this scenario: "A node shows NotReady status" — what should you do first?
SSH into the node, check kubelet status (systemctl status kubelet), check kubelet logs (journalctl -u kubelet), check container runtime status — NotReady is almost always a kubelet or CNI issue
Failure Patterns

Common Exam Mistakes — What candidates get wrong

Memorizing YAML templates instead of generating them with kubectl

Writing complex YAML from memory wastes time and introduces errors. Use kubectl create/run with --dry-run=client -o yaml to generate YAML templates, then modify them. This is faster and more accurate under exam time pressure.

Not using the Kubernetes documentation during the exam

CKA is open-book — kubernetes.io/docs is permitted. Candidates who don't use documentation to look up field names, manifest examples, and command syntax waste valuable allowed resources.

Skipping context-switching between clusters

The CKA exam has multiple cluster contexts. Forgetting to switch context (kubectl config use-context) before performing tasks means you're modifying the wrong cluster — every task specifies its context.

Troubleshooting from the wrong layer

Kubernetes troubleshooting requires systematic layer analysis: check Node status → Pod status → Container logs → Events. Candidates who jump to editing YAML before checking pod status waste time on the wrong problem.

Not backing up etcd before cluster modification tasks

Tasks involving cluster configuration changes (especially kubeadm upgrades) require etcd backup first. Candidates who skip this step risk corrupting the cluster.

CKA is a performance exam — knowing isn't enough, you must execute quickly. Test your Kubernetes administration skills now.

Start Diagnostic Test → View all exams