CKAD Application Observability and Maintenance Practice Test 4 — 15 Questions

Question 1

A pod named 'app' is stuck in 'Pending' state. You run 'kubectl describe pod app' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

Accepted Answer

The pod's CPU request is higher than the available CPU on any node. The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the pod's CPU resource request exceeds the allocatable CPU capacity on every node in the cluster. Kubernetes schedules pods based on resource requests, not limits, so if the sum of CPU requests across all pods on a node would exceed the node's capacity, the pod remains Pending. This is the most likely cause because the error message directly points to insufficient CPU resources.

Answer

The container image is not found

Answer

The pod is in CrashLoopBackOff

Answer

The pod has been evicted due to memory pressure

Question 2

You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?

Accepted Answer

kubectl debug -it --image=busybox --target=. Option D is correct because `kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original container.

Answer

kubectl attach <pod>

Answer

kubectl exec -it <pod> -- /bin/sh

Answer

kubectl run debug --image=busybox -it --restart=Never

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

You want to see a list of all events in the 'default' namespace, sorted by timestamp. Which command should you use?

Accepted Answer

kubectl get events. Option C is correct because `kubectl get events` retrieves all events in the current namespace (default) and, by default, sorts them by the `lastTimestamp` field in ascending order, which is the timestamp of the event. This command directly answers the requirement to list events sorted by timestamp without additional flags.

Answer

kubectl describe events

Answer

kubectl get pods

Answer

kubectl logs --all-containers

Question 5

You have a pod with two containers: 'web' and 'sidecar'. You want to view the logs of only the 'sidecar' container. Which command should you use?

Accepted Answer

kubectl logs pod-name -c sidecar. Option A is correct because `kubectl logs pod-name -c sidecar` explicitly specifies the container name within the pod using the `-c` flag, allowing you to view logs from only the 'sidecar' container. In Kubernetes, when a pod contains multiple containers, you must specify the container name to isolate logs from a particular container.

Answer

kubectl attach pod-name -c sidecar

Answer

kubectl logs pod-name

Answer

kubectl logs pod-name --container sidecar

Question 6

You need to run a command inside a running pod's container. The container has a shell available. Which command allows you to execute 'ls -la /data' inside the container?

Accepted Answer

kubectl exec pod-name -- ls -la /data. The `kubectl exec` command is designed to execute arbitrary commands inside a running container. The `--` separator tells kubectl that everything after it is the command to run inside the container, not a kubectl flag. Option C correctly uses `kubectl exec pod-name -- ls -la /data` to run `ls -la /data` inside the specified pod's primary container.

Answer

kubectl exec pod-name

Answer

kubectl run pod-name -- ls -la /data

Answer

kubectl attach pod-name -c container-name

Question 7

You have a Deployment that uses an httpGet liveness probe on port 8080 with path /healthz. The probe fails after the container starts, but you can successfully curl http://localhost:8080/healthz from within the container. What is the most likely cause?

Accepted Answer

The container is listening on localhost (127.0.0.1) instead of 0.0.0.0. The liveness probe is executed by the kubelet from the node's network namespace, not from within the container. If the application binds only to 127.0.0.1 (localhost), it will only accept connections from within the container itself. The kubelet's HTTP GET request to the pod's IP on port 8080 will be refused because the socket is not listening on 0.0.0.0, causing the probe to fail even though a local curl succeeds.

Answer

The liveness probe port is incorrect

Answer

The container is not running

Answer

The liveness probe path is incorrect

Question 8

Which TWO statements about readiness probes are correct? (Choose two.)

Accepted Answer

Readiness probes run continuously after the container starts. Option B is correct because readiness probes are designed to run continuously throughout the lifecycle of a container, not just during startup. They are periodically executed by the kubelet to determine whether the container is ready to accept traffic, and their success or failure directly controls the pod's inclusion in Service endpoints.

Answer

Readiness probes are only used during initial startup

Answer

Readiness probes can only be of type httpGet

Answer

Readiness probes restart the container if they fail

Question 9

Which TWO parameters can be configured for a probe to control its behavior? (Choose two.)

Accepted Answer

timeoutSeconds. Option D is correct because `timeoutSeconds` defines the maximum time a probe waits for a response before considering the probe failed. Option E is correct because `initialDelaySeconds` configures the delay before the probe starts after the container starts, allowing the application to initialize. Both are standard fields in the Kubernetes probe specification (liveness, readiness, startup).

Answer

maxRetries

Answer

backoffSeconds

Answer

retryIntervalSeconds

Question 10

Which THREE commands can be used to get detailed information about a pod named 'my-pod'? (Choose three.)

Accepted Answer

kubectl get pod my-pod -o json. Option B is correct because `kubectl get pod my-pod -o json` retrieves the full object representation of the pod in JSON format, which includes all fields such as metadata, spec, status, and annotations. This provides detailed, machine-readable information about the pod's current state and configuration.

Answer

kubectl logs my-pod

Answer

kubectl exec my-pod -- env

Question 11

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 12

Which command streams logs from a pod in real-time?

Accepted Answer

kubectl logs -f pod-name. Option B is correct because `kubectl logs -f` (the `-f` flag stands for 'follow') streams log output from a pod in real-time, similar to `tail -f` on a file. This is the standard Kubernetes command for continuous log monitoring, allowing you to see new log lines as they are written by the container.

Answer

kubectl logs --stream pod-name

Answer

kubectl logs --previous pod-name

Answer

kubectl logs pod-name

Question 13

You have a Deployment named 'api' with 3 replicas. You need to ensure that new pods are not added to the Service's endpoints until the application is ready to serve traffic. Which probe configuration should you add to the pod spec?

Accepted Answer

Readiness probe. A Readiness probe is the correct choice because it controls whether a pod is added to a Service's endpoints. Kubernetes will only mark a pod as Ready when the probe succeeds, and only Ready pods receive traffic from the Service. This ensures new pods are not added until the application is ready to serve traffic.

Answer

No probe is needed; pods are automatically added when running

Answer

Startup probe

Answer

Liveness probe

Question 14

You run 'kubectl get pods -o wide' and see that a pod's NODE column shows 'node-1'. You want to see more details about that node's resource usage. Which command should you use?

Accepted Answer

kubectl top node node-1. Option D is correct because `kubectl top node node-1` directly displays real-time resource usage (CPU and memory) for the specified node, which is exactly what you need when you want to see more details about a node's resource consumption after identifying the node from `kubectl get pods -o wide`.

Answer

kubectl top pods --all-namespaces

Answer

kubectl describe node node-1

Answer

kubectl top pod node-1

Question 15

A container in your pod takes a long time to start (up to 5 minutes). You want to avoid the container being restarted by the liveness probe during this period. What should you configure?

Accepted Answer

Add a startup probe with a longer failure threshold. A startup probe is designed specifically for slow-starting containers. It runs at initialization and defers the liveness and readiness probes until it succeeds. By setting a high `failureThreshold` (e.g., 30) with a short `periodSeconds` (e.g., 10s), you allow up to 5 minutes for the container to start without the liveness probe killing it.

Answer

Set a long 'initialDelaySeconds' on the liveness probe

Answer

Add a readiness probe

Answer

Increase the failureThreshold on the liveness probe