CKAD Application Observability and Maintenance Practice Test 7 — 15 Questions

Question 1

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. `kubectl get events --sort-by=.metadata.creationTimestamp` retrieves all cluster events and sorts them by the creation timestamp field in the event object's metadata. This is the standard Kubernetes approach for ordering events chronologically, as events are stored in etcd and can be sorted client-side using JSONPath expressions against the resource's metadata.

Answer

kubectl top events

Answer

kubectl describe events

Answer

kubectl logs --events

Question 2

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

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 support four handler types: httpGet, exec, tcpSocket, and gRPC (since Kubernetes 1.24). These are defined in the container spec under the `readinessProbe` field, allowing the kubelet to check container readiness using HTTP status codes, command exit codes, TCP port connectivity, or gRPC health checks.

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 4

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. `kubectl debug` with `--target=container-name` creates an ephemeral container in the same pod, sharing the network and process namespace (if supported) with the target container. This allows you to run debugging tools (e.g., `busybox`) without modifying the original container image, which is essential when the container lacks a shell or necessary utilities.

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 5

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

Accepted Answer

View the conditions and status of a node. `kubectl describe node <node-name>` displays detailed information about a node, including its conditions (e.g., Ready, DiskPressure, MemoryPressure) and status (e.g., capacity, allocatable resources). This command is essential for debugging node-level issues.

Answer

Execute a command inside a container

Answer

View the logs of a container

Answer

View the YAML manifest of a resource

Question 6

Which kubectl command streams logs from a pod named 'web-pod' in real-time?

Accepted Answer

kubectl logs -f web-pod. `kubectl logs -f web-pod` uses the `-f` (follow) flag to stream logs from the pod in real-time, similar to `tail -f` in Linux. This flag keeps the connection open and continuously outputs new log lines as they are written by the container.

Answer

kubectl logs --previous web-pod

Answer

kubectl logs --tail web-pod

Answer

kubectl logs web-pod --all-containers

Question 7

A pod with a liveness probe using 'httpGet' is restarting repeatedly. The probe checks '/healthz' on port 8080. The application is healthy and responds with HTTP 200. What is the most likely cause?

Accepted Answer

The timeoutSeconds value is too low. The liveness probe is restarting the pod despite the application returning HTTP 200 on /healthz. A timeoutSeconds value that is too low can cause the probe to fail if the application takes longer than the timeout to respond, even though it is healthy. Kubernetes will restart the container when the probe fails, leading to repeated restarts.

Answer

The initialDelaySeconds is too high

Answer

The liveness probe is checking the wrong port

Answer

The readiness probe is misconfigured

Question 8

A developer wants to debug a container that has crashed and is no longer running. Which command allows them to start an ephemeral container in the same pod for debugging?

Accepted Answer

kubectl debug -it --image=busybox --target=. To debug a container that is no longer running, the recommended approach is to create a copy of the pod with a different command via `kubectl debug -it --copy-to= --container= --image=busybox -- sh`, or add an ephemeral container without `--target` (e.g., `kubectl debug -it --image=busybox`). Option B with `--target` will not work because the target container is not running.

Answer

kubectl attach <pod>

Answer

kubectl run debug --image=busybox -it --rm

Answer

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

Question 9

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

Accepted Answer

kubectl top pod. `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 10

You run 'kubectl get events' and see an event 'FailedScheduling' for a pod. What is the most common cause?

Accepted Answer

Insufficient node resources to meet the pod's requests. The 'FailedScheduling' event indicates that the Kubernetes scheduler could not find a suitable node to place the pod. The most common cause is insufficient node resources (CPU, memory, or ephemeral storage) to meet the pod's resource requests defined in the pod spec. The scheduler uses the `kube-scheduler` component to evaluate node fit based on predicates like `PodFitsResources`, and if no node satisfies the requested resources, the pod remains in a Pending state with this event.

Answer

The pod's container image pull failed

Answer

The liveness probe failed

Answer

The pod was deleted by a Deployment update

Question 11

A pod spec has terminationGracePeriodSeconds: 30. The main process ignores SIGTERM. After 30 seconds, what happens?

Accepted Answer

SIGKILL is sent to forcefully terminate the container. When the main process in a container ignores SIGTERM, Kubernetes waits for the duration specified in `terminationGracePeriodSeconds` (30 seconds) and then sends SIGKILL to forcefully terminate the container. This ensures that pods do not hang indefinitely during shutdown, as SIGKILL cannot be ignored by any process.

Answer

The pod remains running indefinitely

Answer

The pod enters a CrashLoopBackOff state

Answer

The pod is rescheduled to another node

Question 12

Which probe type is used to indicate that a container is ready to serve traffic and should be added to Service endpoints?

Accepted Answer

Readiness probe. A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, the container is removed from all Service endpoints, ensuring only healthy pods receive requests. This is the correct probe for indicating readiness to serve traffic.

Answer

Liveness probe

Answer

Startup probe

Answer

Both liveness and readiness probes

Question 13

A pod uses a liveness probe with exec command 'cat /tmp/healthy'. The file /tmp/healthy exists initially but is deleted by the application after 60 seconds. Which behavior will occur?

Accepted Answer

The liveness probe will fail and the container will be restarted. The liveness probe in Kubernetes periodically checks the health of a container by executing the specified command. When the file /tmp/healthy is deleted, the 'cat /tmp/healthy' command fails (returns non-zero exit code), causing the liveness probe to fail. After consecutive failures (default threshold is 3), kubelet restarts the container to attempt recovery, which is the expected behavior for a failing liveness probe.

Answer

The pod will continue running because the liveness probe only checks at startup

Answer

The pod will be deleted and recreated by the Deployment

Answer

The pod will be marked as NotReady and removed from the Service

Question 14

You need to view the logs of a container that previously crashed and has been restarted. Which flag do you use with 'kubectl logs'?

Accepted Answer

--previous. The `--previous` flag is used with `kubectl logs` to view logs from the previous instance of a container that has crashed and been restarted. This allows you to inspect the logs of the terminated container before the restart, which is essential for debugging crash loops.

Answer

--all-containers

Answer

--tail

Answer

-f

Question 15

A pod has a readiness probe using tcpSocket on port 3306. The application listens on port 3306 but returns errors on database queries. What is the effect of the readiness probe?

Accepted Answer

The pod will be considered ready as long as the TCP port is open, even if the application is not fully functional. A readiness probe with tcpSocket only checks whether the TCP port is open and accepting connections. It does not verify application-level health, such as whether the application can process queries or return valid responses. Since port 3306 is open, the probe succeeds, and the pod is considered ready, even though the application returns errors on database queries.

Answer

The pod will be evicted from the node

Answer

The pod will be marked not ready because the application returns errors

Answer

The container will be restarted due to readiness probe failure