Free CKA Practice Test Questions and Answers (2026)

Q: 1

SIMULATION Score: 7% Linux CKA question

Task Reconfigure the existing deployment front-end and add a port specification named http exposing port 80/tcp of the existing container nginx. Create a new service named front-end-svc exposing the container port http. Configure the new service to also expose the individual Pods via a NodePort on the nodes on which they are scheduled.

Your Answer

Correct Answer:

See the solution below.

Explanation

1. Edit the deployment to add the named port:

bash

kubectl edit deployment front-end

In the editor, add the ports section to the nginx container specification:

yaml

spec:

containers:

- image: nginx

name: nginx

ports:

- name: http

containerPort: 80

protocol: TCP

Save and exit the editor.

2. Expose the deployment as a NodePort service:

bash

kubectl expose deployment front-end --name=front-end-svc --type=NodePort --port=80 --target-port=http

Explanation:

The first step, kubectl edit deployment front-end, opens the deployment's configuration. Adding a ports section with name: http and containerPort: 80 fulfills the requirement to define a named port on the container, which is a prerequisite for referencing it by name in a Service.

The second command, kubectl expose, creates a new Service. The --type=NodePort flag makes the service accessible from outside the cluster on a static port on each node. The --name=front-end-svc sets the service name. The --target-port=http flag specifically targets the named port http on the pods, as required by the task, while --port=80 defines the port on which the service is available internally within the cluster.

References:

1. Kubernetes Documentation, "Service": This document explains the different service types, including NodePort, which "Exposes the Service on each Node's IP at a static port (the NodePort)." It also details how a Service's targetPort can be a string, referring to the name of a port in the backend Pods.

Source: Kubernetes Authors, "Service," Kubernetes Documentation, Concepts > Services, Load Balancing, and Networking. (https://kubernetes.io/docs/concepts/services-networking/service/#nodeport)

2. Kubernetes Documentation, "kubectl expose": The official documentation for the kubectl expose command provides the syntax and options. It explicitly shows the use of --type=NodePort to create a NodePort service and --target-port to specify the port on the container that the service should target, which can be a port number or name.

Source: Kubernetes Authors, "kubectl expose," Kubernetes Documentation, Reference > kubectl > Commands. (https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#expose)

3. Kubernetes API Reference, "Container v1 core": The API specification for a Pod's container defines the ports field as a list of ContainerPort objects. Each ContainerPort object includes the name, containerPort, and protocol fields, confirming the structure used to reconfigure the deployment.

Source: Kubernetes Authors, "Container v1 core," Kubernetes Documentation, Reference > Kubernetes API > Workload Resources. (https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)

Q: 2

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).

Q: 3

SIMULATION Schedule a pod as follows: Name: nginx-kusc00101 Image: nginx Node selector: disk=ssd

Your Answer

Q: 4

SIMULATION Create a pod named kucc8 with a single app container for each of the following images running inside (there may be between 1 and 4 images specified): nginx + redis + memcached.

Your Answer

Correct Answer:

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

Explanation

A Kubernetes Pod can contain multiple co-located and co-scheduled containers that share resources like network and storage. The provided YAML manifest defines a single Pod object named kucc8. Within its specification (spec), the containers field is a list that defines the three required containers. Each entry in the list specifies a unique name (nginx, redis, memcached) and the corresponding container image as required by the question. Applying this manifest will create one Pod running all three specified container images.

References

1. Kubernetes Documentation

"Pods": The official documentation explains that a Pod can have multiple containers. "A Pod can contain multiple containers. When a Pod runs multiple containers

the containers are managed as a single entity and share the Pod's resources."

Source: Kubernetes Authors

Pods

Kubernetes Documentation.

Section: "Pods with multiple containers".

URL: https://kubernetes.io/docs/concepts/workloads/pods/#pods-with-multiple-containers

2. Kubernetes Documentation

"Pod API Reference": The API reference for the PodSpec v1 core shows that the containers field is a list of Container objects

explicitly allowing for more than one.

Source: Kubernetes Authors

API Reference v1.29

Kubernetes Documentation.

Section: PodSpec v1 core.

URL: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec

3. MIT OpenCourseWare

"6.824 Distributed Systems": Course materials often cover container orchestration concepts

including the multi-container pod pattern as a fundamental building block for tightly coupled applications. Lecture notes on Kubernetes describe pods as the atomic unit of scheduling

capable of holding one or more containers.

Source: Robert Morris

Frans Kaashoek

Lecture 12: Containers and Kubernetes

MIT OpenCourseWare

Spring 2020.

Section: Kubernetes architecture overview.

URL: https://ocw.mit.edu/courses/6-824-distributed-systems-spring-2020/

Q: 5

SIMULATION List the nginx pod with custom columns POD_NAME and POD_STATUS

Your Answer

Q: 6

SIMULATION Monitor the logs of pod foo and: Extract log lines corresponding to error unable-to-access-website Write them to/opt/KULM00201/foo

Your Answer

Q: 7

SIMULATION Score: 5%

Task Monitor the logs of pod bar and: • Extract log lines corresponding to error file-not-found • Write them to /opt/KUTR00101/bar

Your Answer

Correct Answer:

KUBECTL LOGS BAR | GREP "ERROR FILE-NOT-FOUND" > /OPT/KUTR00101/BAR

Explanation

This command is a standard Linux pipeline for log processing. The kubectl logs bar command retrieves the standard output and error streams from the pod named bar. The pipe symbol | redirects this output to the grep "error file-not-found" command, which filters the log stream, only passing through lines that contain the specified error string. Finally, the output redirection operator > writes the filtered lines from grep into the target file /opt/KUTR00101/bar, overwriting the file if it already exists. This sequence efficiently accomplishes the task of extracting and saving specific log entries.

References

1. Kubernetes Official Documentation

kubectl logs: The command kubectl logs is used to print the logs for a container in a pod. The documentation provides examples of its usage

including piping the output to other commands like grep. (See "Examples" section).

Source: kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs

2. Kubernetes Official Documentation

"Logging Architecture": This document explains that the basic logging mechanism in Kubernetes relies on capturing the standard output (stdout) and standard error (stderr) streams of containers. The kubectl logs command is the primary tool for accessing these basic logs.

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

Section: "Basic logging in Kubernetes".

3. MIT OpenCourseWare

"The Missing Semester of Your CS Education": Lecture 1 covers shell tools

explicitly detailing the use of the pipe | to chain programs and the output redirection operator > to direct a command's output to a file.

Source: missing.csail.mit.edu/2020/course-notes/

Section: "Lecture 1: The Shell"

Subsection: "I/O Redirection".

Q: 8

SIMULATION Create a deployment spec file that will: Launch 7 replicas of the nginx Image with the labelapp_runtime_stage=dev deployment name: kual00201 Save a copy of this spec file to /opt/KUAL00201/spec_deployment.yaml (or /opt/KUAL00201/spec_deployment.json). When you are done, clean up (delete) any new Kubernetes API object that you produced during this task.

Your Answer

Correct Answer:

YAML APIVERSION: APPS/V1 KIND: DEPLOYMENT METADATA: NAME: KUAL00201 SPEC: REPLICAS: 7 SELECTOR: MATCHLABELS: APPRUNTIMESTAGE: DEV TEMPLATE: METADATA: LABELS: APPRUNTIMESTAGE: DEV SPEC: CONTAINERS: - NAME: NGINX IMAGE: NGINX

Explanation

This YAML manifest defines a Kubernetes Deployment named kual00201 with 7 replicas. The Pod template (spec.template) specifies the nginx container image and is assigned the label appruntimestage: dev. For the Deployment controller to correctly identify and manage the Pods it creates, the spec.selector.matchLabels field must exactly match the labels defined in spec.template.metadata.labels.

To complete the simulation:

1. Create the file: mkdir -p /opt/KUAL00201 && cat > /opt/KUAL00201/specdeployment.yaml (paste the YAML above, then press CTRL+D).

2. Apply the manifest to create the object: kubectl apply -f /opt/KUAL00201/specdeployment.yaml.

3. Clean up the created object: kubectl delete deployment kual00201.

References

1. Kubernetes Official Documentation

"Deployments": The core concepts of a Deployment are detailed here. It specifies that .spec.selector is a required field that defines how the Deployment finds which Pods to manage

and these labels must match those in the Pod template (.spec.template.metadata.labels).

Source: Kubernetes Documentation > Concepts > Workloads > Controllers > Deployment.

Section: "Creating a Deployment"

"Specifying a Deployment Strategy".

2. Kubernetes API Reference

"DeploymentSpec v1 apps": This official API documentation provides the formal schema for the Deployment object. It defines replicas as the desired number of Pods

selector as the label selector for pods targeted by this deployment

and template as the template for the Pods to be created.

Source: Kubernetes Documentation > Reference > Kubernetes API > Workload Resources > Deployment v1.

Section: spec object definition.

3. Kubernetes Official Documentation

"Imperative Commands": While the final answer is a declarative YAML file

it can be bootstrapped using an imperative command like kubectl create deployment kual00201 --image=nginx --replicas=7 --dry-run=client -o yaml. This command generates a base manifest that can then be edited to add the specific labels to the selector and template.

Source: Kubernetes Documentation > Reference > Kubectl > kubectl create deployment.

Section: "Examples".

Q: 9

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".

Q: 10

SIMULATION Get IP address of the pod – “nginx-dev”

Your Answer

Correct Answer:

KUBECTL GET POD NGINX-DEV -O JSONPATH='{.STATUS.PODIP}'

Explanation

The command kubectl get pod nginx-dev retrieves the specified pod resource. To extract only the IP address, the --output (or -o) flag is used with the jsonpath format. JSONPath is a query language for JSON that allows you to select specific fields from the resource's data structure. The expression {.status.podIP} navigates the pod's object hierarchy to the status field and then to the podIP sub-field, returning its value directly. An alternative, less precise command is kubectl get pod nginx-dev -o wide, which displays the IP address in an additional column along with other information.

References

1. Kubernetes Authors. (n.d.). JSONPath Support. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/kubectl/jsonpath/. (See the "Examples" section for usage with pod fields).

2. Kubernetes Authors. (n.d.). kubectl Cheat Sheet. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/kubectl/cheatsheet/. (See the "Viewing & Finding Resources" section

which demonstrates the use of kubectl get ... -o wide to view pod IPs).

3. Kubernetes Authors. (n.d.). kubectl-get. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get. (See the --output flag description and examples for jsonpath).

4. Borah

& Pister

K. (2021). Lab 7: AWS-F1 Tutorial 3: Debugging with Vivado ILA. University of California

Berkeley

EECS 151/251A. Retrieved from https://inst.eecs.berkeley.edu/~eecs151/sp21/labs/lab7/fpgalab7awsf1tutorial3.pdf. (In Section "Monitoring the Build Process"

the document instructs the use of kubectl get pods -o wide to obtain pod IP addresses).

Q: 11

SIMULATION Check the image version in pod without the describe command

Your Answer

Q: 12

SIMULATION Check the Image version of nginx-dev pod using jsonpath

Your Answer

Correct Answer:

KUBECTL GET POD NGINX-DEV -O JSONPATH='{.SPEC.CONTAINERS[0].IMAGE}'

Explanation

This command uses kubectl to retrieve information about the pod named nginx-dev. The -o jsonpath flag instructs kubectl to filter the standard JSON output using the provided JSONPath expression. The expression {.spec.containers[0].image} navigates the Pod's API object structure. It accesses the spec field, then the containers array, selects the first container ([0]), and finally extracts the value of the image field, which contains the image name and version tag.

References

1. Kubernetes Documentation

"JSONPath Support": This official document details how to use JSONPath expressions with kubectl to filter specific fields from JSON output. The example kubectl get pods -o=jsonpath='{.items[0].metadata.name}' demonstrates the syntax. The expression {.spec.containers[0].image} follows this documented syntax.

Source: Kubernetes Authors

JSONPath Support

Kubernetes Documentation. Available at: https://kubernetes.io/docs/reference/kubectl/jsonpath/

2. Kubernetes API Reference

"PodSpec v1 core": The official API documentation for a Pod object confirms the path used in the command. It defines the Pod structure as having a spec field (PodSpec)

which contains a list of containers ([]Container)

where each container object has an image string field.

Source: Kubernetes Authors

API Reference > core > v1 > PodSpec

Kubernetes Documentation. Available at: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#podspec-v1-core

3. Kubernetes Documentation

"kubectl Cheat Sheet": This guide provides common kubectl commands

including examples for formatting output. Under the "Formatting output" section

it lists the use of jsonpath for "Output the value of a specific field of the first element of a list."

Source: Kubernetes Authors

kubectl Cheat Sheet

Kubernetes Documentation. Available at: https://kubernetes.io/docs/reference/kubectl/cheatsheet/#formatting-output

Q: 13

SIMULATION Create a pod that having 3 containers in it? (Multi-Container)

Your Answer

Q: 14

SIMULATION Create a file: /opt/KUCC00302/kucc00302.txt that lists all pods that implement service baz in namespace development. The format of the file should be one pod name per line.

Your Answer

Correct Answer:

BASH KUBECTL GET ENDPOINTS BAZ -N DEVELOPMENT -O JSONPATH='{RANGE .SUBSETS[].ADDRESSES[]}{.TARGETREF.NAME}{"\N"}{END}' > /OPT/KUCC00302/KUCC00302.TXT

Explanation

This command directly retrieves the pods backing the baz service. The kubectl get endpoints command is used because an Endpoints object maps a service to its backing pods. The -n development flag specifies the correct namespace. The -o jsonpath option formats the output, where the expression '{range .subsets[].addresses[]}{.targetRef.name}{"\n"}{end}' iterates through each endpoint address, extracts the pod name from the targetRef.name field, and appends a newline character to ensure each pod name is on a separate line. The > operator redirects this formatted output to the specified file, fulfilling all requirements of the task.

References:

1. Kubernetes Official Documentation, "Services": This document explains that for each Service, the control plane creates a corresponding Endpoints object. This object contains a list of the internal IP addresses and ports of the pods that the service routes traffic to. This establishes the direct link between a Service and its backing Pods via the Endpoints object.

Source: Kubernetes Authors. (2023). Services. Kubernetes Documentation.

Reference: Section: "Endpoints" (https://kubernetes.io/docs/concepts/services-networking/service/#endpoints)

2. Kubernetes Official Documentation, "kubectl Cheat Sheet": This official guide provides examples of using jsonpath for advanced output formatting. It demonstrates how to iterate over items in a list and extract specific fields, which is the technique used in the correct answer.

Source: Kubernetes Authors. (2023). kubectl Cheat Sheet. Kubernetes Documentation.

Reference: Section: "Formatting output", subsection for jsonpath. (https://kubernetes.io/docs/reference/kubectl/cheatsheet/#formatting-output)

3. Kubernetes Official Documentation, "JSONPath Support": This page provides the definitive reference for using JSONPath expressions with kubectl. It details the syntax for ranging over arrays ({range .items[]}) and accessing nested fields (.targetRef.name), which are essential for constructing the correct command.

Source: Kubernetes Authors. (2023). JSONPath Support. Kubernetes Documentation.

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

Q: 15

SIMULATION Configure the kubelet systemd- managed service, on the node labelled with name=wk8s-node-1, to launch a pod containing a single container of Image httpd named webtool automatically. Any spec files required should be placed in the /etc/kubernetes/manifests directory on the node. You can ssh to the appropriate node using: [student@node-1] $ ssh wk8s-node-1 You can assume elevated privileges on the node with the following command: [student@wk8s-node-1] $ | sudo –i

Your Answer

Correct Answer:

BASH SSH WK8S-NODE-1 SUDO -I KUBECTL RUN WEBTOOL --IMAGE=HTTPD --DRY-RUN=CLIENT -O YAML > /ETC/KUBERNETES/MANIFESTS/WEBTOOL.YAML

Explanation

The task requires creating a static pod, which is managed directly by the kubelet daemon on a specific node, bypassing the API server. The kubelet monitors the directory specified by its staticPodPath configuration, which is /etc/kubernetes/manifests by default. By placing a pod manifest file in this directory, the kubelet automatically creates and runs the pod. The command kubectl run --dry-run=client -o yaml is an efficient, officially supported method to generate the required pod manifest YAML without interacting with the API server, and the output is redirected to a file within the static pod directory.

References

1. Kubernetes Official Documentation

"Static Pods": This document explains that the kubelet on a node can be configured to watch a directory for pod manifests. It states

"You configure the kubelet to use static pods by providing a path to a directory on that node... The kubelet periodically scans the configured directory... and creates/deletes pods as YAML/JSON files appear/disappear." The default path is typically /etc/kubernetes/manifests.

Source: Kubernetes Authors. (2023). Static Pods. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/

2. Kubernetes Official Documentation

"kubectl run": The kubectl run command is used to create workload resources. The --dry-run=client flag is specified to "only print the object that would be sent

without sending it." This allows for the generation of a valid manifest file.

Source: Kubernetes Authors. (2023). kubectl run. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run

3. Kubernetes Official Documentation

"KubeletConfiguration": The kubelet's behavior is defined by its configuration. The staticPodPath field within the KubeletConfiguration object specifies the directory to monitor for static pod manifests.

Source: Kubernetes Authors. (2023). KubeletConfiguration v1beta1. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration (See staticPodPath field description).

Question 1 of 20

Premium Access Includes