CKAD Application Observability and Maintenance Practice Test 2 — 15 Questions

Question 1

A deployment 'web-app' is running with 3 replicas. Users report that the application is slow. The team suspects a memory leak. Which command provides the most immediate insight into the memory usage of the pods?

Accepted Answer

kubectl top pod. Option D is correct because `kubectl top pod` directly queries the metrics server to display real-time CPU and memory usage for each pod, providing the most immediate insight into whether a pod is consuming excessive memory due to a suspected leak. Unlike logs or events, it gives quantitative resource utilization data without requiring additional configuration or parsing.

Answer

kubectl describe deployment web-app

Answer

kubectl get events

Answer

kubectl logs <pod>

Question 2

A pod named 'db-backup' is in CrashLoopBackOff. The team needs to understand why it keeps crashing. Which approach should be taken first to diagnose the issue?

Accepted Answer

View the logs of the pod using kubectl logs. C is correct because `kubectl logs` directly shows the stdout/stderr output from the container's main process, which typically contains the error message or stack trace explaining why the application crashed. Since the pod is in CrashLoopBackOff, the container is repeatedly starting and failing, so viewing the logs from the last (or previous) attempt is the fastest way to identify the root cause, such as a missing configuration file, a failed dependency, or an unhandled exception.

Answer

Increase the restart policy to Always

Answer

Run kubectl describe pod

Answer

Check the pod's events with kubectl get events

Question 3

A cluster has a node that is NotReady. The kubelet on that node is not responding. Which command should be used to investigate the kubelet logs on the node?

Accepted Answer

journalctl -u kubelet. Option D is correct because `journalctl -u kubelet` directly queries the systemd journal for logs from the kubelet service on the node. Since the kubelet is not responding, you cannot use `kubectl` to access its logs remotely; you must SSH into the node and use `journalctl` (or `systemctl status kubelet`) to read the kubelet's logs locally.

Answer

kubectl logs --node=

Answer

kubectl describe node <node>

Answer

kubectl get events --field-selector involvedObject.kind=Node

Question 4

A DevOps engineer needs to set up resource monitoring for pods in a namespace. Which built-in Kubernetes resource provides CPU and memory metrics out-of-the-box?

Accepted Answer

Metrics Server. The Metrics Server is the built-in Kubernetes resource that collects resource metrics (CPU and memory) from the kubelet on each node via the Summary API and exposes them through the metrics.k8s.io API. It provides these metrics out-of-the-box without requiring any additional configuration or external storage, making it the standard solution for horizontal pod autoscaling and kubectl top commands.

Answer

Prometheus

Answer

CoreDNS

Answer

Kubernetes Dashboard

Question 5

A pod has been scheduled on a node but is stuck in 'ContainerCreating' state. The team suspects a missing storage class. Which command would best confirm this?

Accepted Answer

kubectl describe pod . Option D is correct because `kubectl describe pod ` provides detailed event logs and status conditions for the pod, including specific error messages like 'failed to provision volume with StorageClass' or 'storageclass.storage.k8s.io "" not found'. This directly confirms whether a missing storage class is the root cause of the 'ContainerCreating' state, as the pod's events will surface the exact provisioning failure.

Answer

kubectl describe node

Answer

kubectl get pvc

Answer

kubectl get storageclass

Question 6

A pod is running but the application inside is not serving traffic. The team runs 'kubectl exec -it <pod> -- curl localhost:8080' and gets 'Connection refused'. What is the most likely cause?

Accepted Answer

Application is not listening on port 8080. The 'Connection refused' error from curl indicates that the TCP connection to port 8080 was actively rejected by the kernel, meaning no process is listening on that port inside the container. This is most commonly caused by the application not starting, crashing before binding, or being configured to listen on a different port (e.g., 3000, 8443). The error is immediate and does not suggest a timeout or network-level block.

Answer

Container logs are full and writing to disk is slow

Answer

NetworkPolicy is blocking traffic

Answer

Liveness probe is failing and restarting the container

Question 7

A developer wants to view the resource usage of all containers in a specific pod. Which command should they use?

Accepted Answer

kubectl top pod --containers. Option D is correct because `kubectl top pod --containers` displays per-container CPU and memory metrics for a specific pod, which is exactly what the developer needs to view resource usage of all containers within that pod. The `--containers` flag is essential to break down the pod-level metrics into individual container-level metrics.

Answer

kubectl top pods --all-namespaces

Answer

kubectl top pods

Answer

kubectl top pod <pod>

Question 8

Which TWO of the following are valid ways to expose application metrics for scraping by Prometheus in a Kubernetes environment?

Accepted Answer

Add annotations 'prometheus.io/scrape: "true"' to the pod template. Option A is correct because Prometheus supports automatic service discovery in Kubernetes via pod annotations. Adding 'prometheus.io/scrape: "true"' to the pod template tells Prometheus to scrape metrics from that pod, provided Prometheus is configured to use the Kubernetes service discovery mechanism. This is a standard, widely adopted pattern for exposing application metrics.

Answer

Create an Ingress with the metrics path

Answer

Add annotations 'prometheus.io/scrape: "true"' to the Deployment

Answer

Store metrics in a ConfigMap and mount it to Prometheus

Question 9

Which THREE of the following are best practices for configuring readiness probes?

Accepted Answer

Set initialDelaySeconds to avoid startup race conditions. Option C is correct because setting `initialDelaySeconds` in a readiness probe prevents the probe from starting before the container's application has had time to initialize. Without this delay, the probe might fail immediately during startup, causing the container to be prematurely marked as not ready and removed from service, even though the application would have become ready given a few more seconds. This avoids race conditions between container startup and probe evaluation.

Answer

Use the same endpoint as the liveness probe

Answer

Configure the probe to restart the container if it fails

Question 10

Which THREE of the following are valid methods to view logs of a container that has already terminated?

Accepted Answer

kubectl logs --tail=50. Option B is correct because `kubectl logs --tail=50` retrieves the last 50 lines of logs from the specified pod's container. Even if the container has terminated, the logs are still available from the pod's log history, and `--tail` limits the output to the most recent entries, which is useful for debugging recent failures.

Answer

kubectl logs <pod> --all-containers

Answer

kubectl logs --all

Question 11

You are a platform engineer managing a production Kubernetes cluster. A team deploys a stateful application called 'inventory-service' with 3 replicas using a StatefulSet. Each pod writes logs to a persistent volume via a PersistentVolumeClaim. Recently, the team reports that the application becomes unresponsive after running for a few hours. You notice that the pods are still running (READY 1/1) but the application does not respond to HTTP requests. You exec into one pod and find that the disk is 100% full. The PVC is backed by a cloud disk (e.g., AWS EBS). You check the pod's resource limits and see that memory and CPU are not exhausted. The container logs are not rotated. Which course of action should you take to resolve the immediate issue and prevent recurrence?

Accepted Answer

Increase the size of the PVC to provide more disk space, and configure log rotation inside the container to limit log file size. Option A is correct because the immediate issue is a full disk caused by unrotated logs. Increasing the PVC size provides temporary relief, while configuring log rotation inside the container (e.g., using logrotate or the application's own rotation) prevents the disk from filling up again. This directly addresses the root cause without changing the application's logging behavior or introducing unnecessary sidecars.

Answer

Add a sidecar container that compresses and archives logs to a remote storage every hour

Answer

Change the application to log to stdout and configure Docker log rotation on the host

Answer

Configure a log rotation sidecar that writes logs to an emptyDir volume with size limit

Question 12

A Pod is stuck in CrashLoopBackOff. You run 'kubectl logs mypod' and get no output. What is the most likely cause?

Accepted Answer

The application crashes before writing any logs.. When a Pod is in CrashLoopBackOff and `kubectl logs mypod` returns no output, the most likely cause is that the application crashes before it can write any logs to stdout/stderr. The container starts, runs briefly, and exits before the logging framework initializes, so no log data is captured by the container runtime.

Answer

The Pod is not ready yet.

Answer

The liveness probe is failing.

Answer

The container never started due to a missing image.

Question 13

You need to view metrics from a Pod running a web server. Which approach follows Kubernetes best practices?

Accepted Answer

Configure a Prometheus server to scrape the Pod's /metrics endpoint.. Option A is correct because Prometheus is the de facto standard for monitoring in Kubernetes, and scraping a Pod's /metrics endpoint is the recommended approach for collecting application-level metrics. This follows the Kubernetes best practice of exposing metrics via an HTTP endpoint that a monitoring system can scrape, rather than relying on ephemeral commands or resource-level metrics.

Answer

Use kubectl top pod to view CPU and memory metrics.

Answer

Exec into the container and run curl to check health.

Answer

Create a ServiceMonitor resource to expose metrics.

Question 14

A Pod is running but not responding to requests. The liveness probe is a TCP check on port 8080. What is the most likely issue?

Accepted Answer

The application is listening on port 8080 but not processing requests correctly.. A is correct because a TCP liveness probe only checks if the port is open and accepting connections, not whether the application is actually processing requests. If the application is listening on port 8080 but is stuck or not handling HTTP traffic correctly, the TCP probe will still succeed, and Kubernetes will not restart the container. This is a common scenario where the application is 'alive' at the socket level but not 'healthy' at the application layer.

Answer

The container is being throttled due to CPU limits.

Answer

The probe's initial delay is too short.

Answer

The liveness probe is misconfigured and should be an HTTP GET.

Question 15

You need to debug a Pod that is in CrashLoopBackOff. Which command should you run first?

Accepted Answer

kubectl logs . When a Pod is in CrashLoopBackOff, the immediate priority is to see why the container is failing. `kubectl logs ` retrieves the container's stdout/stderr output, which typically contains the error message (e.g., missing config, runtime exception, or startup failure). This is the fastest way to get the root cause without modifying the Pod state.

Answer

kubectl get events --sort-by=.lastTimestamp

Answer

kubectl exec -it <pod-name> -- sh

Answer

kubectl describe pod <pod-name>