Reinforce KCNA concepts with active-recall study cards covering all 5 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 KCNA preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the KCNA 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 KCNA 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 KCNA 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 KCNA.
Sample cards from the KCNA flashcard bank. Read the question, think of the answer, then read the explanation below.
A developer deploys a pod that continuously restarts. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?
The container is exceeding its memory limit and being OOM-killed.
Exit code 137 (128 + 9) indicates the container was killed by SIGKILL. In Kubernetes, this most commonly occurs when the container exceeds its memory limit, triggering the OOM (Out-Of-Memory) killer. The kubelet enforces the resource limits specified in the pod spec, and when memory usage surpasses the limit, the kernel terminates the process with SIGKILL, resulting in exit code 137.
A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?
All nodes are unreachable or have been cordoned.
The taint `node.kubernetes.io/unreachable` is automatically added by the node controller when a node becomes unreachable (e.g., network failure, kubelet stops heartbeating). The error shows all 4 nodes have this taint and the pod has no matching toleration, meaning the scheduler cannot place the pod. This directly indicates all nodes are unreachable or have been cordoned (which also adds the `node.kubernetes.io/unschedulable` taint, but here the specific taint is `unreachable`).
A team wants to minimize downtime during a Deployment rollout. Which strategy ensures that new pods are created before old pods are terminated?
Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=0.
Setting `maxSurge=1` and `maxUnavailable=0` in a RollingUpdate strategy ensures that one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees zero downtime by maintaining full capacity during the rollout, as new pods become ready before old ones are removed.
A developer creates a pod that needs to securely access a database password stored in the cluster. Which Kubernetes resource should be used to inject the password as an environment variable?
Secret
A Secret is the correct Kubernetes resource for injecting sensitive data like a database password into a Pod as an environment variable. Secrets store base64-encoded data and are designed specifically for confidential information, unlike ConfigMaps which store non-sensitive configuration. When mounted as environment variables, Secrets ensure the password is not exposed in plaintext in the Pod specification or image layers.
An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taints that the pod didn't tolerate, 3 nodes had insufficient memory'. What is the most likely issue?
The pod's resource requests exceed available memory on three nodes.
The scheduler event explicitly states '3 nodes had insufficient memory', which directly indicates that the pod's resource requests (specifically memory) exceed the available allocatable memory on those three nodes. The fourth node is unavailable due to taints, leaving zero schedulable nodes, hence the 'Pending' state.
A cluster has a node with the taint 'node-role.kubernetes.io/control-plane:NoSchedule'. A pod must be scheduled on this node for a special workload. Which action is required?
Add a toleration to the pod spec.
A taint on a node causes the scheduler to avoid placing pods on that node unless the pod explicitly tolerates the taint. By adding a toleration in the pod spec that matches the taint key, effect, and optionally the value, the pod becomes eligible to be scheduled on the tainted node. This is the standard Kubernetes mechanism for allowing pods to run on control-plane or other specially tainted nodes.
Refer to the exhibit. A pod 'my-pod' shows repeated 'BackOff' events after the container starts. Which is the most likely cause?
The application crashes shortly after starting.
The 'BackOff' event in Kubernetes indicates that the container has started but repeatedly crashes, causing the kubelet to increase the restart delay. Option D is correct because an application that crashes shortly after starting will trigger this restart loop, as the container exits with a non-zero exit code, leading to exponential backoff.
A team deploys a microservice that requires sticky sessions. The service runs on Kubernetes with multiple replicas. Which Kubernetes resource should be used to ensure requests from a client are consistently routed to the same pod?
Service with sessionAffinity: ClientIP
Setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.
A Kubernetes cluster is experiencing network latency. The team suspects that the number of services and endpoints is causing iptables performance degradation. Which CNI plugin or network policy approach is most likely to improve performance?
Use an eBPF-based CNI plugin like Cilium
C is correct because eBPF-based CNI plugins like Cilium bypass the traditional iptables chains entirely, using a kernel-level BPF (Berkeley Packet Filter) program to handle service load balancing and network policy enforcement. This eliminates the O(n) scaling issue of iptables rules with the number of services and endpoints, significantly reducing latency in large clusters.
A developer wants to ensure that a pod runs only on nodes with SSDs. Which mechanism should be used?
Add a nodeSelector with disktype: ssd
`nodeSelector` is a simple and direct mechanism in Kubernetes to constrain a pod to run only on nodes that have a specific label, such as `disktype=ssd`. By labeling nodes with SSDs and adding the corresponding `nodeSelector` in the pod spec, the scheduler ensures the pod is placed exclusively on those nodes. This approach is straightforward and does not require complex scheduling constraints or resource management.
A DevOps team notices that a new deployment of a web application is not receiving traffic even though the pods are running. The deployment has a selector matching the pod labels, and a Service of type ClusterIP exists. What is the most likely cause?
The Service's targetPort does not match the container's containerPort.
The most likely cause is that the Service's targetPort does not match the container's containerPort. In Kubernetes, a Service routes traffic to pods by forwarding packets to the port specified in the Service's `targetPort` field. If this does not match the `containerPort` defined in the pod's container spec, the traffic will be dropped because the kube-proxy will forward packets to a closed port on the pod, resulting in no connectivity even though the pods are running.
An administrator needs to ensure that Pods from two different Deployments cannot communicate with each other. Which Kubernetes resource should be used?
NetworkPolicy
NetworkPolicy is the correct resource because it acts as a firewall for Kubernetes Pods, controlling ingress and egress traffic at the IP address and port level using layer 3/4 rules. By applying a NetworkPolicy that denies all traffic between the Pods of the two Deployments (e.g., using podSelector and ingress/egress rules with an empty `from` or `to` block), the administrator can enforce network isolation. This is the native Kubernetes mechanism for restricting Pod-to-Pod communication within a cluster.
A cloud-native application is designed with multiple microservices that need to handle a sudden spike in traffic without manual intervention. Which Kubernetes feature best enables this?
HorizontalPodAutoscaler
The HorizontalPodAutoscaler (HPA) automatically scales the number of pod replicas in a deployment based on observed CPU/memory utilization or custom metrics. This directly addresses the need to handle a sudden traffic spike without manual intervention by adding more pod instances to distribute the load.
A team is designing a cloud-native system that must maintain high availability across multiple cloud regions. The application uses Kubernetes clusters in each region. Which approach best ensures that the system can tolerate a full region failure while minimizing complexity?
Use a global load balancer with active-passive regional failover
A global load balancer with active-passive regional failover provides a straightforward way to route traffic to a healthy secondary region when the primary fails, without the complexity of multi-region Kubernetes control planes or synchronous replication. This approach leverages DNS-based or anycast routing to detect region failure and redirect traffic, ensuring high availability while keeping the operational overhead low.
A platform team wants to implement observability for a Kubernetes cluster running 500+ microservices. They need to reduce the cost of storing logs while retaining the ability to search for specific error patterns. Which strategy best achieves this?
Use structured logging and sample debug logs, retaining error logs fully
Structured logging (e.g., JSON format) enables efficient indexing and querying of logs, while sampling debug logs and retaining error logs fully reduces storage costs without losing critical error patterns. This approach balances observability needs with cost optimization, a key principle in cloud-native environments.
A startup wants to minimize downtime during application updates in Kubernetes. Which deployment strategy should they use?
RollingUpdate
The RollingUpdate strategy is the default in Kubernetes and minimizes downtime by gradually replacing old Pods with new ones while the application remains available. It uses a configurable `maxSurge` and `maxUnavailable` parameters to control the rate of change, ensuring that a specified number of Pods are always serving traffic. This makes it ideal for startups seeking zero-downtime updates without the complexity of additional tooling or infrastructure.
The KCNA flashcard bank covers all 5 official blueprint domains published by CNCF. Cards are distributed proportionally, so domains with higher exam weight have more cards.
Domain Coverage
Kubernetes Fundamentals
Container Orchestration
Cloud Native Architecture
Cloud Native Observability
Cloud Native Application Delivery
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 KCNA 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.KCNA questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective KCNA 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 KCNA 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 930+ original KCNA flashcards across all 5 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 KCNA 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