CKAD Practice Test 8 — 10 Questions

Question 1

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly resolving the OOM condition.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 2

You need to configure a liveness probe that checks if the container port 8080 is open. Which probe type should you use?

Accepted Answer

tcpSocket. A tcpSocket probe is the correct choice when you need to verify that a container is listening on a specific TCP port, such as port 8080. It works by attempting to open a TCP connection to the specified port; if the connection succeeds, the probe is considered successful. This is ideal for checking basic network-level readiness or liveness without requiring an HTTP endpoint or a custom command.

Answer

grpc

Answer

exec

Answer

httpGet

Question 3

A container in a pod is expected to shut down gracefully within 30 seconds when it receives SIGTERM. How should you configure the pod to ensure the container is given enough time to shut down before being forcefully killed?

Accepted Answer

Set spec.terminationGracePeriodSeconds: 35. terminationGracePeriodSeconds defines the time Kubernetes waits after sending SIGTERM before sending SIGKILL. Setting it to 35 seconds gives the container a 5-second buffer. Option B is correct. Option A is not a valid field. Option C sets the grace period too short. Option D sets it to an excessively long time.

Answer

Set spec.terminationGracePeriod: 35

Answer

Set spec.terminationGracePeriodSeconds: 300

Answer

Set spec.terminationGracePeriodSeconds: 20

Question 4

Which TWO of the following are valid types of probes in Kubernetes? (Select 2)

Accepted Answer

Readiness probe. A is correct because a Readiness probe determines whether a Pod is ready to serve traffic. If the probe fails, the Pod is removed from the Service's endpoints, preventing traffic from being routed to an unready container. This is essential for rolling updates and graceful shutdowns.

Answer

HTTP probe

Answer

Exec probe

Answer

TCP probe

Question 5

You have a Deployment with 3 replicas. The pods have a readiness probe that checks an HTTP endpoint /ready. One pod's readiness probe is failing. What will happen?

Accepted Answer

The pod will be removed from the Service endpoints. If a pod fails its readiness probe, it is removed from the Service endpoints. The pod remains running and is not restarted. Option B is correct. Option A is wrong because liveness probes cause restarts. Option C is incorrect because readiness failure does not decrease replicas. Option D is wrong.

Answer

The pod will be restarted by the kubelet

Answer

The Deployment will create a new pod to maintain 3 replicas

Answer

The pod will be terminated gracefully

Question 6

Which TWO are valid ways to debug a pod using ephemeral containers?

Accepted Answer

kubectl debug -it --image=busybox -- sh. Option A is correct because `kubectl debug -it --image=busybox -- sh` creates an ephemeral container in the target pod and attaches an interactive terminal to it. This is the standard Kubernetes mechanism for debugging a running pod without modifying its original container spec, using the ephemeral container feature (alpha in v1.16, stable in v1.23).

Answer

kubectl run debug --image=busybox -- sh

Answer

kubectl exec -it <pod> -- sh

Answer

kubectl attach to the pod

Question 7

Which command shows resource usage (CPU/memory) of pods in the default namespace?

Accepted Answer

kubectl top pod. Option C is correct because `kubectl top pod` is the Kubernetes command that displays real-time CPU and memory usage metrics for pods, leveraging the metrics server to collect resource utilization data. This command is essential for monitoring pod performance and is part of the Application Observability and Maintenance domain.

Answer

kubectl get pods -o wide

Answer

kubectl logs pod

Answer

kubectl describe pod

Question 8

Which TWO of the following are valid reasons to use a readiness probe? (Select 2)

Accepted Answer

To prevent traffic from being sent to a pod that is not ready due to a dependency. A readiness probe is used to determine whether a pod is ready to serve traffic. Option A is correct because it prevents traffic from being sent to a pod that is not ready due to a dependency, such as a database or cache that hasn't fully initialized. The kubelet uses the probe's success or failure to control whether the pod's IP address is added to the endpoints of a Service, ensuring only ready pods receive requests.

Answer

To monitor resource usage and scale the pod

Answer

To delay the start of the application until a database is available

Answer

To restart the container if it becomes unresponsive

Question 9

You have a Deployment with a liveness probe using an exec command. The probe currently runs 'cat /tmp/healthy' and fails after 3 failures. You notice the pod is being restarted even though the application is healthy. What is the most likely cause?

Accepted Answer

The file /tmp/healthy does not exist or is not being updated by the application. Option C is correct because the liveness probe executes 'cat /tmp/healthy' and fails after 3 consecutive failures. If the file /tmp/healthy does not exist or is not being updated by the application, the command returns a non-zero exit code, causing the probe to fail and Kubernetes to restart the container even though the application process itself is running and healthy.

Answer

The readiness probe is misconfigured and is shutting down the pod

Answer

The liveness probe is using the wrong HTTP endpoint

Answer

The probe timeoutSeconds is set too low, causing the probe to fail before the command completes

Question 10

Which THREE of the following are correct statements about the terminationGracePeriodSeconds field? (Select 3)

Accepted Answer

The default value is 30 seconds. Option A is correct because the Kubernetes documentation specifies that the default value for terminationGracePeriodSeconds is 30 seconds. This field is part of the PodSpec and controls the duration between sending SIGTERM to the container and forcefully killing it with SIGKILL. If not set, Kubernetes applies this default to ensure a reasonable window for graceful shutdown.

Answer

The default value is 0 seconds

Answer

It is used to configure the readiness probe timeout