Reinforce CKAD 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 CKAD preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the CKAD 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 CKAD 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 CKAD 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 CKAD.
Sample cards from the CKAD flashcard bank. Read the question, think of the answer, then read the explanation below.
A team is deploying a microservice that requires initialization of a database schema before the main application starts. The init container must run a script that writes to a shared volume. Which configuration correctly ensures the init container completes before the main container runs?
Define an init container with the script and mount the shared volume to both init and main containers.
Option C is correct because an init container runs to completion before any main container in the Pod starts, ensuring the database schema script finishes. By mounting the shared volume to both the init container and the main container, the script's output (e.g., schema files) is available to the main application when it launches.
A developer wants to deploy a stateless application as a set of identical pods. They need the pods to be distributed across nodes and have stable network identities. Which resource should they use?
StatefulSet
StatefulSet is the correct resource because it provides each pod with a stable, unique network identity (e.g., pod-name-0, pod-name-1) that persists across rescheduling. While Deployment manages replicas for stateless applications, it does not assign per-pod stable hostnames. The question explicitly requires 'stable network identities' for identical pods, which is a defining feature of StatefulSet. A Service combined with a Deployment gives a stable endpoint for the set, not per-pod identities.
A pod named 'web-app' is running but has no environment variables. The developer wants to inject a variable 'DB_URL=postgres://db:5432' from a ConfigMap named 'db-config'. Which pod spec snippet correctly achieves this?
env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: DB_URL
Option D is correct because it uses the `configMapKeyRef` field under `valueFrom` to inject a specific key from a ConfigMap as an environment variable. This allows the pod to consume the `DB_URL` value from the `db-config` ConfigMap without exposing it as a file or using `envFrom`.
A pod named 'web-app' is experiencing high CPU usage. You want to investigate which process inside the container is consuming the most CPU. Which command should you run?
kubectl exec web-app -- top
Option B is correct because `kubectl exec web-app -- top` runs the `top` command inside the container of the pod 'web-app', which displays real-time process-level CPU usage. This allows you to identify the specific process consuming the most CPU, directly addressing the question's requirement to investigate inside the container.
A developer deploys a set of Pods labeled app=frontend and wants to expose them internally within the cluster on a stable IP. Which resource should be used?
Service of type ClusterIP
A Service of type ClusterIP exposes the Pods on a stable internal IP address that is only reachable within the cluster. This is the default Service type and is ideal for internal communication between components, such as a frontend being accessed by a backend, without exposing the service outside the cluster.
During a canary deployment, you want to send 10% of traffic to the new version. You have two Deployments: 'app-stable' (version: stable) and 'app-canary' (version: canary). You use a Service with label selector 'app: myapp' and a second selector for version. How can you achieve the 10% traffic split?
Use an Ingress controller that supports canary deployments or a service mesh
Option A is correct because Kubernetes Services alone cannot perform weighted traffic splitting based on replica counts; they use round-robin load balancing at the pod level. To achieve a precise 10% traffic split, you need an Ingress controller (e.g., NGINX Ingress with canary annotations) or a service mesh (e.g., Istio with VirtualService) that supports weighted routing between two different Services or subsets. This allows you to direct a specific percentage of traffic to the canary version independently of replica counts.
A headless service is created with 'clusterIP: None'. What is the primary use case for such a service?
To allow direct pod-to-pod DNS resolution for StatefulSets.
A headless service (clusterIP: None) is primarily used with StatefulSets to enable direct pod-to-pod DNS resolution. Instead of a single virtual IP, the DNS returns the individual pod IPs (A/AAAA records) or SRV records, allowing each pod to be addressed by its stable network identity (e.g., pod-name.service-name.namespace.svc.cluster.local). This is essential for stateful applications like databases that require stable peer discovery.
You need to allow ingress traffic to pods with label 'app: web' from pods with label 'role: frontend' in the same namespace, and also from any pod in namespace 'monitoring'. Which NetworkPolicy egress/ingress rule correctly implements this?
spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend - namespaceSelector: matchLabels: name: monitoring
Option C is correct because it defines two separate ingress rules: one allowing traffic from pods with label 'role: frontend' in the same namespace, and another allowing traffic from any pod in namespace 'monitoring'. In Kubernetes NetworkPolicy, when multiple items are listed under 'from' in an ingress rule, they are ORed; however, here each rule is independent, so the first rule matches pods with 'role: frontend' (no namespaceSelector, so same namespace), and the second rule matches all pods in the 'monitoring' namespace (no podSelector, so all pods). This satisfies the requirement.
An Ingress resource uses the annotation 'kubernetes.io/ingress.class: nginx'. However, traffic is not being routed. The cluster has multiple ingress controllers. What is the most likely cause?
The annotation is deprecated; use spec.ingressClassName instead.
The annotation `kubernetes.io/ingress.class` is deprecated in Kubernetes 1.18+ and removed in 1.25+. The correct approach is to use `spec.ingressClassName` in the Ingress spec, which references an `IngressClass` resource. Since the cluster has multiple ingress controllers, the deprecated annotation may be ignored or not processed by the intended controller, causing traffic not to be routed.
A pod in namespace 'default' cannot resolve the service name 'db' in namespace 'data'. Which DNS name should the pod use to reach the service?
db.data.svc.cluster.local
Option C is correct because Kubernetes DNS resolves a service in another namespace using the format <service>.<namespace>.svc.cluster.local. Since the service is named 'db' in namespace 'data', the fully qualified domain name (FQDN) is db.data.svc.cluster.local. This allows cross-namespace service discovery without needing to modify the pod's DNS configuration.
A developer wants to containerize a Node.js application. The Dockerfile should first copy only package.json and package-lock.json, run npm install, then copy the rest of the source code. Which Dockerfile best achieves this?
COPY package*.json /app/\nRUN npm install\nCOPY . /app/
Option C is correct because it first copies only package.json and package-lock.json (using a wildcard pattern), runs `npm install` to leverage Docker's layer caching, and then copies the rest of the source code. This ensures that subsequent builds only re-run `npm install` when the dependency files change, not on every source code modification, which is a best practice for efficient Docker builds.
Which of the following Dockerfile instructions is used to set a command that runs when the container starts and can be overridden by command-line arguments?
CMD
The CMD instruction in a Dockerfile provides default command(s) for the executing container. When a user runs `docker run image [COMMAND]`, the provided COMMAND overrides the CMD value, making it the correct choice for a command that can be overridden by command-line arguments.
A developer wants to debug a container that has crashed and is no longer running. Which command allows them to start an ephemeral container in the same pod for debugging?
kubectl debug -it <pod> --image=busybox --target=<container>
Option B is correct because `kubectl debug` with the `-it` flag and `--image=busybox` creates an ephemeral container in the same pod as the crashed container, allowing debugging without restarting the pod. The `--target` flag specifies the crashed container to attach the ephemeral container to its namespace (e.g., network, process namespace), which is essential for debugging a container that is no longer running.
You want to configure a pod so that it receives a SIGTERM signal and has 60 seconds to shut down gracefully before being forcefully killed. Which field should you set?
terminationGracePeriodSeconds: 60
The `terminationGracePeriodSeconds` field in the Pod spec defines the duration (in seconds) that Kubernetes waits after sending a SIGTERM to the primary container process before sending a SIGKILL. Setting it to 60 gives the pod 60 seconds to shut down gracefully, which is exactly what the question requires.
A pod has been scheduled on a node but is stuck in 'ContainerCreating' state. The team suspects a missing storage class. Which command would best confirm this?
kubectl describe pod <pod>
Option D is correct because `kubectl describe pod <pod>` provides detailed event logs and status conditions for the pod, including specific error messages like 'failed to provision volume with StorageClass' or 'storageclass.storage.k8s.io "<name>" not found'. This directly confirms whether a missing storage class is the root cause of the 'ContainerCreating' state, as the pod's events will surface the exact provisioning failure.
An Ingress resource has the following spec: spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 What will the Ingress controller do for a request to http://example.com/api/v1/users?
Route the request to api-service on port 80.
The Ingress rule uses `pathType: Prefix` and a path of `/api`, which matches any request whose URL path begins with `/api`. The request to `http://example.com/api/v1/users` starts with `/api`, so the Ingress controller routes it to `api-service` on port 80. This is the standard behavior defined by the Kubernetes Ingress specification for prefix-based path matching.
You have a pod with two containers: one runs a web server, and the other is a sidecar that logs the web server's output to a central logging system. Which pattern does this represent?
Sidecar pattern
The sidecar pattern involves deploying a helper container alongside the main application container within the same pod. In this scenario, the sidecar container consumes the web server's logs (e.g., by tailing a shared volume or reading stdout/stderr) and forwards them to a central logging system, such as Elasticsearch or Fluentd. This pattern is a core Kubernetes design principle for extending or enhancing the main container without modifying its code.
A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?
Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext
The container process runs as a non-root user (UID 1000) and needs to bind to a privileged port (below 1024). Linux requires either root privileges or the CAP_NET_BIND_SERVICE capability to bind to ports below 1024. Adding this capability to the container's securityContext grants the process the necessary privilege without running as root, which is the correct and secure approach.
Given the following NetworkPolicy YAML: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress What is the effect of this policy?
Denies all ingress and egress traffic to and from all pods in the namespace
This NetworkPolicy uses an empty `podSelector: {}` which selects all pods in the namespace. By specifying both `Ingress` and `Egress` in `policyTypes` without any `ingress` or `egress` rules, the policy defaults to denying all ingress and egress traffic. In Kubernetes, NetworkPolicy rules are additive (allow-listed), so an empty rules list means no traffic is permitted, effectively creating a default-deny for both directions.
A developer reports that a container in a pod is not responding correctly. You need to get an interactive shell in the container to investigate. Which command should you run?
kubectl exec -it <pod> -- /bin/bash
Option B is correct because `kubectl exec -it <pod> -- /bin/bash` attaches an interactive terminal to a running container within an existing pod, allowing direct shell access for debugging. The `-it` flags enable interactive mode with a TTY, and `/bin/bash` starts a shell if available in the container image. This is the standard method for troubleshooting a container that is already deployed and running.
You have a Deployment named 'web' with label 'app: web'. You want to create a Service that exposes the Deployment on port 80 internally within the cluster. Which kubectl command achieves this?
kubectl expose deployment web --port=80
Option D is correct because `kubectl expose deployment web --port=80` creates a ClusterIP Service that selects Pods based on the Deployment's label selector (app: web) and exposes port 80 internally within the cluster. This command directly maps the Deployment's Pods to a Service without requiring manual specification of the target port or protocol, defaulting to TCP.
A developer configures a liveness probe for a container that takes a long time to start (about 120 seconds). The probe uses httpGet on port 8080 with a path '/healthz'. The probe is configured with initialDelaySeconds=10, periodSeconds=10, failureThreshold=3. The pod enters CrashLoopBackOff. What is the MOST likely cause?
The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container
The liveness probe is configured with initialDelaySeconds=10, which means Kubernetes will start probing 10 seconds after the container starts. Since the application takes about 120 seconds to become healthy, the probe will fail immediately. With failureThreshold=3 and periodSeconds=10, the probe will fail after 30 seconds (3 * 10s), causing Kubernetes to restart the container before it has finished initializing, leading to CrashLoopBackOff.
Which of the following commands creates a ClusterIP service named 'my-service' that exposes port 80 on the pod with label 'app=web'?
kubectl expose deployment my-deployment --port=80 --name=my-service
Option A is correct because `kubectl expose deployment my-deployment --port=80 --name=my-service` creates a ClusterIP service by default, which selects pods based on the labels of the deployment (e.g., `app=web` if the deployment has that label). The `--port=80` flag sets the service port, and the service automatically maps to the container port (defaults to the same port if `--target-port` is omitted). This command satisfies the requirement of exposing port 80 on pods with label `app=web`.
The CKAD 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
Application Design and Build
Application Deployment
Application Environment, Configuration and Security
Application Observability and Maintenance
Services and 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 CKAD 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.CKAD questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective CKAD 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 CKAD 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 991+ original CKAD flashcards across all 5 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 CKAD 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