What the CKA exam covers
- Cluster Architecture Installation and Configuration188 questions
- Workloads and Scheduling182 questions
- Services and Networking161 questions
- Storage164 questions
- Troubleshooting173 questions
Free CKA sample questions
A sample of 10 questions with answers and explanations. Sign up free to practice all 868.
-
Which component in a Kubernetes control plane is responsible for persisting all cluster data?
- Akube-controller-manager
- Bkube-apiserver
- Ckube-scheduler
- DetcdCorrect
✓ Correct answer: Detcd is the consistent and highly available key-value store that serves as the sole backing store for all Kubernetes cluster state and configuration data. Every object created in the cluster - nodes, pods, services, config maps, secrets - is persisted in etcd. All other control plane components access cluster data by reading from and writing to etcd exclusively through the kube-apiserver, which acts as the only direct client of etcd.
Why the other options are wrong- Akube-controller-manager runs reconciliation loops that watch cluster state and drive actual state toward desired state, but it does not persist data - it reads and writes through the kube-apiserver.
- Bkube-apiserver is the front-end gateway for the Kubernetes control plane and is the only component that communicates directly with etcd, but the apiserver itself does not store data - it delegates persistence entirely to etcd.
- Ckube-scheduler watches for unscheduled pods and assigns them to suitable nodes, but it holds no persistent state of its own and does not interact with the storage layer directly.
-
Which command renews all Kubernetes certificates managed by kubeadm?
- Akubeadm certs rotate all
- Bkubeadm renew certs --all
- Ckubeadm alpha certs renew
- Dkubeadm certs renew allCorrect
✓ Correct answer: DThe correct subcommand path is 'kubeadm certs renew all', which instructs kubeadm to renew every certificate it manages - including the API server cert, etcd certs, front-proxy cert, and others - using the existing CA. Individual certificates can be renewed by replacing 'all' with the specific certificate name such as 'apiserver' or 'etcd-server'.
Why the other options are wrong- Akubeadm certs rotate all is not a valid kubeadm subcommand; kubeadm uses 'renew', not 'rotate', for certificate renewal operations.
- Bkubeadm renew certs --all reverses the correct subcommand order; the valid command structure is 'kubeadm certs renew all', not 'kubeadm renew certs'.
- Ckubeadm alpha certs renew was the path used in older pre-GA versions of kubeadm; since Kubernetes 1.20 the 'alpha' prefix was removed and the stable command 'kubeadm certs renew' is used instead.
-
Which kubectl command creates a Deployment named 'web-app' with 3 replicas using the nginx:1.25 image?
- Akubectl create deployment web-app --image=nginx:1.25 --replicas=3Correct
- Bkubectl create pod web-app --image=nginx:1.25 --count=3
- Ckubectl deploy web-app --image=nginx:1.25 --replicas=3
- Dkubectl run web-app --image=nginx:1.25 --replicas=3
✓ Correct answer: Akubectl create deployment is the correct imperative command for creating a Deployment object. The --image flag specifies the container image and the --replicas flag sets the desired replica count. This creates a full Deployment resource with a ReplicaSet and pod template, unlike kubectl run which creates a single standalone Pod in modern Kubernetes versions.
Why the other options are wrong- Bkubectl create pod is not a valid kubectl subcommand for creating pods imperatively; the correct command is kubectl run, and pods do not accept a --count flag.
- Ckubectl deploy is not a valid kubectl subcommand; the correct command group is kubectl create deployment or kubectl apply with a manifest.
- Dkubectl run web-app --image=nginx:1.25 --replicas=3 is invalid because kubectl run no longer accepts --replicas in modern Kubernetes - it creates a single Pod, not a Deployment with multiple replicas.
-
Which CronJob spec field limits how many completed Job objects are retained?
- Aspec.successfulJobsHistoryLimitCorrect
- Bspec.keepJobs
- Cspec.jobHistoryLimit
- Dspec.historyLimit
✓ Correct answer: AThe spec.successfulJobsHistoryLimit field on a CronJob controls how many completed (successful) Job objects are kept in the cluster after they finish. Retaining Job history allows administrators to inspect logs and completion status of past runs. The default value is 3. A companion field, spec.failedJobsHistoryLimit (default 1), controls retention of failed Jobs. Setting either to 0 immediately deletes Jobs of that type after they complete.
Why the other options are wrong- Bspec.keepJobs is not a valid Kubernetes CronJob field; no such field exists in the CronJob API specification. The correct field is spec.successfulJobsHistoryLimit.
- Cspec.jobHistoryLimit is not a valid Kubernetes CronJob field; Kubernetes uses separate fields for successful and failed job history (spec.successfulJobsHistoryLimit and spec.failedJobsHistoryLimit) rather than a single combined limit.
- Dspec.historyLimit is not a valid Kubernetes CronJob field; this field name does not appear in the CronJob API. The correct field for completed job retention is spec.successfulJobsHistoryLimit.
-
Which of the following are valid Ingress path types in Kubernetes? (Select TWO)
- AExactCorrect
- BWildcard
- CPrefixCorrect
- DRegex
✓ Correct answer: A, CKubernetes defines three standard Ingress path types: 'Exact', which matches only the literal URL path specified; 'Prefix', which matches the path and any subpaths based on '/' delimiters; and 'ImplementationSpecific', where matching behavior is delegated to the Ingress controller. 'Wildcard' and 'Regex' are not part of the Kubernetes Ingress API specification, though some controllers may offer regex support through custom annotations.
Why the other options are wrong- BWildcard is not a valid Kubernetes Ingress path type - the three supported types are Exact, Prefix, and ImplementationSpecific.
- DRegex is not a standard Kubernetes Ingress path type - while some Ingress controller implementations support regex via annotations, it is not a recognized pathType value in the Kubernetes API.
-
What does kubectl get endpointslices show?
- AThe list of external endpoints for services
- BPod IP address ranges per node
- CNetwork slices allocated to the cluster
- DScalable endpoint objects that replace Endpoints for large servicesCorrect
✓ Correct answer: DEndpointSlices, introduced in Kubernetes v1.17 and enabled by default from v1.21, replace the original Endpoints resource for scalability. Each EndpointSlice holds up to 100 endpoints by default, so large services are split across multiple slices rather than one monolithic Endpoints object. This reduces the size of updates propagated through the API server and etcd, significantly improving performance in clusters with thousands of pods behind a single service.
Why the other options are wrong- AThe list of external endpoints for services describes ExternalName services or manually-managed Endpoints objects pointing outside the cluster, not what the EndpointSlice resource represents.
- BPod IP address ranges per node describes a node-level CIDR allocation concept, which is tracked by the node's podCIDR field, not by EndpointSlices.
- CNetwork slices allocated to the cluster is a fabricated concept unrelated to Kubernetes; network slicing is a telecommunications term and has no equivalent in the Kubernetes EndpointSlice API.
-
Summit Retail has a PersistentVolumeClaim (PVC) with a storageClassName set to 'fast-ssd'. However, the PVC remains in Pending state. What is the most likely reason?
- ANo PersistentVolume or StorageClass named 'fast-ssd' exists in the clusterCorrect
- BPVCs always start in Pending state for 60 seconds
- CThe pod referencing the PVC has not been created yet
- DThe PVC is in the wrong namespace
✓ Correct answer: AA PVC remains in Pending state when Kubernetes cannot satisfy the storage request. When a storageClassName is specified, Kubernetes first looks for a StorageClass with that name to dynamically provision a PV. If no such StorageClass exists, it also checks for a statically provisioned PV that matches the class name, access modes, and capacity. If neither exists, the PVC stays Pending indefinitely.
Why the other options are wrong- BPVCs do not always start in Pending state for 60 seconds; a PVC is bound immediately when a matching PV or dynamic provisioner is available.
- CThe pod referencing the PVC does not need to exist for the PVC to bind; under the default Immediate binding mode, binding happens as soon as a matching PV or dynamic provisioner is available, regardless of pod creation.
- DThe PVC being in the wrong namespace is not the likely cause here; PVCs are namespace-scoped, but PVs are cluster-wide and the storageClassName must match a StorageClass, which is also cluster-wide.
-
Which command changes the reclaim policy of PV "data-vol" from Delete to Retain?
- Akubectl patch pv data-vol --type=json -p '[{"op":"replace","path":"/spec/reclaim","value":"Retain"}]'
- Bkubectl set reclaim-policy pv data-vol --value=Retain
- Ckubectl patch pv data-vol -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'Correct
- Dkubectl edit pv data-vol --patch persistentVolumeReclaimPolicy=Retain
✓ Correct answer: Ckubectl patch allows in-place updates to specific fields of a Kubernetes resource without replacing the entire object. Using a strategic merge patch with the JSON payload {"spec":{"persistentVolumeReclaimPolicy":"Retain"}} changes only the reclaim policy field of the PV named data-vol. This is the recommended way to change the reclaim policy on an existing PV because kubectl edit requires opening an editor interactively, while patch is scriptable.
Why the other options are wrong- AThe correct field is persistentVolumeReclaimPolicy, not /spec/reclaim, so this JSON patch path is invalid.
- BThere is no kubectl set reclaim-policy subcommand in Kubernetes.
- Dkubectl edit opens an interactive editor and does not accept an inline --patch flag.
-
SummitPeak Engineering finds that CoreDNS pods are running but DNS resolution inside other pods is failing. Which command should they run from a test pod to verify DNS functionality?
- Aping kube-dns
- Btraceroute coredns
- Cnslookup kubernetes.default.svc.cluster.localCorrect
- Dcurl http://dns-server:53
✓ Correct answer: CFrom inside a test pod, nslookup queries the cluster DNS resolver (the kube-dns Service backed by CoreDNS) using the pod's configured /etc/resolv.conf, so it directly exercises the full in-cluster name-resolution path. Looking up kubernetes.default.svc.cluster.local is the canonical check because that Service always exists in the default namespace, so a successful response confirms DNS is resolving service names while a failure isolates the problem to DNS. This is why nslookup against that FQDN is the standard diagnostic for in-cluster DNS.
Why the other options are wrong- Aping kube-dns is incorrect because ping uses ICMP and tests basic reachability, not DNS resolution; many cluster Services and CNI setups also drop ICMP, so a failed ping would not indicate a DNS problem.
- Btraceroute coredns is incorrect because traceroute maps the network path via ICMP/UDP hops and does not perform name resolution against the DNS service, so it cannot verify DNS functionality.
- Dcurl http://dns-server:53 is incorrect because DNS is served over UDP/TCP port 53 using the DNS protocol, not HTTP, and 'dns-server' is not the cluster DNS Service name, so this command tests neither the correct protocol nor the correct endpoint.
-
You suspect the controller manager is not working because Deployment replicas are not being created. Which command checks the controller manager logs?
- Akubectl logs kube-controller-manager-master -n kube-systemCorrect
- Bsystemctl logs kube-controller-manager
- Ckubectl describe deployment -n kube-system kube-controller-manager
- Dcat /var/log/controller-manager.log
✓ Correct answer: AThe kube-controller-manager runs as a static pod in the kube-system namespace, and because the API server is functioning (the cluster is otherwise reachable), you can retrieve its logs through the normal kubectl logs command against the pod, whose name is kube-controller-manager-<nodename>. The controller manager runs the Deployment, ReplicaSet, and other controllers, so its logs reveal why ReplicaSets are not creating pods, such as leader-election failures or reconciliation errors. Tailing these logs is the standard way to diagnose controller-loop problems when the API server is healthy. You can confirm the exact pod name with kubectl get pods -n kube-system.
Why the other options are wrong- Bsystemctl logs kube-controller-manager is incorrect because systemctl has no logs subcommand (you would use journalctl), and on kubeadm clusters the controller manager runs as a static pod rather than a systemd service.
- Ckubectl describe deployment -n kube-system kube-controller-manager is incorrect because the controller manager is a static pod, not a Deployment, so no such Deployment object exists to describe.
- Dcat /var/log/controller-manager.log is incorrect because the component runs in a container and does not write to that fixed host log path by default.
Related Cloud Native resources
- CKA study guideKey concepts
- Cloud Native practice examsAll Cloud Native
- Certification pathWhere this fits
- Certification exam guides & tipsBlog
- Plans & pricingFree & paid
- KCSA practice examRelated
- CKS practice examRelated
- KCNA practice examRelated
CKA practice exam FAQ
How many questions are in the CKA practice exam on CertGrid?
CertGrid has 868 practice questions for CKA: Certified Kubernetes Administrator, covering 5 exam domains. The real CKA exam is a hands-on, performance-based lab exam (120 min). The real CKA exam is hands-on and performance-based. CertGrid provides a fixed 50-question MCQ practice session to test concepts, command decisions, and troubleshooting readiness. Practice in a real Kubernetes cluster before booking. CertGrid's MCQ readiness practice covers 50 questions.
Is CertGrid a hands-on Cloud Native lab simulator?
No. The real CKA exam is a hands-on, performance-based lab exam. CertGrid provides MCQ-style readiness practice to help you check concepts, commands, troubleshooting choices, and weak domains before doing hands-on labs - it is not a live lab simulator.
What is the passing score for CKA?
The CKA exam passing score is 66%, and you have about 120 min to complete it. CertGrid tracks your readiness across every objective so you know where to focus your hands-on lab practice.
Are these official CKA exam questions?
No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the CKA: Certified Kubernetes Administrator exam.
Can I practice CKA for free?
Yes. You can start practicing CKA: Certified Kubernetes Administrator for free with daily practice and sample questions. Paid plans unlock full timed exams, complete explanations, and domain analytics.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Cloud Native. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.