CKAD Application Observability and Maintenance Practice Test 3 — 15 Questions

Question 1

Sequence the steps to troubleshoot a Pod stuck in CrashLoopBackOff state.

Accepted Answer

Check Pod status, then inspect logs and events, then fix the issue, then restart the Pod.. Start by checking status, then inspect logs and events to diagnose. Fix the issue, then restart the Pod.

Answer

Restart the Pod, then check Pod status, then inspect logs and events, then fix the issue.

Answer

Inspect logs and events, then fix the issue, then restart the Pod, then check Pod status.

Answer

Fix the issue, then check Pod status, then inspect logs and events, then restart the Pod.

Question 2

Order the steps to update a Kubernetes Secret and ensure a Pod uses the new secret.

Accepted Answer

Step 1: Update the Secret. Step 2: Determine if the Secret is mounted as a volume or set as an environment variable. Step 3a: If volume mount, no further action needed (Pod picks up changes automatically). Step 3b: If environment variable, restart the Pod (e.g., delete and recreate or rollout restart).. Update secret, then if mounted as volume, Pod picks it up automatically; if env, need restart.

Answer

Step 1: Restart the Pod. Step 2: Update the Secret.

Answer

Step 1: Update the Secret. Step 2: Restart the Pod in all cases.

Answer

Step 1: Update the Secret. Step 2: Update the Pod's environment variable definition to reference the new Secret version.

Question 3

A pod named 'db-pod' is running but not responding as expected. You want to check its logs from the previous instantiation (after a crash). Which command should you use?

Accepted Answer

kubectl logs db-pod --previous. The `--previous` flag in `kubectl logs` retrieves logs from the previous instantiation of a container in a pod that has crashed or restarted. This allows you to inspect the logs from the terminated container before the current running instance, which is essential for debugging why the pod is not responding as expected after a crash.

Answer

kubectl exec db-pod -- cat /var/log/app.log

Answer

kubectl logs -f db-pod

Answer

kubectl describe pod db-pod

Question 4

You need to view resource usage (CPU and memory) for all pods in the 'default' namespace. Which command should you use?

Accepted Answer

kubectl top pods. `kubectl top pods` is the command specifically designed to display real-time CPU and memory usage metrics for pods in a Kubernetes cluster. It relies on the metrics server to collect resource usage data and presents it in a concise table format, making it the appropriate tool for viewing resource consumption in the 'default' namespace.

Answer

kubectl logs pods

Answer

kubectl describe pods

Answer

kubectl top nodes

Question 5

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 6

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 beyond the expected 30-second shutdown time. Option B is correct because 35 seconds provides sufficient time without being excessive. Option A uses an invalid field name (terminationGracePeriod instead of terminationGracePeriodSeconds). Option C sets the grace period to 300 seconds, which is excessively long and could delay pod termination. Option D sets the grace period to 20 seconds, which is too short and may not allow the container to shut down gracefully within the expected 30 seconds.

Answer

Set spec.terminationGracePeriod: 35

Answer

Set spec.terminationGracePeriodSeconds: 300

Answer

Set spec.terminationGracePeriodSeconds: 20

Question 7

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. `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 8

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. `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 9

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 10

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 11

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

Accepted Answer

Readiness probes run continuously after the container starts. 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 12

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

Accepted Answer

timeoutSeconds. `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 13

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