LINUX certification preparation

CKA Practice Questions

Practice exam-style questions, check your answers, and review explanations and source references where they are available.

Exam: CKA
Provider: LINUX
Full set: 83 questions
Last Update Check: September 26, 2026

Browse LINUX exams View exam 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

1. Kubernetes Documentation

kubectl Commands Reference

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

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 Score:7% Context An existing Pod needs to be integrated into the Kubernetes built-in logging architecture (e. g. kubectl logs). Adding a streaming sidecar container is a good and common way to accomplish this requirement. Task Add a sidecar container named sidecar, using the busybox Image, to the existing Pod big-corp-app. The new sidecar container has to run the following command: /bin/sh -c tail -n+1 -f /va r/log/big-corp-app.log Use a Volume, mounted at /var/log, to make the log file big-corp-app.log available to the sidecar container.

Your Answer

Correct Answer:

THE FINAL POD MANIFEST (POD-DEFINITION.YAML) SHOULD BE AS FOLLOWS: YAML APIVERSION: V1 KIND: POD METADATA: NAME: BIG-CORP-APP OTHER METADATA FROM THE ORIGINAL POD WILL BE HERE SPEC: VOLUMES: - NAME: LOG-VOLUME EMPTYDIR: {} CONTAINERS: - NAME: BIG-CORP-APP # ASSUMING THIS IS THE ORIGINAL CONTAINER'S NAME IMAGE: # THE ORIGINAL CONTAINER'S IMAGE VOLUMEMOUNTS: - NAME: LOG-VOLUME MOUNTPATH: /VAR/LOG - NAME: SIDECAR IMAGE: BUSYBOX COMMAND: ["/BIN/SH", "-C", "TAIL -N+1 -F /VAR/LOG/BIG-CORP-APP.LOG"] VOLUMEMOUNTS: - NAME: LOG-VOLUME MOUNTPATH: /VAR/LOG EXECUTION STEPS: 1. KUBECTL GET POD BIG-CORP-APP -O YAML > POD-DEFINITION.YAML 2. MODIFY POD-DEFINITION.YAML TO MATCH THE CONFIGURATION ABOVE, ENSURING YOU ADD THE NEW SIDECAR CONTAINER, THE VOLUMES SECTION, AND THE VOLUMEMOUNTS TO BOTH CONTAINERS. REMOVE SYSTEM-ADDED METADATA LIKE RESOURCEVERSION, UID, ETC. 3. KUBECTL REPLACE --FORCE -F POD-DEFINITION.YAML OR KUBECTL DELETE POD BIG-CORP-APP && KUBECTL APPLY -F POD-DEFINITION.YAML

Explanation

The sidecar pattern is used to extend or enhance the functionality of an existing container. Since Pod specifications are largely immutable, you cannot add a container to a running Pod. The correct procedure is to retrieve the Pod's definition, add the new sidecar container configuration, and define a shared emptyDir volume. This volume is mounted into both the original application container and the new sidecar container at /var/log. This allows the sidecar to access and stream the log files generated by the main application, integrating it with kubectl logs. The Pod must then be replaced with the updated configuration.

Common Incorrect Approaches:

Using kubectl edit: Attempting to add a new container to a running Pod via kubectl edit pod big-corp-app will fail, as the spec.containers field is immutable.

Omitting the Volume from the Main Container: If the volumeMount is not added to the main application container, it will write logs to its own ephemeral filesystem, not the shared volume, and the sidecar will see nothing.

Using an incorrect command: The command must be structured correctly for the shell (-c) and use tail -f to continuously stream the file as new lines are added.

References

1. Kubernetes Documentation

"Pods": The official documentation explains that Pods are composed of one or more containers that share storage. It details the sidecar pattern for tasks like log streaming.

Reference: kubernetes.io/docs/concepts/workloads/pods/

Section: "Uses of Pods".

2. Kubernetes Documentation

"Volumes": This source describes the emptyDir volume type

which is created when a Pod is assigned to a node and exists as long as that Pod is running on that node. It is the standard method for sharing files between containers within the same Pod.

Reference: kubernetes.io/docs/concepts/storage/volumes/

Section: "emptyDir".

3. Kubernetes Documentation

"Logging Architecture": This page explicitly describes using a sidecar container as a logging agent. It states

"The sidecar container reads logs from a file... and then streams the logs to its own stdout." This exactly matches the task's requirement.

Reference: kubernetes.io/docs/concepts/cluster-administration/logging/

Section: "Sidecar container with a logging agent".

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

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.

CKA Practice Questions

Question 1 discussion

Question 2 discussion

Question 3 discussion

Question 4 discussion

Question 5 discussion

Question 6 discussion

Question 7 discussion

Question 8 discussion

Question 9 discussion

Question 10 discussion

How this practice set is maintained

How this practice set is maintained

More LINUX practice questions