CKA Practice Test.
65 free practice questions with answers and explanations.
No signup required. Choose a topic and review each answer.
Start practicing →About these practice questions
These are original study questions written from published exam objectives—not recalled, copied, or confidential live-exam items. Always confirm current coverage with the official sources linked on this page.
Exam format and study resources
The CKA is administered by Cloud Native Computing Foundation (CNCF), in collaboration with The Linux Foundation, with a 2 hours time limit and a passing score of 66%.
This free CKA practice test has 65 original questions written to Cloud Native Computing Foundation (CNCF), in collaboration with The Linux Foundation's official content outline, last checked against it on July 18, 2026. Every question shows a worked explanation, and nothing here requires a signup.
As of 2026, the CKA exam fee is $445.
Browse all questions & answers
1. A cluster administrator wants a new control plane node's kubelet and kube-proxy to trust the API server automatically after running kubeadm join. Which artifact makes this trust possible without manual certificate exchange?
- A. A shared bootstrap token combined with the cluster CA certificate hash presented to kubeadm join
- B. An SSH key pair copied from the first control plane node
- C. A Kubernetes Secret of type kubernetes.io/basic-auth created in the default namespace
- D. A wildcard DNS record pointing to the API server load balancer
Show answer & explanation
Answer: A
kubeadm join uses a bootstrap token plus a CA certificate hash (discovery-token-ca-cert-hash) so the joining node can verify the API server and the API server can verify the joining node's TLS bootstrap request, after which the kubelet is issued a proper client certificate. SSH keys have nothing to do with Kubernetes API trust, basic-auth Secrets are not part of standard kubeadm bootstrap trust, and DNS records only route traffic, they do not establish cryptographic trust.2. During a cluster upgrade planned with kubeadm, which component version relationship must be respected to avoid an unsupported configuration?
- A. kubelet versions may be newer than the API server version by any number of minor versions
- B. kube-proxy must always be exactly two minor versions behind kubelet
- C. etcd must be upgraded only after every node's kubelet has been upgraded
- D. kubelet on each node must not be newer than the kube-apiserver version, and should be no more than a few minor versions older
Show answer & explanation
Answer: D
Kubernetes version skew policy requires kubelet to be no newer than kube-apiserver, and within the supported number of minor versions older, to guarantee API compatibility. Kubelets newer than the API server are unsupported, kube-proxy does not follow a fixed two-version offset rule, and etcd upgrades are governed by their own compatibility matrix independent of kubelet upgrade order.3. An administrator needs to back up the state of a kubeadm-managed cluster so it can be restored after a catastrophic control plane failure. What must be captured to ensure all cluster objects can be recovered?
- A. A tar archive of /var/lib/kubelet on every worker node
- B. A consistent snapshot of the etcd data store
- C. The contents of the kube-apiserver container image
- D. A copy of the kubeconfig file used by kubectl
Show answer & explanation
Answer: B
etcd is the single source of truth for all cluster state (objects, secrets, configuration), so a consistent etcdctl snapshot save is what allows full cluster restoration. Worker node kubelet directories hold only local pod state, not cluster-wide objects; the apiserver image contains no cluster data; and a kubeconfig only holds client credentials and endpoint info, not cluster state.4. A candidate applies a new taint to a control plane node so that only specific pods can be scheduled there. Which pod-side field must match the taint for scheduling to be permitted on that node?
- A. nodeSelector referencing the node's hostname label
- B. An identical toleration in the pod spec matching the taint's key, value, and effect
- C. A resource limit equal to the node's allocatable capacity
- D. An ownerReference pointing to the node object
Show answer & explanation
Answer: B
Taints repel pods unless the pod spec declares a matching toleration (same key, matching operator/value, and effect such as NoSchedule); tolerations permit scheduling but do not force it. A nodeSelector only targets nodes by label and does nothing to overcome a taint, resource limits are unrelated to taint logic, and pods do not use ownerReferences to nodes for scheduling.5. An admin wants to grant a CI/CD service account permission to create and delete Deployments only within the 'staging' namespace, and no other namespace. Which combination of objects accomplishes this correctly?
- A. A ClusterRole bound to the service account with a ClusterRoleBinding
- B. A Role scoped to the 'staging' namespace bound to the service account with a RoleBinding in that namespace
- C. A PodSecurityPolicy applied cluster-wide restricting the namespace field
- D. A NetworkPolicy limiting ingress to the staging namespace
Show answer & explanation
Answer: B
A namespaced Role paired with a RoleBinding is the correct RBAC primitive to grant permissions confined to a single namespace. A ClusterRole with a ClusterRoleBinding would grant the permission cluster-wide across all namespaces, PodSecurityPolicy (deprecated and unrelated to RBAC) governs pod security context rather than API verbs, and NetworkPolicy controls network traffic, not API authorization.6. A team wants every future Pod created in a namespace to automatically receive a specific toleration and an init container without modifying each manifest. Which mechanism is designed for this kind of automatic mutation at admission time?
- A. A LimitRange object in the namespace
- B. A MutatingAdmissionWebhook (or built-in mutating admission plugin) configured for that namespace
- C. A ResourceQuota object in the namespace
- D. A StorageClass marked as default
Show answer & explanation
Answer: B
Mutating admission webhooks intercept object creation requests and can inject or modify fields such as tolerations and init containers before persistence, which is exactly the described use case. LimitRange only constrains resource requests/limits, ResourceQuota caps aggregate resource consumption, and a default StorageClass only affects unspecified PVC storage class selection — none of these mutate arbitrary pod fields.7. An administrator inspects /etc/kubernetes/manifests/kube-apiserver.yaml on a control plane node and needs to change how long client certificates issued by the API server remain valid. What is the most direct supported approach?
- A. Restart the kubelet service on every worker node
- B. Edit the --client-ca-file flag to point to a different CA
- C. Run kubectl edit deployment kube-apiserver -n kube-system
- D. Modify the relevant certificate-related flags in the static pod manifest and let the kubelet restart the apiserver pod automatically
Show answer & explanation
Answer: D
Because kube-apiserver runs as a static pod, editing its manifest file in /etc/kubernetes/manifests triggers the local kubelet to detect the change and restart the pod with new flags — this is the supported way to change control plane component configuration in a kubeadm cluster. Changing --client-ca-file swaps the trusted CA rather than certificate validity duration, kube-apiserver is not a Deployment so 'kubectl edit deployment' would fail, and restarting worker kubelets has no effect on the control plane's static pod.8. A Deployment specifies 'replicas: 4' and a rolling update strategy with maxUnavailable=1 and maxSurge=1. During a rollout of a new image, what is the primary guarantee this strategy provides?
- A. All 4 old pods are terminated simultaneously before any new pod starts
- B. At most one pod can be unavailable and at most one extra pod can exist above the desired count at any point during the rollout
- C. The rollout pauses indefinitely until an administrator manually approves each pod replacement
- D. New pods only start after all old pods pass a readiness gate defined in a separate Job
Show answer & explanation
Answer: B
maxUnavailable and maxSurge bound how many pods can be down and how many extra can be created simultaneously during a rolling update, which is what enables zero-downtime updates for adequately replicated workloads. Simultaneous termination of all pods describes a Recreate strategy, not RollingUpdate; there is no built-in manual-approval pause without an external gate; and rolling updates do not depend on a separate Job resource for pod replacement.9. A Pod's container regularly crashes shortly after startup because a downstream dependency isn't ready yet, and Kubernetes keeps restarting it with increasing delay between attempts. What is this restart behavior called?
- A. Liveness probe failure escalation
- B. CrashLoopBackOff, where the kubelet increases the delay between restart attempts exponentially
- C. Eviction due to node pressure
- D. Preemption by a higher-priority pod
Show answer & explanation
Answer: B
CrashLoopBackOff is the kubelet's exponential backoff behavior for a container that repeatedly exits, increasing wait time between restarts up to a cap to avoid hammering the node. A liveness probe failure can trigger a restart but 'liveness probe failure escalation' is not the name of the backoff mechanism itself, node-pressure eviction removes pods rather than restarting containers in place, and preemption is about the scheduler removing lower-priority pods to fit a new one, unrelated to container crash restarts.10. A workload must run exactly one copy of a logging agent pod on every node in the cluster, including nodes added later. Which controller is purpose-built for this requirement?
- A. Deployment with replicas set to the current node count
- B. DaemonSet
- C. StatefulSet with a headless Service
- D. Job with parallelism set to the node count
Show answer & explanation
Answer: B
A DaemonSet ensures exactly one pod copy runs on each (matching) node and automatically extends to newly added nodes, which is exactly the stated requirement. A Deployment with a fixed replica count does not track node count changes and provides no per-node guarantee, StatefulSet is designed for stable identity and storage for stateful apps rather than per-node placement, and a Job runs pods to completion rather than as continuously running per-node daemons.11. A container needs a value that changes per environment (e.g., a database hostname) without rebuilding the image, and the value should be easy to update independently of the Pod spec. Which approach best fits this requirement?
- A. Hardcode the value as an environment variable directly in the container image
- B. Reference a ConfigMap key as an environment variable or mounted volume in the Pod spec
- C. Store the value in a Secret encoded only in base64 for readability
- D. Pass the value as a command-line flag to kubectl apply
Show answer & explanation
Answer: B
ConfigMaps externalize non-sensitive configuration from the image and can be referenced by Pods via env vars or volume mounts, letting the same image be reused across environments by swapping the ConfigMap. Hardcoding in the image defeats the goal of environment independence and requires rebuilds, Secrets are meant for sensitive data (base64 is encoding, not the defining reason to use a Secret) so using one for a non-sensitive hostname is not best practice, and kubectl apply flags don't persist as part of a Pod's declarative config.12. A Pod defines a container with resources.requests.cpu: 250m and resources.limits.cpu: 500m. What does this configuration mean for scheduling and runtime behavior?
- A. The scheduler guarantees exactly 500m CPU is reserved and the container is killed if it ever uses less than 250m
- B. The scheduler uses the 250m request to find a node with enough allocatable CPU, and the kernel throttles the container if it tries to exceed the 500m limit
- C. The container will be OOMKilled if it exceeds 500m CPU usage
- D. Requests and limits apply only to memory, not CPU, so this field is ignored
Show answer & explanation
Answer: B
CPU requests inform scheduling placement (finding a node with enough allocatable capacity) while CPU limits are enforced via CFS throttling rather than termination, since CPU is a compressible resource. There is no requirement to use at least the request amount, OOMKill applies to memory limit violations (an incompressible resource) not CPU, and CPU requests/limits are fully valid and commonly used fields, not memory-only.13. A Job manifest sets 'completions: 5' and 'parallelism: 2' without specifying a completion mode. What behavior should the administrator expect?
- A. 5 pods run concurrently at all times until all succeed
- B. Up to 2 pods run concurrently at a time, and the Job continues creating new pods until 5 have completed successfully in total
- C. Exactly 2 pods run once each and the Job is marked complete regardless of the completions field
- D. The Job creates 5 pods immediately and ignores the parallelism field entirely
Show answer & explanation
Answer: B
With completions and parallelism both set, the Job controller keeps at most 'parallelism' pods running concurrently while working toward the total 'completions' successful pod completions, replacing failed pods as needed. Running all 5 concurrently would ignore the parallelism cap, treating the Job as complete after only 2 successes would ignore the completions field, and parallelism is not ignored — it directly bounds concurrency.14. A cluster-internal application needs a stable virtual IP and DNS name that load-balances traffic across a dynamic set of backend Pods selected by label, without exposing it outside the cluster. Which Service type satisfies this exactly?
- A. ClusterIP
- B. NodePort
- C. LoadBalancer
- D. ExternalName
Show answer & explanation
Answer: A
ClusterIP is the default Service type providing a stable internal virtual IP and DNS name that load-balances across matching Pods, visible only within the cluster. NodePort additionally exposes a port on every node (external reachability), LoadBalancer provisions an external cloud load balancer, and ExternalName simply creates a DNS CNAME to an external name with no proxying or selector-based backend at all.15. An application Pod tries to reach another Service by its short name 'backend' instead of the fully qualified 'backend.namespace.svc.cluster.local' and it resolves correctly. What makes this possible?
- A. kube-proxy injects a HOSTS file entry for every Service into each Pod
- B. CoreDNS is configured with a search domain list in the Pod's /etc/resolv.conf that includes the Pod's namespace and cluster domain
- C. NetworkPolicy objects perform name resolution as a side effect of allowing traffic
- D. The Pod's container image bundles a static DNS zone file for the cluster
Show answer & explanation
Answer: B
Kubernetes populates each Pod's /etc/resolv.conf with search domains (namespace.svc.cluster.local, svc.cluster.local, cluster.local) so short names are expanded and resolved via CoreDNS, the cluster's DNS provider. kube-proxy handles Service IP load-balancing via iptables/IPVS rules, not DNS or hosts files; container images don't ship cluster DNS zone data; and NetworkPolicy only controls allowed traffic, it has no role in name resolution.16. By default, with no NetworkPolicy objects created in a namespace, what is the network traffic behavior between Pods in that namespace?
- A. Traffic is allowed only if both Pods share the same service account
- B. Only traffic within the same Deployment is allowed by default
- C. All ingress and egress traffic is allowed between Pods, since Kubernetes networking is unrestricted by default
- D. All traffic is denied until at least one NetworkPolicy explicitly allows it
Show answer & explanation
Answer: C
Kubernetes' default networking model is flat and permissive: without any NetworkPolicy resources selecting a Pod, all ingress and egress traffic is allowed, and policies exist to progressively restrict this. The 'deny by default' behavior only appears once a NetworkPolicy selects a Pod for a given direction; there's no default same-Deployment or same-service-account isolation built into core networking.17. A NetworkPolicy is created selecting Pods with label app=payments and specifies a single ingress rule allowing traffic from Pods labeled app=frontend on port 8080. What is the resulting effect on traffic to app=payments pods?
- A. Only ingress from app=frontend pods on port 8080 is allowed; all other ingress to those pods is now denied
- B. Egress from app=payments pods is also automatically restricted to app=frontend
- C. The policy has no effect unless a corresponding egress rule exists on the frontend pods
- D. All ingress remains allowed because NetworkPolicies only add exceptions, never restrictions
Show answer & explanation
Answer: A
Once any NetworkPolicy selects a Pod for the ingress direction, that direction becomes default-deny except for what the rules explicitly allow — here, only app=frontend on port 8080. Egress is a separate direction and is unaffected unless the policy also includes egress rules; policies apply independently per Pod selector, so a matching egress policy on the frontend side is not required for this ingress rule to take effect; and NetworkPolicies are inherently restrictive/allow-list based once applied, not purely additive to an already-open default.18. A Service of type NodePort is created for a Deployment. From outside the cluster, which of the following correctly describes how traffic reaches a backend Pod?
- A. External traffic must first pass through kube-scheduler before reaching kube-proxy
- B. A client connects to any cluster node's IP on the allocated NodePort, and kube-proxy forwards the connection to a healthy backend Pod, possibly on a different node
- C. External traffic can only reach Pods that are running on the specific node the client connects to
- D. NodePort Services require an Ingress controller to route any traffic at all
Show answer & explanation
Answer: B
NodePort opens the same port on every node; kube-proxy's rules (iptables/IPVS) forward incoming connections to any healthy matching Pod cluster-wide, regardless of which node it lives on. kube-scheduler is only involved in placing Pods, not in the data path of live traffic; NodePort does not require the traffic's destination Pod to reside on the contacted node; and NodePort works independently of any Ingress controller — Ingress is a separate, optional layer for HTTP(S) routing.19. An Ingress resource defines host-based routing rules for 'shop.example.com', but external clients report the domain does not route any traffic. What is the most likely missing piece?
- A. The Ingress object must be recreated as a NodePort Service
- B. An Ingress controller is not deployed or not watching Ingress resources in the cluster
- C. Ingress objects are automatically ignored unless TLS is configured
- D. DNS records are managed automatically by the Ingress API and never require external configuration
Show answer & explanation
Answer: B
The Ingress resource is only a routing specification; an Ingress controller (e.g., an nginx or cloud-provider controller) must be running and configured to watch and act on Ingress objects, or no traffic is ever routed. Ingress and Service are distinct resource types serving different purposes, so 'recreating as a NodePort' misunderstands the model; TLS is optional on Ingress and unrelated to whether routing occurs; and DNS records pointing to the ingress load balancer typically must be configured separately (or via external-dns), they are not automatically created by the Ingress API itself.20. A PersistentVolumeClaim requests 10Gi with accessMode ReadWriteOnce, and a matching PersistentVolume of 10Gi with the same accessMode already exists statically. What determines whether binding succeeds?
- A. Binding requires the PVC's storageClassName, accessModes, and capacity to be compatible with the PV, subject to any selector/label matching
- B. Binding is based solely on which PVC was created first in time, ignoring size or access mode
- C. PersistentVolumes can only bind to PersistentVolumeClaims in the same namespace as the PV
- D. Binding always requires a StorageClass with a provisioner, even for pre-provisioned PVs
Show answer & explanation
Answer: A
The binding process matches PVCs to PVs based on storage class, sufficient capacity, compatible access modes, and any selector/label constraints; the control loop picks the smallest suitable PV meeting these criteria. Creation order alone doesn't govern binding when multiple criteria must match; PersistentVolumes are cluster-scoped (not namespaced) so 'same namespace as the PV' is a category error; and statically provisioned PVs can bind with an empty or matching storageClassName without any provisioner being involved, since no dynamic provisioning happens in that path.21. A cluster uses a StorageClass with 'reclaimPolicy: Delete' for dynamically provisioned volumes. What happens to the underlying storage asset when the bound PersistentVolumeClaim is deleted?
- A. The PersistentVolume and its underlying storage are automatically deleted as well
- B. The PersistentVolume is retained indefinitely regardless of the reclaim policy
- C. The PersistentVolume is recycled by running a scrub Pod, a legacy option still active by default
- D. Deleting a PVC has no effect on the PersistentVolume under any reclaim policy
Show answer & explanation
Answer: A
With reclaimPolicy Delete, removing the PVC triggers deletion of both the PV object and its backing storage resource (e.g., the cloud disk), which is the default for most dynamically provisioned classes. 'Retain' is the policy that preserves the PV (and requires manual cleanup) after PVC deletion, not 'Delete'; the 'Recycle' reclaim policy is deprecated/removed in current Kubernetes and was never the default; and claiming PVC deletion never affects the PV contradicts the entire purpose of reclaim policies.22. A Pod mounts a volume backed by a PersistentVolumeClaim with accessMode ReadWriteOnce (RWO). A second Pod on a different node also references the same PVC. What should the administrator expect?
- A. Both Pods mount the volume simultaneously without restriction, since RWO only limits write access, not read access
- B. The second Pod will typically fail to schedule or mount, because RWO volumes can only be mounted read-write by a single node at a time
- C. Kubernetes automatically converts the volume to ReadWriteMany to satisfy both Pods
- D. The second Pod mounts successfully but all writes from the first Pod are silently discarded
Show answer & explanation
Answer: B
ReadWriteOnce restricts the volume to being mounted read-write by a single node at a time (and, depending on CSI driver/Kubernetes version nuances, effectively one Pod's node), so a second Pod scheduled to a different node will fail to attach/mount it. RWO is not a read-only-for-others mode; Kubernetes never silently upgrades a volume's access mode to RWX; and there is no mechanism that lets writes be silently discarded as a 'feature' of access mode conflicts — the mount attempt fails instead.23. An application needs its container's filesystem changes to persist only for the Pod's lifetime and be shared between two containers in the same Pod, without needing any external storage backend. Which volume type is appropriate?
- A. A PersistentVolumeClaim backed by network storage
- B. An emptyDir volume
- C. A hostPath volume pointing to a directory unique to one node
- D. A ConfigMap volume
Show answer & explanation
Answer: B
emptyDir is created when a Pod is assigned to a node, is shared across all containers in that Pod, and is deleted permanently when the Pod is removed, matching exactly the described transient shared-storage need with no external backend. A PVC implies persistence beyond the Pod's lifetime and requires a storage backend, hostPath ties data to a specific node's filesystem which breaks if the Pod reschedules and isn't meant for inter-container sharing per se, and a ConfigMap volume is for injecting configuration data, not for writable shared scratch space.24. A user runs 'kubectl get pods' and sees a Pod stuck in Pending state for several minutes. Which command provides the most direct explanation of why the scheduler has not placed it?
- A. kubectl logs <pod-name>
- B. kubectl describe pod <pod-name>, checking the Events section for scheduling failure reasons
- C. kubectl get nodes -o wide
- D. kubectl top pod <pod-name>
Show answer & explanation
Answer: B
kubectl describe pod surfaces the Events section, which records scheduler messages such as insufficient resources or unmatched node affinity/taints — the direct reason a Pod remains Pending. kubectl logs only returns container stdout/stderr, which doesn't exist yet for a Pod that hasn't been scheduled and started; kubectl get nodes shows node status but not why this specific Pod was rejected; and kubectl top requires the metrics server and pod to be running, neither of which applies to a Pending pod.25. A Deployment's Pods are repeatedly restarted, and 'kubectl describe pod' shows 'Liveness probe failed: HTTP probe failed with statuscode: 500'. What is the most direct interpretation of this signal?
- A. The container's readiness probe passed but its liveness probe endpoint is returning an application-level error, so the kubelet is restarting the container
- B. The node itself is unreachable and is about to be marked NotReady
- C. The container image failed to pull from the registry
- D. A NetworkPolicy is blocking all traffic to the Pod
Show answer & explanation
Answer: A
A liveness probe failure with an HTTP 500 means the kubelet successfully connected to the container's probe endpoint but the application returned a server error, causing the kubelet to consider the container unhealthy and restart it. This is unrelated to node reachability (that would show as NotReady node status, a different signal), unrelated to image pull errors (which would show as ImagePullBackOff/ErrImagePull events instead), and a NetworkPolicy blocking traffic would typically manifest as a connection timeout/refused rather than a completed HTTP request returning status 500.26. kubectl get nodes shows a worker node in state NotReady. Which of the following is the most systematic first step to diagnose the root cause?
- A. Scale the affected Deployment to zero replicas
- B. Delete and recreate the node object immediately
- C. Modify the node's taints to NoExecute to force pod eviction before investigating
- D. SSH to the node and check the kubelet service status and logs (e.g., systemctl status kubelet, journalctl -u kubelet)
Show answer & explanation
Answer: D
NotReady typically indicates the kubelet on that node has stopped reporting status (crashed, lost API connectivity, or a failed health check), so checking the kubelet's live service status and logs directly identifies the cause. Deleting the node object doesn't fix the underlying host issue and can cause unnecessary pod rescheduling churn; scaling an unrelated Deployment doesn't address node health; and manually tainting the node NoExecute before diagnosis needlessly evicts workloads that might otherwise still be running fine.27. kubectl get pods shows a Pod in ImagePullBackOff. kubectl describe pod reveals 'Failed to pull image: unauthorized: authentication required'. What is the most likely fix?
- A. Add a toleration for the NoSchedule taint
- B. Increase the Pod's memory limit
- C. Change the Pod's restartPolicy to Never
- D. Create or correct an imagePullSecrets reference in the Pod spec (or service account) with valid registry credentials
Show answer & explanation
Answer: D
An 'unauthorized' error while pulling an image means the node lacks valid credentials for the private registry, so the fix is to supply correct imagePullSecrets on the Pod or its service account. Memory limits are unrelated to registry authentication, tolerations address scheduling onto tainted nodes rather than image pull auth, and changing restartPolicy affects what happens after container exit, not the ability to pull the image in the first place.28. An application Pod cannot reach a Service by its DNS name, but curling the Service's ClusterIP directly from the same Pod works. What area should be investigated first?
- A. The etcd cluster's disk I/O latency
- B. The kube-scheduler logs on the control plane
- C. The CoreDNS Pods' health/logs and the Pod's /etc/resolv.conf configuration
- D. The container's CPU limit settings
Show answer & explanation
Answer: C
Since IP-based connectivity works but name resolution doesn't, the fault is isolated to DNS: check that CoreDNS Pods are running and healthy, and confirm the Pod's resolv.conf has correct nameserver and search entries. kube-scheduler is unrelated to runtime networking or DNS; etcd disk latency would affect API server responsiveness broadly, not selectively break DNS while ClusterIP routing works; and CPU limits on the application container wouldn't selectively break only name resolution while raw IP connectivity succeeds.29. A Deployment update introduces a broken container image, and Pods enter CrashLoopBackOff cluster-wide for that Deployment. What is the fastest supported way to restore service while investigating the image issue?
- A. kubectl rollout undo deployment/<name> to revert to the previous working ReplicaSet revision
- B. kubectl delete deployment/<name> and manually recreate Pods with kubectl run
- C. Scale the Deployment to 0 replicas and leave it there until a new image is ready
- D. Edit the Service to point selector labels at a nonexistent ReplicaSet
Show answer & explanation
Answer: A
kubectl rollout undo reverts a Deployment to its prior ReplicaSet revision using the retained rollout history, restoring known-good Pods quickly without hand-authoring new manifests. Deleting the Deployment loses its rollout history and management, and manually created Pods via kubectl run lose Deployment-level self-healing and rollout tracking; scaling to zero removes service entirely rather than restoring it; and repointing a Service's selector to a nonexistent ReplicaSet provides no functioning backend at all.30. A PersistentVolumeClaim remains stuck in Pending status indefinitely. Which combination of checks best narrows the root cause?
- A. Only checking whether the Pod referencing the PVC has a valid image tag
- B. Checking whether a matching PV exists (for static provisioning) or whether the StorageClass provisioner and CSI driver are functioning (for dynamic provisioning), plus events on the PVC
- C. Checking only the node's kubelet logs, since PVCs are node-scoped objects
- D. Checking the kube-scheduler's leader election status exclusively
Show answer & explanation
Answer: B
A stuck PVC is a storage/provisioning-layer problem: for static provisioning, verify a compatible PV exists; for dynamic provisioning, verify the StorageClass's provisioner and the underlying CSI driver are healthy, and read 'kubectl describe pvc' Events for explicit error messages. The Pod's image tag is unrelated to volume binding, which happens independently of Pod scheduling; PVCs are cluster-scoped-claim objects tied to namespaces, not to any particular node's kubelet; and scheduler leader election is unrelated to storage provisioning entirely.31. A candidate needs to drain a node for maintenance while minimizing disruption to workloads managed by a Deployment with a PodDisruptionBudget (PDB) requiring minAvailable: 2 out of 3 replicas. What happens when 'kubectl drain' is run on a node holding one of those replicas?
- A. The drain proceeds unconditionally, ignoring the PDB, because PDBs only apply to manual kubectl delete commands
- B. The eviction respects the PDB, only proceeding if evicting that Pod would not push available replicas below the minAvailable threshold
- C. The PDB blocks the drain forever regardless of how many replicas remain elsewhere
- D. PDBs apply only to StatefulSets, so this Deployment's PDB is not enforced during the drain
Show answer & explanation
Answer: B
kubectl drain uses the Eviction API, which respects PodDisruptionBudgets: an eviction is refused if it would violate minAvailable, forcing the drain to wait or retry until it's safe. PDBs are enforced specifically through the Eviction API (which drain uses), not bypassed for it; as long as other replicas remain available elsewhere satisfying minAvailable, the eviction can proceed rather than blocking forever; and PDBs apply to any pod-controller-managed workload matching their selector, including Deployments, not just StatefulSets.32. A cluster administrator wants a Pod to be scheduled preferentially on nodes with SSD-backed storage but still allow scheduling elsewhere if no SSD node is available. Which scheduling mechanism fits this requirement?
- A. A hard nodeSelector matching disktype=ssd
- B. A preferredDuringSchedulingIgnoredDuringExecution node affinity rule targeting disktype=ssd
- C. A taint with effect NoSchedule applied to non-SSD nodes
- D. A ResourceQuota limiting Pods to SSD nodes
Show answer & explanation
Answer: B
'Preferred' (soft) node affinity expresses a scheduling preference that the scheduler tries to honor via weighted scoring but does not require, allowing the Pod to still land elsewhere if no matching node exists. A plain nodeSelector is a hard requirement — the Pod stays Pending if no matching node exists; tainting non-SSD nodes would need pods to carry a toleration and still doesn't express a 'nice-to-have' preference model as flexibly; and ResourceQuota governs aggregate resource consumption per namespace, not node placement.33. A StatefulSet named 'db' with 3 replicas is deployed with a headless Service. What distinguishes the network identity of its Pods from Pods managed by a standard Deployment?
- A. StatefulSet Pods get stable, predictable hostnames (db-0, db-1, db-2) and stable DNS entries that persist across rescheduling
- B. StatefulSet Pods share a single Pod IP among all replicas
- C. StatefulSet Pods cannot be addressed via DNS at all, only by IP
- D. StatefulSet Pods are assigned random names identical in format to Deployment-managed Pods
Show answer & explanation
Answer: A
StatefulSets assign stable ordinal-based names (e.g., db-0, db-1, db-2) and, combined with a headless Service, stable per-Pod DNS records that persist across restarts/rescheduling — unlike Deployment Pods, which get random hash-suffixed names with no such per-Pod DNS guarantee. Pods never share a single IP; each Pod retains its own IP address; StatefulSet Pods are in fact addressable individually via DNS (that's the point of the headless Service), so 'cannot be addressed via DNS' is false; and the naming convention is deliberately different from and more predictable than Deployment Pod naming, not identical.34. A Pod spec includes an initContainer that runs a database schema migration before the main application container starts. What is guaranteed about the execution order and failure behavior?
- A. Init containers run concurrently with the main container to save startup time
- B. Init containers run sequentially to completion before any main container starts, and if an init container fails, the kubelet retries it according to the Pod's restart policy before the main container ever starts
- C. Init container failures are ignored and the main container starts regardless
- D. Init containers share no filesystem or volumes with the main containers
Show answer & explanation
Answer: B
Init containers run one at a time, in order, to successful completion before any app container in the Pod starts; a failing init container causes the Pod to retry that init container per the restartPolicy, blocking the main container's start until it succeeds (or the Pod is deemed failed for policies that don't retry). They do not run concurrently with the main container — that would defeat their purpose of guaranteeing pre-conditions; failures are not silently ignored; and init containers can share volumes with app containers (a common pattern for pre-populating a shared volume), so 'no shared filesystem' is incorrect.35. A cluster network uses a CNI plugin that assigns each Pod a unique IP from a cluster-wide pod CIDR. Which fundamental Kubernetes networking requirement does this directly satisfy?
- A. Every Pod can communicate with every other Pod across the cluster without NAT, since each has a routable, unique IP
- B. Every Pod must go through a NodePort to reach any other Pod
- C. Only Pods on the same node can communicate with each other
- D. Pods must share the host node's network namespace to communicate
Show answer & explanation
Answer: A
The Kubernetes networking model mandates that Pods can reach each other directly by IP across the whole cluster without NAT, and CNI plugins implement this by giving every Pod a unique, routable IP from the cluster's Pod CIDR. NodePort is for external-to-cluster access, not Pod-to-Pod communication; the flat, no-NAT model is explicitly designed to allow cross-node Pod communication (not just same-node); and Pods use their own network namespace by default (isolated from the host's), which is precisely what the CNI plugin's IP assignment supports rather than contradicts.36. A pod is stuck in Pending state and events show no nodes are available. What is the most likely cause?
- A. No node satisfies the pod's requirements, whether insufficient allocatable resources, an unsatisfied node selector or affinity rule, or a taint the pod does not tolerate
- B. The container image failed to pull from the registry
- C. The container process exited with a non-zero status
- D. The pod's liveness probe is failing repeatedly
Show answer & explanation
Answer: A
Pending means the scheduler has not placed the pod, so the problem lies in the scheduling constraints rather than in the container. Image pull failures produce ImagePullBackOff and process exits produce CrashLoopBackOff, both of which occur after scheduling has already succeeded.37. A node is marked with a taint. What effect does this have on scheduling?
- A. Pods are repelled from the node unless they carry a matching toleration, with the effect determining whether they are merely not scheduled or also evicted
- B. Pods are attracted to the node in preference to others
- C. The node is removed from the cluster
- D. All pods on the node are immediately deleted regardless of tolerations
Show answer & explanation
Answer: A
Taints repel while node affinity attracts, so the two mechanisms work in opposite directions and are commonly combined to dedicate nodes to particular workloads. The NoExecute effect additionally evicts pods already running without a toleration, whereas NoSchedule affects only future placement.38. A container specifies a memory request of 256Mi and a limit of 512Mi. What do these values control?
- A. The request is used for scheduling and reserves capacity, while the limit is the hard ceiling above which the container is terminated for exceeding memory
- B. The request is the ceiling and the limit is the reservation
- C. Both values are advisory and neither is enforced
- D. The request controls CPU and the limit controls memory
Show answer & explanation
Answer: A
The scheduler places pods against requests while the runtime enforces limits, which is why a cluster can be scheduled to capacity yet have idle physical resources. Memory limits are enforced by termination since memory cannot be throttled, whereas exceeding a CPU limit results in throttling rather than the container being killed.39. A deployment is updated with a new image and the rollout stalls partway. What command-level information identifies the cause?
- A. The rollout status and the events on the new replica set's pods, which report why the new pods are not becoming ready
- B. The node's kernel version
- C. The cluster's total CPU capacity only
- D. The deployment's creation timestamp
Show answer & explanation
Answer: A
A rolling update proceeds only as new pods become ready, so a stall means the new pods are failing readiness and their events carry the reason. The old replica set continues serving during the stall, which is the protection a rolling strategy provides, and the rollout can be undone to the previous revision.40. How do a liveness probe and a readiness probe differ in effect?
- A. A failed liveness probe restarts the container, while a failed readiness probe removes the pod from service endpoints without restarting it
- B. A failed readiness probe restarts the container
- C. Both probes restart the container on failure
- D. Neither probe affects traffic routing
Show answer & explanation
Answer: A
The distinction matters because a container that is temporarily busy should stop receiving traffic rather than being restarted, which readiness achieves and liveness would make worse. A startup probe covers slow-starting applications so a long initialization does not trigger liveness restarts before the application is ready to respond.41. A workload requires stable network identity and persistent storage per replica. Which controller fits?
- A. A StatefulSet, which provides ordered stable identities and per-replica persistent volume claims
- B. A Deployment, which manages interchangeable replicas
- C. A DaemonSet, which runs one pod per node
- D. A Job, which runs a workload to completion
Show answer & explanation
Answer: A
StatefulSets give each replica a predictable ordinal name and its own volume that persists across rescheduling, which clustered databases require. Deployments treat replicas as interchangeable, DaemonSets place one pod per node for agents, and Jobs run to completion rather than serving continuously.42. A batch task must run to completion once, retrying on failure, and must not be restarted after it succeeds. Which controller fits?
- A. A Job, which runs pods to successful completion with a backoff limit bounding retries
- B. A Deployment, which keeps a desired number of pods running indefinitely
- C. A DaemonSet, which places a pod on each node
- D. A StatefulSet, which provides ordered stable identities
Show answer & explanation
Answer: A
A Job tracks completions and stops once the target is met, with the backoff limit preventing an endlessly failing task from retrying forever. A Deployment would restart the container after a successful exit because it maintains a running replica count, which is the wrong semantics for work that finishes, and a CronJob is the scheduled variant that creates Jobs on a recurring basis.43. A Service of type ClusterIP is created. How is it reached?
- A. From within the cluster using its stable virtual IP or DNS name, with no external exposure
- B. From outside the cluster on a port opened on every node
- C. From outside the cluster through a provisioned external load balancer
- D. Only by pods on the same node as the backing pods
Show answer & explanation
Answer: A
ClusterIP is the default and internal-only, while NodePort opens a port on every node and LoadBalancer provisions an external load balancer, each building on the one before it. Cluster DNS resolves the service name to the virtual IP, which is what lets workloads address a service without knowing any pod address.44. A Service has no endpoints despite matching pods appearing to run. What should be checked?
- A. Whether the Service's selector matches the pods' labels and whether those pods are passing readiness, since only ready pods become endpoints
- B. Whether the Service has a public IP address assigned
- C. Whether the cluster's DNS add-on is the latest version
- D. Whether the node has sufficient disk space
Show answer & explanation
Answer: A
Endpoints are populated from pods matching the selector that are also ready, so a label mismatch and a failing readiness probe produce identical empty-endpoint symptoms. Comparing the Service selector against the pod labels directly resolves the first case, and inspecting pod readiness resolves the second.45. A NetworkPolicy is applied to a namespace selecting all pods with no ingress rules. What is the effect?
- A. All ingress traffic to those pods is denied, because selecting a pod with a policy switches it from default-allow to allowing only what the policies permit
- B. All ingress traffic is allowed, since no rules restrict it
- C. Only traffic from other namespaces is denied
- D. The policy has no effect without a matching egress policy
Show answer & explanation
Answer: A
Pods are unrestricted until a policy selects them, at which point the policy set becomes the complete allow list for the specified direction. This makes an empty-rule policy the idiomatic way to establish a default deny, and it also requires a network plugin that implements policies since the API object alone enforces nothing.46. An Ingress resource is created but external traffic does not reach the application. What is a common cause?
- A. The backing Service is of type ClusterIP
- B. No ingress controller is running to act on the resource, since the Ingress object is only a declaration of intent
- C. The pods have readiness probes configured
- D. The namespace lacks a resource quota
Show answer & explanation
Answer: B
An Ingress is a specification that a controller must implement, so without a controller deployed and an ingress class associating the resource with it, nothing routes traffic. ClusterIP is the normal backing service type for an Ingress, since the controller reaches it from inside the cluster.47. Cluster DNS resolves a service name. What is the fully qualified form within the cluster?
- A. The node's hostname followed by the service port
- B. The container image name followed by its tag
- C. The pod name followed by the node name
- D. The service name, its namespace, then the svc and cluster domain suffix, so a short name resolves within the same namespace and a qualified name across namespaces
Show answer & explanation
Answer: D
The search domain configured in each pod means an unqualified service name resolves within the pod's own namespace, which is why the same manifest works in multiple namespaces. Reaching a service in another namespace requires including the namespace in the name, and headless services resolve to the individual pod addresses instead of a virtual IP.48. A PersistentVolumeClaim remains Pending. What are the likely causes?
- A. No matching PersistentVolume is available and no StorageClass can dynamically provision one satisfying the requested size and access mode
- B. The pod referencing the claim has not been created yet, which always blocks binding
- C. The node lacks sufficient CPU capacity
- D. The claim's namespace has no service account
Show answer & explanation
Answer: A
Binding requires either a pre-existing volume matching the requested capacity, access mode and class, or a storage class capable of provisioning one. A storage class using volume binding mode WaitForFirstConsumer deliberately delays binding until a pod is scheduled, which is the one case where Pending is expected rather than a fault.49. A PersistentVolume has a reclaim policy of Delete. What happens when its claim is deleted?
- A. The volume and the underlying storage asset are deleted, so data is lost unless it was backed up separately
- B. The volume is retained with its data for manual recovery
- C. The volume is made available for another claim with its data intact
- D. Nothing happens until the volume is explicitly deleted
Show answer & explanation
Answer: A
Delete is the common default for dynamically provisioned volumes and removes the backing storage along with the claim, which surprises teams who assume deletion is reversible. Retain keeps both the volume and the data for manual handling, which is the appropriate policy for anything whose loss would matter.50. A volume access mode of ReadWriteOnce is specified. What does this permit?
- A. Read-write mounting by pods on a single node, which is why a workload spread across nodes cannot share such a volume
- B. Read-write mounting by exactly one pod cluster-wide under all circumstances
- C. Read-write mounting by pods on any number of nodes
- D. Read-only mounting by a single pod
Show answer & explanation
Answer: A
The constraint is per node rather than per pod, so several pods on the same node can share a ReadWriteOnce volume while a pod on a second node cannot mount it. ReadWriteMany permits multi-node read-write access but is supported only by storage backends capable of it, which excludes most block storage.51. Configuration values and credentials must be supplied to a pod. Which resources are used and what is the difference?
- A. ConfigMaps for non-confidential configuration and Secrets for sensitive values, with Secrets base64-encoded at rest by default rather than encrypted unless encryption at rest is configured
- B. Only ConfigMaps can be mounted as files
- C. Secrets for configuration and ConfigMaps for credentials
- D. Both are encrypted by default with no additional configuration
Show answer & explanation
Answer: A
Secrets signal sensitivity and integrate with access control and encryption features, but base64 is an encoding rather than protection, so cluster encryption at rest and restricted access are what actually secure them. Both can be exposed as environment variables or mounted as files, and mounted files update when the source changes while environment variables do not.52. A ServiceAccount is bound to a Role through a RoleBinding. What does this achieve?
- A. The workload using that account gains the Role's permissions within the binding's namespace, following least privilege rather than using the default account's implicit access
- B. The workload gains cluster-wide administrative permissions
- C. The workload's network traffic is encrypted
- D. The workload is scheduled to a dedicated node
Show answer & explanation
Answer: A
Roles and RoleBindings are namespaced while ClusterRoles and ClusterRoleBindings apply cluster-wide, and a ClusterRole can also be referenced by a RoleBinding to grant its permissions within one namespace. Workloads that never call the API should have token automounting disabled entirely, which removes the credential rather than restricting it.53. A control plane component stores all cluster state. Which is it and what does its loss mean?
- A. The etcd key-value store, whose loss without a backup means the cluster's entire declared state is unrecoverable
- B. The kubelet, which runs on each node
- C. The kube-proxy, which programs service networking
- D. The container runtime, which executes containers
Show answer & explanation
Answer: A
Every object the API server serves is persisted in etcd, so a regular verified snapshot is the single most important cluster backup. The kubelet manages pods on its node, kube-proxy implements service routing, and the container runtime executes containers, none of which hold cluster-wide state.54. A node must be taken out of service for maintenance without disrupting workloads more than necessary. What is the correct sequence?
- A. Cordon the node to stop new scheduling, then drain it to evict existing pods so they reschedule elsewhere, and uncordon after maintenance
- B. Delete the node object immediately and recreate it afterward
- C. Power off the node without notifying the cluster
- D. Delete each pod on the node manually and leave the node schedulable
Show answer & explanation
Answer: A
Cordoning prevents new placements while draining evicts existing pods gracefully, respecting pod disruption budgets so an application does not lose more replicas than it can tolerate. Deleting pods on a still-schedulable node lets them be rescheduled straight back onto the node being maintained.55. A PodDisruptionBudget specifies minAvailable of 2 for a three-replica deployment. What does it constrain?
- A. Voluntary disruptions such as node drains, which will not proceed if they would leave fewer than two replicas available
- B. Involuntary disruptions such as node hardware failure
- C. The maximum number of replicas the deployment may scale to
- D. The number of restarts a container may perform
Show answer & explanation
Answer: A
Budgets govern voluntary operations initiated through the eviction API and cannot prevent a node from failing, since nothing negotiates with hardware. Setting minAvailable equal to the replica count blocks drains entirely, which turns routine maintenance into a manual override rather than protecting availability.56. A namespace has a ResourceQuota applied. What happens to a pod created without resource requests?
- A. It is rejected where the quota covers that resource, since the quota cannot account for a pod that declares no request
- B. It is admitted and assigned unlimited resources
- C. It is admitted with the quota applied to the whole namespace afterward
- D. It is scheduled to a node outside the namespace
Show answer & explanation
Answer: A
A quota on CPU or memory requires every pod to declare the corresponding request so consumption can be counted, so undeclared pods are refused. A LimitRange supplying default requests and limits is the companion object that lets manifests omit them while still satisfying the quota.57. A pod in CrashLoopBackOff must be diagnosed but the container restarts too quickly to inspect. What retrieves the failure output?
- A. Requesting the previous container instance's logs, which returns output from the run that terminated
- B. Describing the node the pod is scheduled on
- C. Checking the cluster's API server version
- D. Listing the images present on the node
Show answer & explanation
Answer: A
The previous-container log flag reaches the terminated instance, which is where the error that caused the exit appears, since the current instance may not have produced it yet. Pod events supply the complementary view of what the platform did, such as repeated restarts and backoff timing.58. A node reports NotReady. Which component's health should be examined first?
- A. The kubelet on that node, since it reports node status to the API server and its failure or inability to reach the API server produces NotReady
- B. The scheduler on the control plane
- C. The ingress controller
- D. The DNS add-on
Show answer & explanation
Answer: A
Node readiness is reported by the kubelet, so NotReady means either the kubelet is unhealthy or it cannot communicate with the control plane, and network connectivity between them is the second thing to check. Container runtime failure and disk or memory pressure conditions also surface through the kubelet's status reporting.59. Pods in one namespace cannot resolve service names. What is the most productive first check?
- A. Whether the affected pods have the correct image tags
- B. Whether the deployment's replica count is correct
- C. Whether the nodes have sufficient disk space for logs
- D. Whether the cluster DNS pods are running and healthy, and whether a NetworkPolicy is blocking pod traffic to them
Show answer & explanation
Answer: D
DNS failures scoped to one namespace commonly indicate an egress NetworkPolicy blocking traffic to the DNS service, since a broken DNS deployment would affect every namespace. Confirming resolution works from a pod in an unaffected namespace distinguishes the two possibilities in one step.60. A cluster upgrade is planned. What order should the components be upgraded in?
- A. Control plane first and node components afterward, since the control plane supports nodes running an older version but not a newer one
- B. Nodes first, then the control plane
- C. All components simultaneously to avoid version skew
- D. Only the control plane, since nodes upgrade automatically
Show answer & explanation
Answer: A
Version skew policy permits kubelets to lag the API server by a bounded number of minor versions but not to run ahead of it, which fixes the upgrade order. Skipping minor versions is also unsupported, so reaching a much newer version requires stepping through each release rather than jumping.61. A pod needs to run a setup task that must complete before the main container starts. What construct provides this?
- A. An init container, which runs to completion before app containers start and blocks the pod if it fails
- B. A sidecar container running alongside the main container
- C. A separate Job in the same namespace
- D. A lifecycle postStart hook on the main container
Show answer & explanation
Answer: A
Init containers run sequentially to completion and guarantee ordering, which a sidecar starting concurrently cannot. A separate Job has no ordering relationship with the pod at all, and a postStart hook runs after the main container has already started rather than before it.62. A HorizontalPodAutoscaler is configured on CPU utilization but does not scale. What is a common cause?
- A. Metrics are unavailable because the metrics pipeline is not running, or the pods declare no CPU request so utilization cannot be computed as a percentage
- B. The deployment has too many replicas already declared in its manifest
- C. The nodes lack a container runtime
- D. The service is of type ClusterIP
Show answer & explanation
Answer: A
Target utilization is expressed relative to the declared request, so a pod without one gives the autoscaler no denominator and the metric reports as unknown. A metrics server or equivalent adapter must also be running, since the autoscaler consumes metrics through an API rather than measuring anything itself.63. A workload must be prevented from scheduling two replicas onto the same node. What achieves this?
- A. Pod anti-affinity keyed on the node hostname topology, or topology spread constraints distributing replicas across a topology domain
- B. A node selector matching every node in the cluster
- C. Increasing the pod's memory limit
- D. Setting the deployment's replica count equal to the node count
Show answer & explanation
Answer: A
Anti-affinity expresses a constraint about co-location relative to other pods, and the topology key determines the scope, whether node, zone or region. Required anti-affinity leaves pods unschedulable when the topology cannot satisfy it, so preferred anti-affinity is often used where availability matters more than strict separation.64. A manifest is applied and the API server rejects it as invalid for the resource kind. What should be verified?
- A. The apiVersion and kind against the cluster's supported API versions, since resources graduate between groups and versions across releases
- B. The node's available memory
- C. The container registry's availability
- D. The pod's assigned service account
Show answer & explanation
Answer: A
API groups and versions change across releases as resources move from beta to stable, so a manifest written for an older cluster can be rejected outright after an upgrade. Checking which versions the cluster serves for that resource identifies the correct apiVersion to use.65. A container image tag of latest is used in a production deployment. What problem does this create?
- A. The running content becomes ambiguous, since nodes may hold different cached versions and a rollback cannot return to a specific prior image
- B. The image will fail to pull entirely
- C. The pod will be rejected by the API server
- D. The deployment will refuse to scale beyond one replica
Show answer & explanation
Answer: A
A mutable tag can resolve to different content over time and across nodes depending on pull policy and cache state, so two replicas of one deployment can run different code. Immutable tags or digests make the deployed artefact unambiguous, which is what makes a rollback meaningful.
More in this family
Explore more Technology & IT Certifications
More in this category
- Claude Certified Associate – FoundationsPractice questions →
- CompTIA A+ (Core 1: 220-1201 and Core 2: 220-1202)Practice questions →
- CompTIA Cybersecurity Analyst+ (CySA+)Practice questions →
- CompTIA Network+Practice questions →
- CompTIA Security+ (SY0-701)Practice questions →
- Google Cloud Certified - Associate Cloud EngineerPractice questions →
- Google Cloud Certified - Cloud Digital LeaderPractice questions →
- Certified Information Systems AuditorPractice questions →
- Certified Information Security ManagerPractice questions →
- ISC2 Certified in Cybersecurity (CC)Practice questions →
- Project Management Professional (PMP)Practice questions →
- Microsoft Certified: Power BI Data Analyst Associate (Exam PL-300)Practice questions →
2026 statistics
Key facts: CKA exam
Every free resource for this exam
Get a free CKA study plan
A week-by-week plan plus new practice questions, straight to your inbox.
Official sources
Primary documents used to verify the exam details shown on this page.
- Certified Kubernetes Administrator (CKA) CertificationCloud Native Computing Foundation (CNCF)cncf.io
- Frequently Asked Questions: CKA, CKAD & CKS (Candidate-Facing Docs)The Linux Foundationdocs.linuxfoundation.org
- Certified Kubernetes Administrator (CKA) — Training & CertificationThe Linux Foundationtraining.linuxfoundation.org
- CNCF Curriculum Repository — CKA_Curriculum_v1.35Cloud Native Computing Foundation (CNCF)github.com
- Important Instructions: CKA and CKAD (Candidate-Facing Docs)The Linux Foundationdocs.linuxfoundation.org
Last verified against the official exam content outline:
Frequently asked questions
How long is the CKA exam and how many tasks does it include?
You have 2 hours (120 minutes) to complete the CKA exam. During that time you'll work through 15–20 performance-based tasks that must be solved directly from a command line running Kubernetes on Linux — there are no multiple-choice questions. With roughly two hours for up to 20 hands-on tasks, that averages out to only a few minutes per task, so time management and speed with kubectl matter as much as knowing the answers. Practice using imperative commands and the official Kubernetes documentation (which you're allowed to consult during the exam) to move quickly.
What score do I need to pass the CKA, and how much does it cost?
You need a score of 66% or above to pass the CKA. The exam costs $445, and that price includes one free retake — so if you don't pass on your first attempt, you can sit the exam again at no additional cost. Because the free retake is built into the fee, it's reasonable to treat your first attempt partly as a diagnostic if you're on the borderline, though you should still prepare fully. Your score report is sent by email within 24 hours of completing the exam.
Which topics are covered on the CKA, and how are they weighted?
The CKA curriculum is organized into 5 domains: Cluster Architecture, Installation & Configuration (25%); Workloads & Scheduling (15%); Services & Networking (20%); Storage (10%); and Troubleshooting (30%). Troubleshooting is the most heavily weighted domain at 30%, so nearly a third of your score comes from diagnosing and fixing broken clusters, nodes, and workloads. Combined with the 25% for Cluster Architecture, Installation & Configuration, these two areas account for more than half of the exam — a strong signal to prioritize hands-on debugging and cluster-setup practice.
What Kubernetes version does the exam use, how is it proctored, and how long is the certification valid?
The CKA exam environment currently runs Kubernetes v1.35, and the published curriculum aligns with that same version — so study against v1.35 features and APIs rather than an older release. The exam is delivered online and remotely proctored through PSI's Bridge platform using the PSI Secure Browser, with the proctor monitoring you via streaming audio, video, and screen sharing. Once you pass, the CKA certification is valid for 2 years, after which you'll need to recertify to keep your credential current.