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.
A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?
The CoreDNS deployment has 0 ready replicas.
When dnsPolicy is ClusterFirst, the pod's DNS queries are forwarded to the cluster's DNS service (CoreDNS by default). If the CoreDNS deployment has 0 ready replicas, the DNS service has no backend endpoints to handle queries, causing all DNS resolutions to fail. This is the most direct and common cause of complete DNS failure in a cluster.
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.
You are tasked with troubleshooting a production Kubernetes cluster. A user reports that they cannot access a web application running in the cluster. The application is deployed as a Deployment named 'frontend' with 2 replicas, exposed via a Service of type LoadBalancer. You have kubectl access to the cluster. You run 'kubectl get pods -l app=frontend' and see both pods are Running and Ready. You run 'kubectl get svc frontend' and see the Service has an external IP of 192.168.1.100. However, when you curl http://192.168.1.100 from a machine outside the cluster, you get a connection timeout. You are able to curl the pod IPs directly from within the cluster and get a response. Which of the following is the most likely cause of the issue?
The cloud provider's load balancer is not properly configured or the security group/firewall is blocking traffic to the node ports.
The pods are running and ready, and the service has an external IP, but external access fails with a connection timeout while internal access to pod IPs works. This indicates the cloud provider's load balancer is not properly routing traffic to the node ports, or a security group/firewall is blocking inbound traffic on the node port range (30000-32767). The load balancer must forward traffic to the node ports, and the nodes must allow that traffic.
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.
An administrator creates a ServiceAccount named 'monitor' in the 'default' namespace. They want any pod using this ServiceAccount to be able to list pods cluster-wide. Which RBAC resource should be created and bound to this ServiceAccount?
ClusterRole and ClusterRoleBinding
A ClusterRole is required because listing pods cluster-wide is a cluster-scoped operation, not limited to a single namespace. A ClusterRoleBinding is needed to bind the ClusterRole to the ServiceAccount 'monitor' at the cluster level, granting permissions across all namespaces. RoleBindings can only grant permissions within a single namespace, so they cannot achieve cluster-wide access.
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.
Which kubectl command will show the rollout history of a Deployment named 'web-app'?
kubectl rollout history deployment web-app
`kubectl rollout history deployment web-app` is the dedicated command to display the rollout history of a Deployment, including revision numbers and change-cause annotations. This command retrieves the stored ReplicaSet revisions associated with the Deployment, allowing you to see past rollout states.
A DevOps team needs to provide persistent storage to a set of pods that all require read-write access to the same data simultaneously. Which volume type should they use?
PersistentVolumeClaim with ReadWriteMany
A PersistentVolumeClaim with ReadWriteMany (RWX) is the correct choice because it allows multiple pods to mount the same volume simultaneously with read-write access. This access mode is supported by network-based storage backends like NFS, GlusterFS, or CephFS, which provide the necessary concurrency controls for shared access across pods.
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'.
A Kubernetes cluster has been running for months. Recently, some pods are reporting 'FailedScheduling' due to insufficient memory. The administrator wants to add a new node with 32GB RAM. However, after joining the node, the new node shows 'NotReady' and the kubelet logs indicate 'Failed to update node status: context deadline exceeded'. What is the most likely cause?
There is a network connectivity issue between the new node and the control plane.
The 'context deadline exceeded' error in the kubelet logs indicates that the kubelet on the new node is unable to communicate with the API server within the expected timeout. This is typically caused by network connectivity issues between the node and the control plane, such as firewall rules, incorrect DNS resolution, or a broken CNI plugin. Without successful node-to-API-server communication, the kubelet cannot post its status, leaving the node in 'NotReady' state.
A Kubernetes cluster has a deployment with 3 replicas. After a node failure, you notice that only 2 pods are running, and the deployment has not rescheduled the missing pod. What is the most likely cause?
The node controller has not yet evicted the pod
When a node fails, the node controller marks the node as `NodeReady=False` and waits for a configurable timeout (`pod-eviction-timeout`, default 5 minutes) before evicting pods. Until eviction, the deployment's ReplicaSet sees the pod as still existing (though on an unreachable node) and does not create a replacement. Option C correctly identifies that the node controller has not yet evicted the pod, which is the default behavior.
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
Troubleshooting
Cluster Architecture, Installation and Configuration
Services and Networking
Workloads and Scheduling
Storage
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 726+ original CKA flashcards across all 8 exam blueprint domains. New cards are added regularly as the question bank grows. All cards are checked against the official CNCF exam objectives, with editorial oversight from an experienced network and security engineer.
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