Reinforce CKA concepts with active-recall study cards covering all 8 blueprint domains. Each card shows the question on the front and the correct answer with a full explanation on the back.
Flashcards work through active recall — the process of retrieving information from memory rather than passively re-reading it. Research consistently shows that active recall produces stronger, longer-lasting memory than re-reading study guides. For CKA preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the CKA question on each card, pause, and attempt to formulate the answer in your own words before revealing. This retrieval attempt — even if wrong — dramatically strengthens memory compared to immediately reading the answer.
Review wrong cards again
When you get a card wrong, note it and add it back to your review pile. Spaced repetition — seeing difficult cards more frequently — is the mechanism that makes flashcard study far more efficient than linear reading.
Study by domain
Group your CKA flashcard sessions by domain for the first 3–4 weeks. Master one domain before moving to the next. In the final week, shuffle all cards together to test cross-domain recall — which is what the real CKA exam requires.
Short sessions beat marathon reviews
20–30 flashcard cards per session, done daily, produces better retention than a single 200-card marathon session. Five short daily sessions per week over 4 weeks gives you over 400 total card reviews — enough to reliably pass CKA.
Sample cards from the CKA flashcard bank. Read the question, think of the answer, then read the explanation below.
Which control plane component is responsible for storing the cluster state and configuration?
etcd
etcd is the distributed key-value store that serves as the single source of truth for the entire cluster, storing all cluster state data such as configurations, secrets, service endpoints, and resource specifications. The kube-apiserver reads from and writes to etcd exclusively, making it the only component that directly persists the cluster's desired and current state.
A cluster was upgraded from v1.28 to v1.29 using kubeadm. After upgrading the control plane, nodes remain at v1.28. What is the correct next step to upgrade a worker node?
SSH into the worker node and run 'kubeadm upgrade node', then upgrade kubelet and kubectl, then restart kubelet.
After upgrading the control plane with kubeadm, worker nodes must be upgraded individually. The correct sequence is to SSH into the worker node, run 'kubeadm upgrade node' to upgrade the kubelet configuration and static pod manifests, then upgrade the kubelet and kubectl binaries (typically via the package manager), and finally restart the kubelet to pick up the new version. This ensures the node runs the same Kubernetes version as the control plane.
Which of the following service types exposes a service on a static port on each node's IP address?
NodePort
NodePort is the correct answer because it exposes a service on a static port (in the range 30000-32767) on every node's IP address. When you create a NodePort service, Kubernetes allocates a port from that range and opens that port on all nodes, forwarding traffic to the service's ClusterIP and then to the pods.
A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?
Increase the memory limit in the pod's container resource specification
The 'OOMKilled' status indicates the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.
A cluster uses a CSI driver for dynamic provisioning. An administrator creates a StorageClass with 'volumeBindingMode: WaitForFirstConsumer' and a PVC. The pod using the PVC is scheduled to a node. However, the PV is never provisioned. What is the most likely cause?
The CSI driver is not installed or malfunctioning.
When `volumeBindingMode: WaitForFirstConsumer` is set, the PV is not provisioned until a pod using the PVC is scheduled to a node. If the PV is never provisioned after scheduling, the most likely cause is that the CSI driver is not installed or malfunctioning, because the dynamic provisioning request is sent to the CSI driver, and without a functioning driver, the PV creation will fail silently or not occur at all.
Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?
kubectl logs api-6f4d7b9d4c-abcde -n production --previous
The pod is in CrashLoopBackOff, which means the container starts, crashes, and restarts repeatedly. The `kubectl logs --previous` command retrieves the logs from the previous (crashed) container instance, which is the fastest way to see the error that caused the crash. This directly reveals the root cause, such as a missing dependency, configuration error, or application panic.
You are a CKA managing a production cluster with 5 worker nodes. A developer reports that a new deployment 'payment-service' is not accessible from other pods via its Service 'payment-svc' in the 'default' namespace. The Service is of type ClusterIP with selector 'app: payment'. The deployment has 3 replicas, all showing 'Running' status. From a test pod, you run 'curl http://payment-svc:8080' and get 'Connection refused'. You verify that the pods are listening on port 8080 and the container's readiness probe passes. 'kubectl get endpoints payment-svc' shows no endpoints. 'kubectl describe svc payment-svc' shows the selector 'app=payment'. What is the most likely cause?
The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.
The most likely cause is that the pods' labels do not match the Service's selector. The Service 'payment-svc' uses selector 'app: payment', but the pods have label 'app: payment-service'. Since the selector does not match any pods, the Service's endpoints list is empty, causing 'Connection refused' when trying to reach the ClusterIP. The pods are running and listening on port 8080, but the Service has no backends to forward traffic to.
Based on the exhibit, what is the most likely cause of the pod not running?
The Secret 'my-secret' does not exist in the namespace.
The pod's status indicates it is waiting for a secret to be mounted, and the error message 'secret "my-secret" not found' directly points to the missing Secret resource. Without the Secret existing in the same namespace as the pod, the volume mount fails, preventing the pod from starting.
A pod has status 'Init:Error'. What does this indicate?
An init container failed
The 'Init:Error' status indicates that a pod's init container has failed to complete successfully. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, the pod enters this error state. This is distinct from a main container crash, which would show as 'CrashLoopBackOff' or 'Error' after the pod has started.
A pod is running but cannot be accessed via its ClusterIP service from another pod in the same namespace. The service endpoints list shows the pod's IP. What is the most likely cause?
A NetworkPolicy is blocking the traffic
A NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.
A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?
The bootstrap token used for TLS bootstrapping has expired.
The bootstrap token used for TLS bootstrapping has expired. During the TLS bootstrap process, the kubelet uses a limited-time bootstrap token to authenticate with the API server and request a client certificate. If the token expires before the kubelet completes registration, the kubelet will fail to obtain the bootstrap CA certificate and cannot join the cluster, as indicated by the error 'Failed to get bootstrap CA certificate'.
An administrator is tasked with setting up a new Kubernetes cluster using kubeadm. They have two nodes: one control plane and one worker. After initializing the control plane with 'kubeadm init', the worker node fails to join with the error 'error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running'. What should the administrator check first?
Ensure that containerd is installed and running on the worker node.
The error 'container runtime is not running' on the worker node indicates that the CRI (Container Runtime Interface) implementation, typically containerd, is not active. Since kubelet relies on a running container runtime to manage pods, the administrator must first check that containerd is installed and running on the worker node using commands like 'systemctl status containerd' or 'systemctl start containerd'.
A developer wants to deploy a pod that will run only once to initialize a database schema. Which Kubernetes resource should they use?
Job
A Job is the correct Kubernetes resource for a one-time task that runs to completion, such as initializing a database schema. Unlike controllers that maintain a desired number of replicas, a Job creates one or more Pods and ensures they successfully terminate, making it ideal for batch or initialization workloads.
A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?
db-service.backend.svc.cluster.local
Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).
The CKA flashcard bank covers all 8 official blueprint domains published by CNCF. Cards are distributed proportionally, so domains with higher exam weight have more cards.
Domain Coverage
Cluster Architecture, Installation and Configuration
Services and Networking
Workloads and Scheduling
Storage
Troubleshooting
Cluster Architecture, Installation & Configuration
Workloads & Scheduling
Services & Networking
Both flashcards and practice questions are evidence-based study tools. The difference is in what they train:
Flashcards — concept retention
Best for memorising definitions, acronyms, protocol behaviours, command syntax, and conceptual distinctions. Use flashcards to build the foundational vocabulary that CKA questions assume you know.
Best in: weeks 1–3
Practice tests — application
Best for applying concepts to realistic scenarios, eliminating distractors, and building exam stamina.CKA questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective CKA study plan combines both: use flashcards for the first 2–3 weeks to build conceptual foundations, then shift to practice tests and mock exams in the final 2–3 weeks to apply and benchmark that knowledge. Most candidates who pass on their first attempt use both tools.
Yes. Courseiva provides free CKA flashcards across all official exam domains. Every card includes the correct answer and a full explanation of why it is right and why the distractors are wrong. The platform also includes topic-based practice, mock exams, and readiness tracking — no account required.
Courseiva has 302+ original CKA flashcards across all 8 exam blueprint domains. New cards are added regularly as the question bank grows. All cards are written by certified engineers against the official CNCF exam objectives.
Courseiva flashcards are purpose-built for IT certification exams. Unlike generic flashcard platforms where content quality varies, every Courseiva card is mapped to the official CKA exam blueprint, written by engineers who hold the certification, and includes a full explanation of the correct answer and why the distractors are wrong. This explanation quality is what separates genuine learning from rote memorisation.
Courseiva is a web platform — an internet connection is required. For offline study, we recommend creating free Courseiva account, using the platform in your browser, and using your device's offline capabilities if your browser supports offline web apps.
Save your results, see which domains need more work, and get spaced repetition recommendations — all free.
Sign Up FreeFree forever · Every certification included