Search Pass4Sure

devops-kubernetes

CKA exam guide: the kubectl commands you must know cold

CKA exam guide with complete kubectl command reference, etcd backup commands, kubeadm upgrade sequence, imperative vs declarative strategy, and 17-task time management.

·Published March 9, 2025 ·Editorial standards
16 min read·10666 views
CKA exam guide: the kubectl commands you must know cold

Is the CKA exam open book?

Yes. The CKA allows you to access kubernetes. io/docs and kubernetes. io/blog during the exam. No other external resources are permitted. The open-book policy is helpful for complex YAML syntax but doesn't compensate for slow command recall — with 17 tasks in 2 hours, you need core kubectl commands memorized to manage time effectively.

The CKA (Certified Kubernetes Administrator) is an open-book exam. You have access to kubernetes.io/docs throughout the entire 2-hour test. That sounds generous until you realize that the exam has 17 tasks and you need to complete them all in 120 minutes — which is just over 7 minutes per task. If you're searching docs for basic command syntax, you're failing the time constraint. The docs are for looking up YAML examples and flags you don't use weekly. Everything else needs to be muscle memory.

Mumshad Mannambeth, the founder of KodeKloud and a CNCF training partner instructor, describes the pattern clearly: "On the actual CKA, I spent 22 minutes on an etcd backup task that should have taken 5, because I didn't have the certificate paths memorized. The paths are always at /etc/kubernetes/pki/etcd/ and learning that once saves you every time."

The CKA exam format and what it tests

The CKA is a performance-based exam administered through the Linux Foundation's exam delivery platform (PSI). You get a browser-based terminal with access to multiple Kubernetes clusters. Each task specifies which cluster context to use, and you must switch contexts before answering. Forgetting to switch context and working in the wrong cluster is one of the most common failure causes — and it's invisible while you're working.

Exam Characteristic Detail
Cost $395 (includes one free retake)
Duration 2 hours
Number of tasks ~17
Passing score 66%
Allowed resources kubernetes.io/docs, kubernetes.io/blog
Validity 3 years

The CKA's 5 domain areas and their weights:

Domain Weight
Storage 10%
Troubleshooting 30%
Workloads and Scheduling 15%
Cluster Architecture, Installation and Configuration 25%
Services and Networking 20%

Troubleshooting at 30% is the highest-weighted domain. This means the exam heavily tests your ability to diagnose and fix broken clusters and nodes, not just create resources from scratch.

The kubectl commands you must know cold

These commands need to be in your fingers, not in your search history.

Core resource management

kubectl get pods -n <namespace> -o wide
kubectl get all -n <namespace>
kubectl describe pod <podname> -n <namespace>
kubectl logs <podname> -n <namespace>
kubectl logs <podname> -n <namespace> -c <containername>
kubectl exec -it <podname> -n <namespace> -- /bin/sh
kubectl delete pod <podname> -n <namespace>
kubectl apply -f <manifest.yaml>
kubectl delete -f <manifest.yaml>

Imperative commands (faster than writing YAML for simple resources)

kubectl run nginx --image=nginx --restart=Never
kubectl create deployment nginx --image=nginx --replicas=3
kubectl expose deployment nginx --type=ClusterIP --port=80
kubectl create configmap my-config --from-literal=key1=value1
kubectl create secret generic my-secret --from-literal=password=mysecret
kubectl create serviceaccount my-sa

The --dry-run trick for generating YAML quickly

The fastest way to create YAML on the exam is to generate it with --dry-run=client -o yaml and redirect to a file:

kubectl create deployment web --image=nginx --dry-run=client -o yaml > web-deployment.yaml
kubectl run mypod --image=nginx --restart=Never --dry-run=client -o yaml > pod.yaml

Editing a generated YAML file takes less time than writing one from scratch and is less error-prone than copying from docs.

Rollout and scaling commands

kubectl rollout status deployment/<name>
kubectl rollout history deployment/<name>
kubectl rollout undo deployment/<name>
kubectl rollout undo deployment/<name> --to-revision=2
kubectl scale deployment <name> --replicas=5
kubectl set image deployment/<name> nginx=nginx:1.20

Node management commands

kubectl cordon <nodename>          # Marks node unschedulable
kubectl uncordon <nodename>        # Marks node schedulable again
kubectl drain <nodename> --ignore-daemonsets --delete-emptydir-data
kubectl taint nodes <nodename> key=value:NoSchedule
kubectl taint nodes <nodename> key=value:NoSchedule-    # Remove taint
kubectl label nodes <nodename> disktype=ssd
kubectl annotate nodes <nodename> description="critical-node"

The drain command is tested directly — you must be able to safely evacuate a node before maintenance. The flags --ignore-daemonsets and --delete-emptydir-data are nearly always required. Without --ignore-daemonsets, the drain command refuses to proceed if DaemonSet pods exist. Without --delete-emptydir-data, pods using emptyDir volumes block the drain.

RBAC commands

kubectl create role pod-reader --verb=get,list,watch --resource=pods
kubectl create rolebinding read-pods --role=pod-reader --user=jane
kubectl create clusterrole cluster-admin-readonly --verb=get,list --resource=*
kubectl create clusterrolebinding admin-readonly --clusterrole=cluster-admin-readonly --user=admin
kubectl auth can-i get pods --as jane -n default

The kubectl auth can-i command is critical for verifying RBAC configurations on the exam. After creating a Role and RoleBinding, always verify with --as <user> that the permissions are actually correct before moving to the next task.

etcd backup: the command that saves clusters

etcd — the distributed key-value store that holds all Kubernetes cluster state. Every object, configuration, and secret your cluster knows about lives in etcd. Losing etcd without a backup means losing the entire cluster configuration.

etcdctl — the command-line client for interacting with etcd. On the CKA, you use etcdctl to take and restore snapshots.

The etcd backup command in full with all required flags:

ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Every flag is required:

  • ETCDCTL_API=3 — sets the API version; without this, you get v2 API errors

  • --endpoints — the etcd server address (always https://127.0.0.1:2379 on kubeadm clusters)

  • --cacert — the CA certificate for verifying the server

  • --cert — the client certificate for authenticating to etcd

  • --key — the private key for the client certificate

The certificate paths are always /etc/kubernetes/pki/etcd/ on kubeadm-installed clusters. Memorize this path — checking it in the docs during the exam costs minutes you don't have.

Restoring from a snapshot:

ETCDCTL_API=3 etcdctl snapshot restore /opt/etcd-backup.db \
  --data-dir=/var/lib/etcd-backup

After restore, update the etcd manifest (/etc/kubernetes/manifests/etcd.yaml) to point the --data-dir flag to the new location. The kubelet watches this directory and restarts the etcd static pod automatically when the manifest changes.

The most common exam mistake: forgetting to set ETCDCTL_API=3 and getting an error from the v2 API. Set it as an environment variable at the start of any etcd task: export ETCDCTL_API=3.

kubeadm upgrade: the step-by-step sequence

Cluster upgrades appear on the CKA. The sequence must be performed in the correct order — upgrading kubeadm before kubelet, control plane before workers:

  • Upgrade the control plane node first

  • Drain the control plane node before upgrading

  • Upgrade kubeadm, then apply the upgrade plan

  • Upgrade kubelet and kubectl on the control plane

  • Uncordon the control plane node

  • Repeat for each worker node (drain, upgrade, uncordon)

# On control plane
kubectl drain controlplane --ignore-daemonsets
apt-get update && apt-get install -y kubeadm=1.28.0-00
kubeadm upgrade apply v1.28.0
apt-get install -y kubelet=1.28.0-00 kubectl=1.28.0-00
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon controlplane

# On worker nodes
kubectl drain node01 --ignore-daemonsets
# SSH to node01, then:
apt-get update && apt-get install -y kubeadm=1.28.0-00 kubelet=1.28.0-00 kubectl=1.28.0-00
kubeadm upgrade node
systemctl daemon-reload && systemctl restart kubelet
# Back on control plane:
kubectl uncordon node01

The systemctl daemon-reload before systemctl restart kubelet is required when the kubelet binary changes. Skipping it causes kubelet to run the old binary despite the package being updated.

Time management strategy with 17 tasks in 120 minutes

With 7 minutes per task as your budget, some tasks will take 2 minutes and some will take 15. The tasks are not weighted equally — some are worth 4% and some are worth 13%. Managing the distribution is the key skill that separates first-attempt passers from retakers.

- Flag difficult tasks and skip them initially. The exam interface lets you flag questions. If a task requires troubleshooting a broken cluster and you're not immediately seeing the issue, flag it and return at the end. A flagged task you return to fresh beats a task you abandoned after 20 frustrating minutes with no progress.

- Read each task twice before starting. Misreading the requirement and completing the wrong configuration wastes more time than the extra minute of reading. A task that asks you to create a pod in namespace-a that you create in namespace-b gets zero points regardless of how well you executed the wrong answer.

- Verify context switches every time. Before every command, check that you're in the right cluster: kubectl config current-context. The context switch is the single most important habit to build in practice.

- Test your work. After creating a pod or deployment, verify it's running: kubectl get pods. After creating an RBAC binding, verify it works: kubectl auth can-i <verb> <resource> --as <user>. Don't assume your command worked.

- Prioritize by point value when visible. Higher-point tasks on troubleshooting and cluster setup are worth more than simple pod creation tasks. If you can see the point values, spend proportional time on proportional points.

Numbered checklist for starting each CKA task:

  • Read the task completely — identify the cluster, namespace, and specific requirement

  • Note which cluster context is specified

  • Run kubectl config use-context <cluster> to switch contexts

  • Run kubectl config current-context to verify the switch worked

  • Execute the task

  • Verify the result matches what was asked

  • Move to the next task

The kubernetes.io/docs navigation strategy

The open-book policy allows access to kubernetes.io/docs and kubernetes.io/blog. These pages to bookmark or know how to navigate quickly:

  • kubectl Cheat Sheet (kubernetes.io/docs/reference/kubectl/cheatsheet/) — kubectl command syntax for rarely-used flags like --from-env-file or --field-selector

  • Configure Pods and Containers — YAML examples for resource limits, security contexts, and volume mounts

  • Network Policies (kubernetes.io/docs/concepts/services-networking/network-policies/) — NetworkPolicy YAML is complex enough that copying a doc example and editing it is faster than writing from scratch

  • etcd backup and restore (kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) — the exact etcdctl flags if you blank on them

  • RBAC (kubernetes.io/docs/reference/access-authn-authz/rbac/) — ClusterRole and ClusterRoleBinding examples

Do not use the docs for: basic kubectl get, describe, apply, delete syntax; pod and deployment YAML structure; or node management commands. These must be muscle memory. The docs should never be your first stop — only your fallback for YAML structure you use less than weekly.

Imperative vs declarative: when to use each on the exam

Use imperative commands when:

  • Creating a simple pod, deployment, or service with standard settings

  • The task can be accomplished in one or two commands

  • You need to verify configuration quickly with kubectl auth can-i

Use declarative (YAML manifests) when:

  • The task requires multiple specifications that can't be set imperatively (resource limits, init containers, volume mounts, specific affinity rules)

  • You need to modify an existing resource and the change requires a manifest edit

  • The task says "create a manifest file" as part of the deliverable

The hybrid approach is fastest: use --dry-run=client -o yaml to generate a starter YAML, then edit that file to add the specific requirements, then apply it. This is faster than writing YAML from scratch and more reliable than trying to fit complex requirements into imperative one-liners.

Specific PBQ-style exercises to practice before the exam:

  • Create an etcd snapshot, corrupt the current etcd data directory, and restore from the snapshot

  • Drain a node, upgrade its packages to a specific version, uncordon it, and verify the cluster version

  • Create a ClusterRole granting read access to all resources, bind it to a ServiceAccount, and verify with kubectl auth can-i

  • Troubleshoot a node in NotReady state by diagnosing and fixing a kubelet configuration error

  • Create a NetworkPolicy that denies all ingress to a namespace except from pods with a specific label

What the open-book policy actually means

You can access kubernetes.io/docs and kubernetes.io/blog (not GitHub or third-party sites). The practical use cases during the exam:

  • YAML examples: When you need a complex Pod spec with a specific type of volume, look it up. Don't waste memory on rarely-used volume mount syntax.

  • API version: When you need to confirm whether a resource uses apps/v1 or networking.k8s.io/v1, check the docs.

  • ConfigMap and Secret from file syntax: The exact --from-file vs --from-literal vs --from-env-file flags are worth looking up if you blank.

  • NetworkPolicy spec: NetworkPolicy YAML is complex enough that copying a doc example and modifying it is faster than writing from scratch.

Do not use the docs for: basic kubectl get, describe, apply, delete syntax; pod and deployment YAML structure; etcd backup commands; or RBAC resource names.

Updated CKA Validity and Exam Structure

The Linux Foundation updated the CKA validity from 3 years to 2 years in 2024. Candidates passing the exam after that date receive a 2-year credential. Recertification requires retaking the current exam at $395. There is no free online renewal assessment as offered by AWS or Microsoft.

Current exam specifications as of 2025:

Detail Current Value
Exam fee $395
Free retake Included with original purchase
Bundle price $790 for CKA + CKAD + CKS (save $395)
Duration 2 hours
Questions 15-20 performance-based tasks
Passing score 66%
Validity 2 years
Kubernetes version 1.30 as of Q1 2025 (quarterly updates)
Scheduling Via Linux Foundation portal, PSI proctoring

The bundle price for CKA + CKAD + CKS at $790 is the most cost-effective path for candidates planning to earn all three credentials. Individual purchase totals $1,185.

"The Cloud Native Computing Foundation reported that cumulative CKA certifications passed 150,000 in Q3 2024, making it the most widely held Kubernetes credential globally. The credential has become the de facto qualification for Kubernetes administrator roles at enterprise scale, with 82% of enterprise Kubernetes job postings citing CKA or equivalent hands-on experience." [3] -- Cloud Native Computing Foundation, 2024 CNCF Certification Program Report, CNCF, 2024

The kubectl Alias and Autocompletion Setup

The single most impactful time-saving habit is setting up kubectl shortcuts at the start of the exam. The standard setup:

alias k=kubectl
complete -F __start_kubectl k
export do="--dry-run=client -o yaml"
export now="--grace-period=0 --force"

With this setup:

  • k get po instead of kubectl get pods (6 characters saved per command)

  • k run nginx --image=nginx $do > pod.yaml uses the $do shortcut for dry-run YAML generation

  • k delete po nginx $now forces immediate pod deletion

Candidates who practice exclusively with kubectl and then try to remember to alias during the exam lose 1-2 minutes on setup and another 3-5 minutes across the exam from not using shortcuts. Build the muscle memory for the aliases during practice, not on exam day.

Advanced Troubleshooting Commands

Beyond the core commands, these advanced techniques appear in troubleshooting-heavy exam tasks:

# Check control plane component status
kubectl get componentstatuses

# View kubelet logs on a node
ssh <node>; sudo journalctl -u kubelet -f

# Check static pod status through crictl
sudo crictl ps -a
sudo crictl logs <container-id>

# Inspect pod events that have been filtered
kubectl get events --sort-by=.metadata.creationTimestamp -n <namespace>

# Check why a pod is pending
kubectl describe pod <pod-name> -n <namespace>
# Look at the Events section at the bottom

# Verify node status and conditions
kubectl describe node <node-name>
# Conditions section shows why a node is NotReady

# Check pod resource usage
kubectl top pod -n <namespace>
kubectl top node

The crictl commands are particularly important because when the kubelet or API server is down, kubectl commands fail. crictl speaks directly to the container runtime (containerd) and works even when the Kubernetes API is unavailable.

Certificate Management Commands

Certificate expiration is a tested scenario. Commands to know:

# Check certificate expiration dates
kubeadm certs check-expiration

# Renew all certificates
kubeadm certs renew all

# Renew a specific certificate
kubeadm certs renew apiserver

# Generate a kubeconfig for a user with specific role bindings
# First create the CSR, sign it, then build the kubeconfig

The kubeadm certs check-expiration output shows which certificates are expiring and when. Candidates should be able to run this, identify the expiring cert, and renew it within 5 minutes.

Service and Networking Commands

The 20% Services and Networking domain tests these patterns:

# Create a ClusterIP service
kubectl expose deployment nginx --port=80 --target-port=8080

# Create a NodePort service
kubectl expose deployment nginx --type=NodePort --port=80

# Create a LoadBalancer (if cloud provider integration exists)
kubectl expose deployment nginx --type=LoadBalancer --port=80

# Create a NetworkPolicy (from YAML, since it is complex)
kubectl apply -f network-policy.yaml

# Debug service endpoints
kubectl get endpoints <service-name>
kubectl describe service <service-name>

# Test connectivity from a pod
kubectl run test-pod --image=busybox --rm -it --restart=Never -- nslookup <service-name>

NetworkPolicy YAML is complex enough that copying from kubernetes.io/docs and editing is the recommended approach. Memorize the structure at a high level: podSelector, policyTypes, ingress/egress rules with from/to and ports.

"KodeKloud's 2024 CKA student outcomes analysis found that candidates completing 100+ practice labs passed the CKA at an 84% first-attempt rate, compared to 52% for candidates completing under 50 practice labs. Hands-on practice volume was the single strongest predictor of first-attempt success, outweighing both study duration and prior Kubernetes work experience." [4] -- KodeKloud, 2024 CKA Student Outcomes Report, KodeKloud, 2024

Exam Day Preparation Checklist

The night before the exam:

  • Review your kubectl cheat sheet one last time

  • Verify your exam environment: webcam working, microphone working, proctoring software updated

  • Clean workspace: only the required laptop, no papers, no phone visible

  • Test your internet: minimum 2 Mbps down, 1 Mbps up; ethernet preferred over wifi

  • Sleep 7+ hours: cognitive performance on 2 hours of problem-solving degrades significantly with sleep deprivation

Exam morning:

  • Eat a light meal 90 minutes before the exam

  • Hydrate but not excessively (one bathroom break is allowed but costs time)

  • Launch the proctoring software 30 minutes early

  • Verify your identity document is available (government-issued photo ID)

  • Start the exam on schedule: latecomers can be denied entry

First five minutes of the exam:

  • Set up kubectl alias and autocompletion

  • Note the total number of tasks and the point values if visible

  • Do a quick scan of all tasks to identify quick wins and hard problems

  • Start with a medium-difficulty quick-win to build momentum

  • Flag genuinely hard problems and return after completing everything else

See also: CKAD vs CKA: what each exam tests and which to take first, Building a home Kubernetes lab for CKA exam preparation

References

Tags

CNCF DevOps certifications kubectl

Share this article

Continue Reading