CKA: Certified Kubernetes Administrator Practice Exam

What the CKA exam covers

• Cluster Architecture Installation and Configuration197 questions
• Workloads and Scheduling187 questions
• Services and Networking168 questions
• Storage168 questions
• Troubleshooting183 questions

Free CKA practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 903.

1. Question 1Cluster Architecture Installation and Configuration

   Which component in a Kubernetes control plane is responsible for persisting all cluster data?

   • Akube-controller-manager
   • Bkube-apiserver
   • Ckube-scheduler
   • DetcdCorrect
   ✓ Correct answer: D

   etcd 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.
2. Question 2Cluster Architecture Installation and Configuration

   Which openssl command extracts only the expiry date from the API server certificate?

   • Aopenssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates
   • Bopenssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -enddateCorrect
   • Copenssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -expiry
   • Dopenssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -validity
   ✓ Correct answer: B

   The openssl x509 -enddate flag prints only the 'notAfter' field of the certificate, which is the exact date and time the certificate expires. Combined with -noout to suppress the encoded certificate output, this gives a concise single-line result useful for scripted expiry checks. This is more precise than -dates, which prints both the notBefore and notAfter fields.

   Why the other options are wrong

   • Aopenssl x509 with -noout -dates prints both the notBefore (start date) and notAfter (expiry date) fields together, not just the expiry date alone, making it more verbose than the -enddate flag.
   • Copenssl x509 -noout -expiry is not a valid openssl flag; there is no -expiry option in the openssl x509 subcommand - the correct flag for the expiration date is -enddate.
   • Dopenssl x509 -noout -validity is not a valid openssl flag; openssl does not recognize -validity as an option, so this command would produce an error rather than displaying any date information.
3. Question 3Workloads and SchedulingSelect all that apply

   Which of the following are valid ways to inject a Secret into a Pod? (Select TWO)

   • AAs command-line arguments passed to the container entrypoint
   • BAs annotations on the Pod
   • CAs environment variables using envFrom or env with secretKeyRefCorrect
   • DAs files mounted via a volumeCorrect
   ✓ Correct answer: C, D

   Kubernetes provides two supported methods for injecting Secret data into a pod. First, Secrets can be exposed as environment variables using env[].valueFrom.secretKeyRef to reference individual keys, or using envFrom to expose all keys in a Secret as environment variables. Second, Secrets can be mounted as a volume, which creates files inside the container where each key becomes a filename and its value is the file content. Both methods allow pods to consume Secret data without embedding sensitive values in the pod spec.

   Why the other options are wrong

   • APassing secrets as command-line arguments to the container entrypoint is not a supported Secret injection mechanism in Kubernetes; while you can reference env vars in args[], the Secret itself must first be injected as an environment variable, not directly as an argument.
   • BPod annotations are metadata labels visible in the API and stored in etcd in plain text; they are not a mechanism for injecting Secret values into a running container's environment or filesystem.
4. Question 4Workloads and Scheduling

   Which command creates a generic Secret named "db-creds" with username and password?

   • Akubectl create secret opaque db-creds --data=username=admin --data=password=secret123
   • Bkubectl create secret db-creds --set username=admin --set password=secret123
   • Ckubectl create secret generic db-creds --from-literal=username=admin --from-literal=password=secret123Correct
   • Dkubectl secret create db-creds --username=admin --password=secret123
   ✓ Correct answer: C

   The correct syntax for creating an Opaque (generic) Secret imperatively is kubectl create secret generic, followed by the Secret name and one --from-literal flag per key-value pair. Kubernetes automatically base64-encodes the supplied values and stores them under the data field of the resulting Secret object.

   Why the other options are wrong

   • Akubectl create secret opaque uses an unrecognized subcommand spelling; the valid type keyword is generic, not opaque. Additionally, --data= is not a valid flag for this command.
   • Bkubectl create secret db-creds omits the required type keyword (generic) between secret and the name, and --set is a Helm flag, not a valid kubectl create secret flag.
   • Dkubectl secret create reverses the command structure; the correct form is kubectl create secret generic, and --username/--password are not valid flags for this command.
5. Question 5Services and Networking

   A NodePort service is configured with nodePort: 30080. Which of the following correctly describes how external traffic reaches the pods?

   • ATraffic to any node's IP on port 30080 reaches the service's pods, wherever they runCorrect
   • BTraffic on port 30080 is accepted only on the control plane node's IP address
   • CTraffic must be sent to the specific node IP where the target pod is running on port 30080
   • DTraffic is forwarded directly to port 30080 on the backing pod itself
   ✓ Correct answer: A

   A NodePort Service instructs kube-proxy to open the specified node port (30080) on every node in the cluster, including nodes that are not running any of the target pods. iptables or IPVS rules on each node intercept traffic arriving on that port and forward it to a healthy pod endpoint anywhere in the cluster. This means an external client can connect to any node's IP on port 30080 and reach the Service, providing simple external access without a cloud load balancer.

   Why the other options are wrong

   • BA NodePort listens on every node, not just the control plane; any node IP accepts the traffic.
   • Ckube-proxy forwards NodePort traffic to a backing pod even if it runs on a different node.
   • DThe pod listens on its targetPort, not 30080; the node forwards from 30080 to that container port.
6. Question 6Services and Networking

   What is the effect of setting spec.publishNotReadyAddresses: true on a headless service?

   • AMakes the service accessible before the cluster is fully initialized
   • BDisables readiness probes for backed pods
   • CPublishes DNS records for pods even if they are not readyCorrect
   • DAllows unready nodes to receive traffic
   ✓ Correct answer: C

   In a standard Kubernetes Service, a pod's IP is only added to DNS (via EndpointSlices and Endpoints) once its readiness probe passes. Setting publishNotReadyAddresses: true on a headless Service bypasses this check and includes the pod IP in DNS records regardless of readiness status. This is particularly important for StatefulSets during initial bootstrap, where peers need to discover each other by DNS before the pods have completed startup and become ready.

   Why the other options are wrong

   • AMakes the service accessible before the cluster is fully initialized is incorrect; publishNotReadyAddresses is scoped to individual pod readiness within the service and has no bearing on cluster initialization state.
   • BDisables readiness probes for backed pods is incorrect; publishNotReadyAddresses does not modify or disable readiness probe execution on pods - it only affects whether unready pods are included in the service's DNS and endpoint records.
   • DAllows unready nodes to receive traffic is incorrect; publishNotReadyAddresses applies to pod readiness within the Service, not to node readiness. Node scheduling is a separate concern managed through node conditions and taints.
7. Question 7Storage

   Which Kubernetes storage resource represents a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using a StorageClass?

   • APersistentVolumeCorrect
   • BStorageClass
   • CConfigMap
   • DPersistentVolumeClaim
   ✓ Correct answer: A

   A PersistentVolume (PV) is a cluster-scoped Kubernetes resource that models a piece of physical or virtual storage. It can be statically provisioned by a cluster administrator who creates the PV object pointing to existing storage infrastructure, or dynamically provisioned by a StorageClass provisioner in response to a PersistentVolumeClaim. The PV holds all the details about how to access the storage - such as the access modes, capacity, and backend-specific connection parameters - while the PVC is merely the consumer's request that binds to a matching PV.

   Why the other options are wrong

   • BStorageClass defines the provisioner, reclaim policy, and parameters used to dynamically create PVs, but it is not itself a piece of provisioned storage.
   • CConfigMap stores non-sensitive configuration data as key-value pairs for use by Pods and has nothing to do with block or file storage provisioning.
   • DPersistentVolumeClaim is a namespace-scoped request for storage submitted by a user or workload; it consumes a PV rather than representing the underlying storage itself.
8. Question 8Storage

   Which volume source allows you to mount a bound service account token as a file with configurable expiration?

   • AdownwardAPI with fieldPath spec.serviceAccountName
   • BconfigMap containing the token
   • CserviceAccountToken projected sourceCorrect
   • DSecret volume referencing the token secret
   ✓ Correct answer: C

   The serviceAccountToken source, used inside a projected volume, requests a short-lived, audience-scoped token from the TokenRequest API and writes it into the pod as a file. It supports an expirationSeconds field to control the token lifetime and an audience field to bind the token to a specific recipient, and the kubelet automatically rotates the token before it expires. This is the modern, recommended way to surface a bound service account token, replacing the legacy auto-mounted secret-based token. The token is therefore tied to the pod's lifetime and far harder to misuse than a long-lived secret.

   Why the other options are wrong

   • AdownwardAPI with fieldPath spec.serviceAccountName is incorrect because the downward API can only expose the account name string, not an actual authentication token.
   • BconfigMap containing the token is incorrect because ConfigMaps are not designed to hold credentials, are not rotated, and cannot generate a bound token with an expiration.
   • Dsecret volume referencing the token secret is incorrect because secret-based tokens are long-lived, not rotated, and lack configurable expiration or audience binding.
9. Question 9Troubleshooting

   You want to see only the last 50 lines of logs from a pod. Which command is correct?

   • Akubectl logs my-pod --lines=50
   • Bkubectl logs my-pod -n 50
   • Ckubectl logs my-pod --tail=50Correct
   • Dkubectl logs my-pod --last=50
   ✓ Correct answer: C

   The --tail flag limits kubectl logs output to a specified number of lines counted from the end of the log, so --tail=50 returns only the most recent 50 lines. This is the supported kubectl logs option for restricting output length and is commonly combined with -f to follow a bounded tail of a live stream. It maps directly to the runtime's ability to seek to the last N lines of a container's log.

   Why the other options are wrong

   • Akubectl logs my-pod --lines=50 is incorrect because --lines is not a valid kubectl logs flag and will be rejected as an unknown option.
   • Bkubectl logs my-pod -n 50 is incorrect because -n is the shorthand for --namespace, so this would be interpreted as targeting a namespace named '50', not limiting line count.
   • Dkubectl logs my-pod --last=50 is incorrect because --last is not a recognized kubectl logs flag; line limiting is done exclusively with --tail.
10. Question 10Troubleshooting

    A StatefulSet pod "db-0" is stuck in Terminating because its PVC finalizer is blocking deletion. The PVC uses a volume that no longer exists. How do you resolve this?

    • ADelete the node object so the stuck StatefulSet pod is force-removed
    • BScale the StatefulSet to 0 so the controller releases the pod and PVC
    • CRestart the controller manager so it re-processes the PVC finalizer
    • Dkubectl patch pvc <name> -p '{"metadata":{"finalizers":null}}'Correct
    ✓ Correct answer: D

    A PersistentVolumeClaim carries a protection finalizer (kubernetes.io/pvc-protection) that keeps the object alive while it is referenced, and the deletion blocks until the finalizer is cleared. When the underlying volume no longer exists, the controller cannot complete its normal cleanup, so the finalizer is never removed and the PVC (and the pod referencing it) stays stuck in Terminating. Patching the PVC's metadata.finalizers to null removes the finalizer, allowing the API server to garbage-collect the object and unblock the pod's termination. This is the standard manual unblock for an orphaned PVC whose backing volume is gone.

    Why the other options are wrong

    • ADeleting the node removes an unrelated object and does not clear the PVC finalizer that is blocking pod deletion.
    • BScaling to 0 will itself hang because the pod cannot terminate while the PVC finalizer remains in place.
    • CRestarting the controller manager does not remove a stuck finalizer; the finalizer must be patched out of the PVC directly.

Who this CKA practice exam is for

This practice set is for anyone preparing for the CKA: Certified Kubernetes Administrator exam at the intermediate level - from first-time candidates building a foundation to experienced Cloud Native practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this CKA practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Treat your readiness score as knowledge readiness, then validate it with hands-on practice in a real environment before booking the CKA exam.

Related Cloud Native resources

• CKA study guideKey concepts
• Cloud Native practice examsAll Cloud Native
• Certification pathWhere this fits
• Best CKA Practice Exams (2026)Comparison
• CKA vs CKADComparison
• Cluster Architecture Installation and Configuration practice questions197 questions
• Workloads and Scheduling practice questions187 questions
• Services and Networking practice questions168 questions
• Storage practice questions168 questions
• Troubleshooting practice questions183 questions
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• Hands-on kubernetes labsLearn
• Hands-on docker labsLearn
• kubeadm and node operations cheat sheetCheat sheet
• kubectl cheat sheetCheat sheet
• Manifest field cheat sheetCheat sheet
• Kubernetes networking cheat sheetCheat sheet
• Kubernetes troubleshooting cheat sheetCheat sheet
• Docker command cheat sheetCheat sheet
• Docker Compose cheat sheetCheat sheet
• Dockerfile cheat sheetCheat sheet
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• CKAD practice examRelated
• CKS practice examRelated
• Istio Certified Associate (ICA) practice examRelated

CKA practice exam FAQ