Linux Foundation certification practice

Free CKA Practice Test

10 free CKA exam-style questions for Certified Kubernetes Administrator, with answers, explanations and source references.

Last updated August 11, 2026

Full set: 83 questions

Our CKA exam simulator covers all the critical knowledge points of the real exam. We provide the latest actual CKA exam questions and answers right here at Cert Mage. With our included answer explanations and comprehensive CKA question bank, you will find everything you need to prepare and achieve the best score on your exam easily and quickly.

Get Full Access

SIMULATION You must connect to the correct host. Failure to do so may result in a zero score. [candidate@base] $ ssh Cka000037 Context A legacy app needs to be integrated into the Kubernetes built-in logging architecture (i.e. kubectl logs). Adding a streaming co-located container is a good and common way to accomplish this requirement. Task Update the existing Deployment synergy-leverager, adding a co-located container named sidecar using the busybox:stable image to the existing Pod . The new co-located container has to run the following command: /bin/sh -c "tail -n+1 -f /var/log/syne rgy-leverager.log" Use a Volume mounted at /var/log to make the log file synergy-leverager.log available to the co- located container . Do not modify the specification of the existing container other than adding the required volume mount . Failure to do so may result in a reduced score.

Your Answer

Correct Answer:

THE SPEC.TEMPLATE.SPEC OF THE SYNERGY-LEVERAGER DEPLOYMENT MUST BE MODIFIED AS FOLLOWS. YAML IN SPEC.TEMPLATE.SPEC: VOLUMES: - NAME: LOG-VOLUME EMPTYDIR: {} CONTAINERS: THE EXISTING CONTAINER MUST BE MODIFIED TO ADD THIS VOLUMEMOUNT: - NAME: ... OTHER EXISTING CONTAINER PROPERTIES VOLUMEMOUNTS: - NAME: LOG-VOLUME MOUNTPATH: /VAR/LOG THE NEW SIDECAR CONTAINER MUST BE ADDED: - NAME: SIDECAR IMAGE: BUSYBOX:STABLE COMMAND: ["/BIN/SH", "-C", "TAIL -N+1 -F /VAR/LOG/SYNERGY-LEVERAGER.LOG"] VOLUMEMOUNTS: - NAME: LOG-VOLUME MOUNTPATH: /VAR/LOG

Explanation

This configuration implements the sidecar logging pattern. An emptyDir volume is created and shared by both containers within the Pod. The primary application container writes its log file to this shared volume. The sidecar container reads the log file from the same volume and streams its content to standard output. This allows the Kubernetes API server, and therefore kubectl logs, to access the application's logs, effectively integrating the legacy application into the native Kubernetes logging system without modifying the application itself. The emptyDir volume's lifecycle is tied to the Pod, making it suitable for this purpose.

References

1. Kubernetes Documentation, "Logging Architecture": This document explicitly describes the "Sidecar container with a logging agent" pattern. It details using a shared volume to allow a sidecar to access and stream log files written by a main application container. (See section: Sidecar container with a logging agent).

2. Kubernetes Documentation, "Volumes": The official documentation on volumes describes the emptyDir volume type. It states, "An emptyDir volume is first created when a Pod is assigned to a node, and exists as long as that Pod is running on that node... Containers in the Pod can all read and write the same files in the emptyDir volume". (See section: emptyDir).

3. Kubernetes Documentation, "Pods": The design principles for Pods explain that containers within a Pod share storage volumes, which is the fundamental concept enabling the sidecar pattern for tasks like log collection. (See section: Pod design, subsection: Storage).

SIMULATION A Kubernetes worker node, named wk8s-node-0 is in state NotReady. Investigate why this is the case, and perform any appropriate steps to bring the node to a Ready state, ensuring that any changes are made permanent. You can ssh to the failed node using: [student@node-1] $ | ssh Wk8s-node-0 You can assume elevated privileges on the node with the following command: [student@w8ks-node-0] $ | sudo –i

Your Answer

Correct Answer:

BASH SYSTEMCTL ENABLE --NOW KUBELET

Explanation

The NotReady state indicates that the control plane's node controller has not received a status update (heartbeat) from the node's kubelet within the node-monitor-grace-period. The most common cause for this is a stopped or failed kubelet service on the worker node. The kubelet is the primary node agent responsible for registering the node with the apiserver and managing pods. The command systemctl enable --now kubelet both starts the service immediately and enables it to launch automatically on system boot, ensuring the fix is permanent and communication with the control plane is restored.

References

1. Kubernetes Official Documentation

"Nodes"

Section: "Node Status". This section details that the Ready condition is reported by the kubelet. If the node controller does not receive a heartbeat

it marks the node as NotReady.

Source: https://kubernetes.io/docs/concepts/architecture/nodes/#node-status

2. Kubernetes Official Documentation

"Debug Cluster"

Section: "Debugging nodes". This guide explicitly recommends checking the status of the kubelet service using systemctl status kubelet as a primary step when a node is in a failure state like NotReady.

Source: https://kubernetes.io/docs/tasks/debug/debug-cluster/#debugging-nodes

3. Kubernetes Official Documentation

"kubeadm"

Section: "Managing the kubelet". This document explains that in clusters set up with kubeadm

the kubelet is configured to run as a systemd service. Using systemctl enable is the correct procedure to ensure the service starts on boot.

Source: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#managing-the-kubelet

4. Red Hat Official Documentation

"RHEL 8: Configuring basic system settings"

Chapter 9: "Managing system services with systemd". This vendor documentation details the usage of systemctl

confirming that enable --now is the standard command to start a service and simultaneously enable it for startup at boot.

Source: Section 9.2.3

"Starting services" and Section 9.2.4

"Enabling services".

SIMULATION Create a deployment as follows: Name: nginx-random Exposed via a service nginx-random Ensure that the service and pod are accessible via their respective DNS records The container(s) within any pod(s) running as a part of this deployment should use the nginx Image Next, use the utility nslookup to look up the DNS records of the service and pod and write the output to /opt/KUNW00601/service.dns and /opt/KUNW00601/pod.dns respectively.

Your Answer

Correct Answer:

BASH CREATE THE DEPLOYMENT KUBECTL CREATE DEPLOYMENT NGINX-RANDOM --IMAGE=NGINX EXPOSE THE DEPLOYMENT WITH A SERVICE KUBECTL EXPOSE DEPLOYMENT NGINX-RANDOM --NAME=NGINX-RANDOM --PORT=80 --TARGET-PORT=80 WAIT FOR THE POD TO BE RUNNING TO ENSURE IT HAS AN IP KUBECTL WAIT --FOR=CONDITION=READY POD -L APP=NGINX-RANDOM --TIMEOUT=60S CREATE THE DIRECTORY IF IT DOESN'T EXIST MKDIR -P /OPT/KUNW00601 PERFORM NSLOOKUP FOR THE SERVICE AND SAVE THE OUTPUT NSLOOKUP NGINX-RANDOM.DEFAULT.SVC.CLUSTER.LOCAL > /OPT/KUNW00601/SERVICE.DNS GET THE POD IP AND CONSTRUCT THE DNS NAME PODIP=$(KUBECTL GET POD -L APP=NGINX-RANDOM -O JSONPATH='{.ITEMS[0].STATUS.PODIP}') PODDNSNAME=$(ECHO ${PODIP} | SED 'S/\./-/G').DEFAULT.POD.CLUSTER.LOCAL PERFORM NSLOOKUP FOR THE POD AND SAVE THE OUTPUT NSLOOKUP ${PODDNSNAME} > /OPT/KUNW00601/POD.DNS

Explanation

The solution first uses kubectl create deployment to deploy an nginx container. The kubectl expose command then creates a ClusterIP service named nginx-random to provide a stable endpoint for the deployment. For DNS resolution, Kubernetes automatically creates records. A Service's DNS A record (..svc.cluster.local) resolves to its cluster IP. A Pod's DNS A record (..pod.cluster.local) resolves to the pod's IP. The nslookup utility queries the cluster's DNS service (CoreDNS) for these records. The script dynamically retrieves the pod's IP to construct its unique DNS name before performing the lookup and redirecting the output to the specified files.

References

1. Kubernetes Documentation

"DNS for Services and Pods": This document details the DNS naming conventions for both services and pods within a Kubernetes cluster

which is the basis for the nslookup commands.

Reference: Section "Services" and "Pods". https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods

2. Kubernetes Documentation

"Imperative Commands": This guide provides the official syntax and examples for creating resources like deployments and services using imperative kubectl commands

as used in the solution.

Reference: Section "Creating objects"

kubectl create deployment and kubectl expose. https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/

3. Kubernetes Documentation

"kubectl Cheat Sheet": This official reference provides concise examples for common operations

including creating and exposing deployments.

Reference: Section "Create". https://kubernetes.io/docs/reference/kubectl/cheatsheet/#create

4. Kubernetes Documentation

"JSONPath Support": This page explains how to use jsonpath to extract specific fields

such as the podIP

from the API server's response.

Reference: kubectl command examples. https://kubernetes.io/docs/reference/kubectl/jsonpath/

SIMULATION List the nginx pod with custom columns POD_NAME and POD_STATUS

Your Answer

Correct Answer:

KUBECTL GET POD NGINX -O CUSTOM-COLUMNS=PODNAME:.METADATA.NAME, PODSTATUS:.STATUS.PHASE

Explanation

This command retrieves information about the pod named nginx. The -o custom-columns flag is used to specify a custom output format. It accepts a comma-separated list of HEADER:JSONPath definitions. In this case, PODNAME:.metadata.name creates a column with the header PODNAME and populates it with the value from the .metadata.name field of the pod object. Similarly, PODSTATUS:.status.phase creates a column with the header PODSTATUS and populates it with the value from the .status.phase field, which reflects the pod's current state (e.g., Pending, Running, Succeeded).

References

2. Kubernetes Documentation, Tasks, "JSONPath Support": This document details the use of JSONPath expressions to filter and format output from kubectl. It provides examples for accessing specific fields within Kubernetes objects, such as .metadata.name for the object's name and .status.phase for a pod's status. (See the "JSONPath Expressions" section).

3. Kubernetes Documentation, kubectl Cheat Sheet: Under the "Formatting Output" section, the use of custom-columns is explicitly demonstrated with the syntax: kubectl get pods -o custom-columns=NAME:.metadata.name, RSRC:.metadata.resourceVersion. This confirms the required format for the answer.

SIMULATION Create a persistent volume with name app-data, of capacity 2Gi and access mode ReadWriteMany. The type of volume is hostPath and its location is /srv/app-data.

Your Answer

Correct Answer:

YAML APIVERSION: V1 KIND: PERSISTENTVOLUME METADATA: NAME: APP-DATA SPEC: CAPACITY: STORAGE: 2GI ACCESSMODES: - READWRITEMANY HOSTPATH: PATH: "/SRV/APP-DATA"

Explanation

This YAML manifest defines a PersistentVolume (PV) resource as required. The metadata.name is set to app-data. The spec section configures the volume's properties: capacity.storage is set to 2Gi, accessModes is set to ReadWriteMany allowing multiple nodes to mount the volume for read-write access, and the volume type is defined using hostPath. The hostPath.path specifies the directory /srv/app-data on the node's filesystem that will be used for this volume. This configuration directly fulfills all requirements of the simulation task.

References

1. Official Kubernetes Documentation

"Persistent Volumes": The concept and configuration of a hostPath PersistentVolume are detailed. The example provided under the hostPath section shows the exact syntax used in the answer.

Reference: Kubernetes Documentation > Concepts > Storage > Persistent Volumes > Section: "hostPath". (https://kubernetes.io/docs/concepts/storage/persistent-volumes/#hostpath)

2. Official Kubernetes API Reference

"PersistentVolumeSpec v1 core": This document provides the formal API definition for the PersistentVolume resource. It specifies hostPath

capacity

and accessModes as valid fields within the spec section

confirming the structure and values used in the answer.

Reference: Kubernetes Documentation > Reference > API Reference > v1.29 > Resources > PersistentVolumeSpec. (https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)

SIMULATION Get list of all pods in all namespaces and write it to file “/opt/pods-list.yaml”

Your Answer

Correct Answer:

KUBECTL GET PODS --ALL-NAMESPACES -O YAML > /OPT/PODS-LIST.YAML

Explanation

This command retrieves a list of all Pods from every namespace within the Kubernetes cluster and saves the output to a file. The kubectl get pods part of the command specifies the resource type to query. The --all-namespaces flag (short form -A) instructs kubectl to perform the action across all available namespaces, not just the current one. The -o yaml flag formats the output in YAML, as implied by the requested file extension. Finally, the standard shell redirection operator > writes the command's standard output to the specified file path /opt/pods-list.yaml, overwriting the file if it already exists.
References:
1. Kubernetes Official Documentation, kubectl get command: Location: kubectl Commands Reference > kubectl get Details: The documentation explicitly lists the --all-namespaces flag with the description: "If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace." It also details the -o, --output flag for specifying output formats, including yaml. Source: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get
2. Kubernetes Official Documentation, "Viewing, finding, and retrieving resources": Location: Tasks > Monitoring, Logging, and Debugging > Viewing, finding, and retrieving resources Details: This document provides practical examples, stating: "To see all Pods in all namespaces, you can use the --all-namespaces flag." It also demonstrates the use of the -o flag for custom output formats. Source: https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#viewing-finding-and-retrieving-resources
3. University of California, Berkeley, EECS Courseware (CS 162): Location: Lab 6: Introduction to Kubernetes, Section "Part 2: Interacting with the cluster" Details: The course lab materials demonstrate the fundamental usage of kubectl get pods and the concept of namespaces, including commands like kubectl get pods --namespace=, which establishes the foundational knowledge for using the --all-namespaces flag for a broader query. Source: https://cs162.eecs.berkeley.edu/static/labs/k8s-lab.html

SIMULATION Create a nginx pod with label env=test in engineering namespace

Your Answer

Correct Answer:

BASH KUBECTL RUN NGINX --IMAGE=NGINX --LABELS=ENV=TEST -N ENGINEERING

Explanation

This command imperatively creates a Pod in the engineering namespace. The kubectl run command is used for creating workload resources. The argument nginx sets the Pod's name. The --image=nginx flag specifies the container image to use. The --labels=env=test flag applies the required label to the Pod's metadata. Finally, the -n engineering (or --namespace=engineering) flag ensures the Pod is created in the specified engineering namespace, fulfilling all requirements of the task.

References

1. Kubernetes Official Documentation

kubectl Commands: The kubectl run command is detailed for creating a Pod from an image. The syntax kubectl run NAME --image=image -- [COMMAND] [ARGS...] is provided

along with flags like --labels and --namespace.

Source: Kubernetes Documentation

"kubectl run"

kubectl Cheat Sheet.

2. Kubernetes Official Documentation

Pods: This document explains that a Pod is the smallest deployable computing unit in Kubernetes and can contain one or more containers. The task requires creating a single-container Pod.

Source: Kubernetes Documentation

Concepts > Workloads > Pods

"Pod Overview".

3. Kubernetes Official Documentation

Labels and Selectors: This section details the usage of labels as key/value pairs attached to objects

such as Pods. The question requires attaching the label env=test.

Source: Kubernetes Documentation

Concepts > Overview > "Labels and Selectors".

4. Kubernetes Official Documentation

Namespaces: This document describes how namespaces provide a scope for names and a way to divide cluster resources. The -n or --namespace flag is the standard method for specifying the target namespace for an operation.

Source: Kubernetes Documentation

Concepts > "Namespaces".

SIMULATION Create a busybox pod that runs the command “env” and save the output to “envpod” file

Your Answer

Correct Answer:

BASH KUBECTL RUN BUSYBOX-ENV --IMAGE=BUSYBOX --RESTART=NEVER --RM --ATTACH --COMMAND -- ENV > ENVPOD

Explanation

This single command accomplishes the task efficiently. The kubectl run command creates a temporary pod. The --restart=Never flag ensures it's a one-off task pod, not a long-running deployment. The --command -- env specifies that the pod should execute the env command upon starting. The --attach flag connects to the pod's standard output, streaming the result of the env command. This output is then redirected (>) to the envpod file on the local machine. Finally, the --rm flag ensures the pod is automatically deleted after the command completes, maintaining a clean cluster state.

References

1. Kubernetes Official Documentation

kubectl run command: The documentation details the flags used.

--restart=Never: "The restart policy for this Pod. If set to 'Never'

a Pod is created."

--attach: "If true

wait for the Pod to start running

and then attach to the Pod's standard output and standard error."

--rm: "If true

delete resources created in this command on exit."

Source: Kubernetes Authors

kubectl run command reference

kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run.

2. Kubernetes Official Documentation

Pod Lifecycle: This document explains the pod lifecycle

including the Succeeded (or Completed) phase that a pod with restartPolicy: Never enters after its containers have successfully exited. This is the state the pod enters before being removed by the --rm flag.

Source: Kubernetes Authors

"Pod Lifecycle"

Section: "Pod phase"

kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase.

3. UC Berkeley

Data 100 Course Materials: University course

SIMULATION Schedule a Pod as follows: . Name: kucc1 . App Containers : 2 . Container Name/Images : redis Memcached

Your Answer

Correct Answer:

YAML APIVERSION: V1 KIND: POD METADATA: NAME: KUCC1 SPEC: CONTAINERS: - NAME: REDIS IMAGE: REDIS - NAME: MEMCACHED IMAGE: MEMCACHED

Explanation

This YAML manifest defines a Kubernetes Pod object as required. The metadata.name field is set to kucc1. The spec.containers field is an array that lists the containers to be run within the Pod. The first element in the array defines a container named redis using the redis image. The second element defines a container named memcached using the memcached image. This configuration precisely fulfills all the requirements of the simulation task by creating a single Pod with two specified application containers.

References

1. Kubernetes Official Documentation

"Pods": The core concept of a Pod encapsulating one or more containers is detailed here. The document states

"A Pod can contain multiple containers... The containers in a Pod are scheduled together on the same cluster node." The basic structure of a Pod manifest

including the spec.containers array

is also shown.

Source: Kubernetes Authors. (n.d.). Pods. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/workloads/pods/

Section: "What is a Pod?" and "Using Pods".

2. Kubernetes Official Documentation

"Pod Lifecycle": This document explains the containers field within the Pod specification (PodSpec). It describes this field as a "list of containers belonging to the pod" and specifies that each container must have a unique name within the Pod.

Source: Kubernetes Authors. (n.d.). Pod Lifecycle. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Section: "Container states".

3. Burns

Grant

Oppenheimer

Brewer

& Wilkes

J. (2016). Borg

Omega

and Kubernetes. ACM Queue

14(1)

70–93. This peer-reviewed article from the creators of Kubernetes provides the foundational academic context. It defines a Pod as "a collection of containers and volumes that are scheduled together... Containers in a pod are guaranteed to be co-located on the same machine."

Source: https://doi.org/10.1145/2898442.2898444

Section: "Kubernetes"

Paragraph 4.

SIMULATION Create a pod with image nginx called nginx and allow traffic on port 80

Your Answer

Correct Answer:

KUBECTL RUN NGINX --IMAGE=NGINX --PORT=80

Explanation

The kubectl run command is an imperative way to create a workload object in Kubernetes. In this case, it creates a Pod. The first argument, nginx, sets the metadata.name of the Pod. The --image=nginx flag specifies the container image to be used from the container registry. The --port=80 flag defines the containerPort within the Pod's container specification, exposing port 80 for intra-cluster communication. This single command fulfills all requirements of the simulation.

References

1. Kubernetes Official Documentation

kubectl Commands: The kubectl run command is detailed in the official command reference. It specifies the syntax kubectl run NAME --image=image [--port=port] ... for creating a Pod.

Source: Kubernetes Documentation

"kubectl run"

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run

2. Kubernetes Official Documentation

Pod API Reference: The Pod specification confirms that the ports field within a container definition is an array of ContainerPort objects

where containerPort is an integer representing the port number to expose from the container.

Source: Kubernetes API Reference

v1 core

Pod

https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#ports-v1-core

3. University of California

Berkeley

Courseware: Lab materials for cloud computing courses frequently use kubectl run as the initial method for introducing Pod creation due to its simplicity. For example

exercises in EECS C106B/206B

"Robotic Manipulation and Interaction

" involve creating pods to run ROS nodes.

Source: UC Berkeley

EECS C106B/206B

Lab 8: ROS on the Cloud with Kubernetes

Section "Creating a Pod". (Note: Specific course material links may change semester to semester

but the practice is standard in university-level Kubernetes instruction).

Question 1 of 10

Browse Linux Foundation exams

Source context

How this practice set is maintained

Maintained by the CertMage content team, this page loads questions from the exam dataset connected to its preparation resource. When an answer includes a supporting reference, it is shown with that answer so you can review the underlying vendor documentation.

Certification objectives, interfaces, and vendor services can change. Verify important details against the provider's current exam guide and documentation before your exam.

How this practice set is maintained

Linux Foundation KCNA certification exam

Kubernetes and Cloud Native Security Associate

Linux Foundation CGOA certification exam

Linux Foundation CKS certification exam

Linux Foundation CNPA certification exam

Linux Foundation FOCP certification exam