Linux Foundation CKAD Certified Kubernetes Application Developer Exam Practice Test

Page: 1 / 14
Total 33 questions

Want more questions? Get Premium Access.
()

Question 1

Refer to Exhibit.

Context

A project that you are working on has a requirement for persistent data to be available.

Task

To facilitate this, perform the following tasks:

* Create a file on node sk8s-node-0 at /opt/KDSP00101/data/index.html with the content Acct=Finance

* Create a PersistentVolume named task-pv-volume using hostPath and allocate 1Gi to it, specifying that the volume is at /opt/KDSP00101/data on the cluster's node. The configuration should specify the access mode of ReadWriteOnce . It should define the StorageClass name exam for the PersistentVolume , which will be used to bind PersistentVolumeClaim requests to this PersistenetVolume.

* Create a PefsissentVolumeClaim named task-pv-claim that requests a volume of at least 100Mi and specifies an access mode of ReadWriteOnce

* Create a pod that uses the PersistentVolmeClaim as a volume with a label app: my-storage-app mounting the resulting volume to a mountPath /usr/share/nginx/html inside the pod

AExplanation:
Solution:

Answer : A

Question 2

Refer to Exhibit.

Set Configuration Context:

[student@node-1] $ | kubectl

Config use-context k8s

Context

A pod is running on the cluster but it is not responding.

Task

The desired behavior is to have Kubemetes restart the pod when an endpoint returns an HTTP 500 on the /healthz endpoint. The service, probe-pod, should never send traffic to the pod while it is failing. Please complete the following:

* The application has an endpoint, /started, that will indicate if it can accept traffic by returning an HTTP 200. If the endpoint returns an HTTP 500, the application has not yet finished initialization.

* The application has another endpoint /healthz that will indicate if the application is still working as expected by returning an HTTP 200. If the endpoint returns an HTTP 500 the application is no longer responsive.

* Configure the probe-pod pod provided to use these endpoints

* The probes should use port 8080

AExplanation:
Solution:
To have Kubernetes automatically restart a pod when an endpoint returns an HTTP 500 on the /healthz endpoint, you will need to configure liveness and readiness probes on the pod.
First, you will need to create a livenessProbe and a readinessProbe in the pod's definition yaml file. The livenessProbe will check the /healthz endpoint, and if it returns an HTTP 500, the pod will be restarted. The readinessProbe will check the /started endpoint, and if it returns an HTTP 500, the pod will not receive traffic.
Here's an example of how you can configure the liveness and readiness probes in the pod definition yaml file:
apiVersion: v1
kind: Pod
metadata:
name: probe-pod
spec:
containers:
- name: probe-pod
image: <image-name>
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /started
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
The httpGet specifies the endpoint to check and the port to use. The initialDelaySeconds is the amount of time the pod will wait before starting the probe. periodSeconds is the amount of time between each probe check, and the failureThreshold is the number of failed probes before the pod is considered unresponsive.
You can use kubectl to create the pod by running the following command:
kubectl apply -f <filename>.yaml
Once the pod is created, Kubernetes will start monitoring it using the configured liveness and readiness probes. If the /healthz endpoint returns an HTTP 500, the pod will be restarted. If the /started endpoint returns an HTTP 500, the pod will not receive traffic.
Please note that if the failure threshold is set to 3, it means that if the probe fails 3 times consecutively it will be considered as a failure.
The above configuration assumes that the application is running on port 8080 and the endpoints are available on the same port.

Answer : A

Question 3

Refer to Exhibit.

Task:

A pod within the Deployment named buffale-deployment and in namespace gorilla is logging errors.

1) Look at the logs identify errors messages.

Find errors, including User ''system:serviceaccount:gorilla:default'' cannot list resource ''deployment'' [...] in the namespace ''gorilla''

2) Update the Deployment buffalo-deployment to resolve the errors in the logs of the Pod.

The buffalo-deployment 'S manifest can be found at -/prompt/escargot/buffalo-deployment.yaml

AExplanation:
Solution:

Answer : A

Question 4

Refer to Exhibit.

Given a container that writes a log file in format A and a container that converts log files from format A to format B, create a deployment that runs both containers such that the log files from the first container are converted by the second container, emitting logs in format B.

Task:

* Create a deployment named deployment-xyz in the default namespace, that:

* Includes a primary

lfccncf/busybox:1 container, named logger-dev

* includes a sidecar Ifccncf/fluentd:v0.12 container, named adapter-zen

* Mounts a shared volume /tmp/log on both containers, which does not persist when the pod is deleted

* Instructs the logger-dev

container to run the command

which should output logs to /tmp/log/input.log in plain text format, with example values:

* The adapter-zen sidecar container should read /tmp/log/input.log and output the data to /tmp/log/output.* in Fluentd JSON format. Note that no knowledge of Fluentd is required to complete this task: all you will need to achieve this is to create the ConfigMap from the spec file provided at /opt/KDMC00102/fluentd-configma p.yaml , and mount that ConfigMap to /fluentd/etc in the adapter-zen sidecar container

AExplanation:
Solution:

Answer : A

Question 5

Refer to Exhibit.

Context

You are asked to prepare a Canary deployment for testing a new application release.

Task:

A Service named krill-Service in the goshark namespace points to 5 pod created by the Deployment named current-krill-deployment

1) Create an identical Deployment named canary-kill-deployment, in the same namespace.

2) Modify the Deployment so that:

-A maximum number of 10 pods run in the goshawk namespace.

-40% of the krill-service 's traffic goes to the canary-krill-deployment pod(s)

AExplanation:
Solution:

Answer : A

Question 6

Refer to Exhibit.

Set Configuration Context:

[student@node-1] $ | kubectl

Config use-context k8s

Context

A user has reported an aopticauon is unteachable due to a failing livenessProbe .

Task

Perform the following tasks:

* Find the broken pod and store its name and namespace to /opt/KDOB00401/broken.txt in the format:

The output file has already been created

* Store the associated error events to a file /opt/KDOB00401/error.txt, The output file has already been created. You will need to use the -o wide output specifier with your command

* Fix the issue.

AExplanation:
To find the broken pod and store its name and namespace to /opt/KDOB00401/broken.txt, you can use the kubectl get pods command and filter the output by the status of the pod.
kubectl get pods --field-selector=status.phase=Failed -o jsonpath='{.items[*].metadata.namespace}/{.items[*].metadata.name}' > /opt/KDOB00401/broken.txt
This command will list all pods with a status of Failed and output their names and namespaces in the format <namespace>/. The output is then written to the /opt/KDOB00401/broken.txt file.
To store the associated error events to a file /opt/KDOB00401/error.txt, you can use the kubectl describe command to retrieve detailed information about the pod, and the grep command to filter the output for error events.
kubectl describe pods --namespace | grep -i error -B5 -A5 > /opt/KDOB00401/error.txt
Replace and with the name and namespace of the broken pod you found in the previous step.
This command will output detailed information about the pod, including error events. The grep command filters the output for lines containing 'error' and also prints 5 lines before and after the match.
To fix the issue, you need to analyze the error events and find the root cause of the issue.
It could be that the application inside the pod is not running, the container image is not available, the pod has not enough resources, or the liveness probe configuration is incorrect.
Once you have identified the cause, you can take appropriate action, such as restarting the application, updating the container image, increasing the resources, or modifying the liveness probe configuration.
After fixing the issue, you can use the kubectl get pods command to check the status of the pod and ensure

Answer : A

Question 7

Refer to Exhibit.

Task

A Deployment named backend-deployment in namespace staging runs a web application on port 8081.

AExplanation:
Solution:

Answer : A