CKAD Application Observability and Maintenance Practice Test 5 — 15 Questions

Question 1

You have a Deployment running a web server that takes 30 seconds to initialize. You want to ensure that the load balancer does not send traffic to the pod until it is ready. Which probe should you configure?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Readiness probe. A Readiness probe is the correct choice because it determines whether a Pod is ready to serve traffic. In this scenario, the web server takes 30 seconds to initialize, so a Readiness probe (e.g., an HTTP GET on the application's health endpoint) will prevent the Service (and thus the load balancer) from sending requests until the probe succeeds, ensuring zero traffic is routed to an uninitialized Pod.

Answer

Resource limit

Answer

Startup probe

Answer

Liveness probe

Question 2

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 3

You have a Deployment that must run a legacy application that takes up to 5 minutes to start. You need to ensure the liveness probe does not kill the container prematurely. Which probe configuration should you use?

Accepted Answer

Configure a startup probe with a high failureThreshold and appropriate initialDelaySeconds. A startup probe is specifically designed for slow-starting containers. It runs before the liveness probe and allows the container extra time to initialize without being killed. By setting a high failureThreshold (e.g., 30) and an appropriate initialDelaySeconds, the probe can wait up to 5 minutes for the application to start, after which the liveness probe takes over.

Answer

Use a HTTP GET liveness probe with path /healthz and port 8080

Answer

Set livenessProbe.initialDelaySeconds to 300

Answer

Set livenessProbe.periodSeconds to a high value, like 300

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

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

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 8

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

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

Accepted Answer

kubectl logs -f pod-name. `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 15

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