CKAD Application Observability and Maintenance Practice Test 8 — 15 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 with an OOMKilled message, which indicates the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it has exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause.

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 view the logs of a container named 'sidecar' in a pod called 'app-pod' running in namespace 'dev'. Which command should you use?

Accepted Answer

kubectl logs app-pod --container=sidecar --namespace=dev. The correct command is 'kubectl logs app-pod -c sidecar -n dev'. The -c flag specifies the container name when a pod has multiple containers. Option A omits the -c flag. Options C and D use incorrect flags.

Answer

kubectl logs sidecar -p app-pod -n dev

Answer

kubectl logs app-pod -n dev

Question 3

You are debugging a pod that is running but not responding to network requests on port 8080. You suspect the application inside the container is faulty. You need to run an interactive shell inside the container to inspect the process. Which command should you use?

Accepted Answer

kubectl exec -it pod-name -- /bin/sh. The correct command is 'kubectl exec -it pod-name -- /bin/sh'. The -it flags enable interactive terminal. Option B is for reading logs. Option C is for debugging with an ephemeral container. Option D is for describing the pod.

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name -f

Answer

kubectl debug -it pod-name --image=busybox

Question 4

A developer configures a liveness probe for a container that takes a long time to start (about 120 seconds). The probe uses httpGet on port 8080 with a path '/healthz'. The probe is configured with initialDelaySeconds=10, periodSeconds=10, failureThreshold=3. The pod enters CrashLoopBackOff. What is the MOST likely cause?

Accepted Answer

The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container. The liveness probe starts after 10 seconds and will fail repeatedly because the application is not ready. After 3 failures (30 seconds total), the container is restarted, but it still needs ~120 seconds to start, causing a loop. A startup probe should be used to give the container time to start before liveness probes begin.

Answer

The failureThreshold should be increased to 10

Answer

The httpGet path '/healthz' is incorrect and should be '/ready'

Answer

The readiness probe is misconfigured and should be used instead of a liveness probe

Question 5

You want to view the resource usage of all pods running on a node named 'node01'. Which command should you use?

Accepted Answer

kubectl top pods --all-namespaces --field-selector spec.nodeName=node01. Option C is correct because `kubectl top pods` retrieves real-time CPU and memory usage metrics for pods, and the `--field-selector spec.nodeName=node01` filter restricts the output to only pods scheduled on the specified node. This directly answers the requirement to view resource usage of all pods on 'node01'.

Answer

kubectl top nodes node01

Answer

kubectl get pods -o wide --all-namespaces --field-selector spec.nodeName=node01

Answer

kubectl describe node node01 | grep -A 10 'Non-terminated Pods'

Question 6

A pod is stuck in the Pending state. You run 'kubectl describe pod pod-name' and see the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 nodes had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.' What is the MOST likely cause?

Accepted Answer

The nodes have disk pressure and the pod lacks tolerations. The disk-pressure taint on 3 nodes indicates those nodes have disk pressure. The control-plane taint on 1 node is normal. The pod cannot be scheduled because nodes are tainted and the pod does not have corresponding tolerations. The solution is to either free disk space on the nodes or add tolerations.

Answer

The pod has a resource request that exceeds node capacity

Answer

The nodes have insufficient CPU

Answer

The nodes have insufficient memory

Question 7

You need to debug a pod that is crashing immediately upon start. You cannot exec into the container because it exits before you can run commands. Which approach should you use to inspect the container's file system?

Accepted Answer

kubectl debug -it pod-name --image=busybox --target=container-name. The 'kubectl debug' command with an ephemeral container allows you to attach a debug container to a running pod, even if the original container is not running. You can share the process namespace or mount volumes to inspect files. Option A is not possible if the container crashes. Option C shows configuration, not runtime state. Option D is for logs, not filesystem.

Answer

kubectl exec -it pod-name -- /bin/sh

Answer

kubectl logs pod-name --previous

Answer

kubectl describe pod pod-name

Question 8

You need to view the logs of the previous (terminated) instance of a container in a pod. Which command should you use?

Accepted Answer

kubectl logs pod-name -p. The '--previous' flag is used to retrieve logs from the previous instance of a container that has been terminated or restarted. This is useful for debugging crash loops.

Answer

kubectl describe pod pod-name | grep -A 10 'Last State'

Answer

kubectl logs pod-name --tail=100

Answer

kubectl logs pod-name -f

Question 9

A pod has a readiness probe configured with httpGet on port 8080. The probe is failing, but the pod is running. What is the immediate effect on the pod?

Accepted Answer

The pod will be removed from the Service's endpoints and will stop receiving traffic. A failing readiness probe causes the pod to be removed from the Service's endpoints, so it will not receive traffic. The pod continues running and can be restarted by a liveness probe if configured, but readiness only affects traffic routing.

Answer

The pod will be restarted

Answer

The pod will be evicted from the node

Answer

The pod will be deleted

Question 10

You are asked to ensure that a pod with a slow-starting container (requires 60 seconds to initialize) is not prematurely restarted by the liveness probe. The liveness probe should start only after the container is fully initialized. Which probe type should you add to the pod spec?

Accepted Answer

startupProbe. A startupProbe is specifically designed for slow-starting containers. It runs at pod startup and only after it succeeds does the liveness probe begin. This prevents the liveness probe from restarting the container during its 60-second initialization period, as the startupProbe will keep failing until the container is fully ready.

Answer

readinessProbe

Answer

livenessProbe with initialDelaySeconds=60

Answer

lifecycle preStop hook

Question 11

You need to get a list of all events in the cluster sorted by timestamp. Which command should you use?

Accepted Answer

kubectl get events --sort-by=.metadata.creationTimestamp. The 'kubectl get events --sort-by=.metadata.creationTimestamp' command retrieves all events sorted by creation timestamp. Option A is the correct syntax.

Answer

kubectl top events

Answer

kubectl describe events

Answer

kubectl logs --events

Question 12

You want to see the IP address and the node on which each pod in the 'default' namespace is running. Which command provides this information?

Accepted Answer

kubectl get pods -o wide. Option B is correct because `kubectl get pods -o wide` outputs additional columns including the pod's IP address and the node it is scheduled on, which directly answers the question. The `-o wide` flag extends the default output format to show these fields without requiring a full resource description or YAML output.

Answer

kubectl describe pods

Answer

kubectl get pods --show-labels

Answer

kubectl get pods -o yaml

Question 13

Which TWO statements are true about readiness probes? (Select two.)

Accepted Answer

Readiness probes can be configured as httpGet, exec, tcpSocket, or gRPC. Readiness probes determine if a container is ready to serve traffic. If failing, the pod is removed from Service endpoints. They are independent of liveness probes.

Answer

Readiness probes are only executed when the pod is first started

Answer

A failing readiness probe causes the pod to be restarted

Answer

Readiness probes are defined in the pod spec under 'startupProbe'

Question 14

Which THREE of the following are valid ways to debug a pod that is not responding? (Select three.)

Accepted Answer

Run 'kubectl debug -it pod-name --image=busybox --target=container-name' to start an ephemeral debug container. Multiple methods exist: exec for interactive shell, logs for output, debug for ephemeral containers. Option B is not a valid command; Option D is for configuration files, not runtime debugging.

Answer

Run 'kubectl attach pod-name' to attach to the container's main process

Answer

Run 'kubectl get pod pod-name -o yaml' to examine the pod's current YAML definition

Question 15

Which TWO actions can you perform using 'kubectl describe'? (Select two.)

Accepted Answer

View the conditions and status of a node. 'kubectl describe' provides detailed information about Kubernetes resources, including events and conditions. It can show the current state and recent events. It does not modify resources or show logs.

Answer

Execute a command inside a container

Answer

View the logs of a container

Answer

View the YAML manifest of a resource