CKAD Application Observability and Maintenance Practice Test 3 — 15 Questions

Question 1

A deployment 'api-deploy' has resource limits set but is frequently being OOMKilled. The team suspects the memory limit is too low. Which approach should be taken to confirm this without causing downtime?

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

Accepted Answer

Increase the memory limit in the deployment spec and apply the change; the rollout will automatically restart pods.. Updating the deployment spec triggers a rolling update, which replaces pods with new ones having the increased memory limit without downtime. This approach leverages Kubernetes' deployment controller to manage the rollout automatically, ensuring service continuity while adjusting resource limits.

Answer

Create a new pod with a higher memory limit and delete the old pods manually.

Answer

Set the memory limit to unlimited by removing the limit section and restart the pod.

Answer

Use 'kubectl set resources' to increase the limit on the running pod dynamically.

Question 2

A pod is in CrashLoopBackOff state. You need to view the last few lines of its logs to understand why it is crashing. Which command is most appropriate?

Accepted Answer

kubectl logs my-pod --tail=20. The `--tail=20` flag limits the output to the last 20 lines of the pod's logs, which is the most efficient way to see the recent crash-related errors without scrolling through the entire log history. In a CrashLoopBackOff state, the pod is repeatedly restarting, so viewing the tail of the logs directly shows the most recent failure messages, which is the standard diagnostic approach.

Answer

kubectl logs -f my-pod

Answer

kubectl logs my-pod

Answer

kubectl get events --field-selector involvedObject.name=my-pod

Question 3

You are debugging a network issue: a pod 'frontend' cannot reach a service 'backend' in the same namespace. The service endpoints are empty. What is the most likely cause?

Accepted Answer

The service selector does not match the labels of any running pod.. B is correct because the most common reason for empty endpoints in a Kubernetes service is that the service's selector does not match the labels of any running pod. The service controller continuously monitors pods and updates the Endpoints object to include only those pods whose labels match the service's selector. If no pods match, the endpoints list remains empty, causing the frontend pod to fail to reach the backend service.

Answer

The pod 'frontend' is not in the same namespace as the service 'backend'.

Answer

The pod's container port is different from the service port.

Answer

The kube-proxy is misconfigured and not updating iptables rules.

Question 4

A deployment is configured with a liveness probe that checks an HTTP endpoint. The probe fails intermittently, causing pod restarts. What is the best first step to diagnose the issue?

Accepted Answer

Examine the container logs via 'kubectl logs' for error messages around the time of the failures.. Container logs provide the application's perspective on why the HTTP endpoint is failing intermittently. The liveness probe failure is a symptom; the root cause (e.g., a transient error, resource exhaustion, or a bug) is most directly visible in the application's own log output around the failure timestamps. This aligns with the CKAD domain of Application Observability and Maintenance, where logs are the primary diagnostic tool for application-level issues.

Answer

Check the liveness probe events via 'kubectl describe pod' to see the exact probe responses.

Answer

Run 'kubectl exec' to curl the endpoint from another pod to test network connectivity.

Answer

Review the liveness probe parameters in the deployment YAML and increase the failureThreshold.

Question 5

A pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' Which action should you take?

Accepted Answer

Reduce the CPU request of the pod and reapply the manifest.. The pod is stuck in 'Pending' because the scheduler cannot find a node with enough allocatable CPU to satisfy the pod's CPU request. Reducing the CPU request (the amount guaranteed to the container) makes the pod schedulable on existing nodes. Increasing limits would only worsen the problem, as limits are a cap on usage, not a scheduling constraint.

Answer

Increase the CPU limits on the pod to give it more resources.

Answer

Add another node to the cluster to increase overall CPU capacity.

Answer

Add a nodeSelector to the pod to target a specific node.

Question 6

You need to collect metrics from an application running in a pod. The application exposes metrics on port 8080 at /metrics in Prometheus format. Which resource should you configure to allow Prometheus to scrape these metrics?

Accepted Answer

Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.. Prometheus uses a pull-based model to scrape metrics from targets. By adding the `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` annotations to a Service that selects the pod, you enable Prometheus's built-in service discovery to automatically detect and scrape the `/metrics` endpoint on port 8080 without manual configuration.

Answer

Create an Ingress resource that exposes the /metrics endpoint externally.

Answer

Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.

Answer

Add a PrometheusRule resource that defines the scrape target.

Question 7

A pod is running but not serving traffic. You suspect the readiness probe is failing. Which THREE commands or actions would help you diagnose the readiness probe issue?

Accepted Answer

Examine the container logs for errors during readiness probe checks.. Container logs often contain detailed error messages from the readiness probe itself, such as HTTP 4xx/5xx responses or connection timeouts. By examining the logs, you can directly see why the probe is failing, e.g., the application's health endpoint returning a non-2xx status or the probe timing out.

Answer

Run 'kubectl top pod <pod-name>' to check CPU/memory usage.

Answer

Run 'kubectl get nodes' to see node conditions.

Question 8

Based on the exhibit, why is the container being killed and restarted?

Accepted Answer

The liveness probe is failing, causing the container to be restarted.. In Kubernetes, a failing liveness probe causes the kubelet to restart the container. The exhibit shows the container being killed and restarted, which is consistent with liveness probe failure. Option A is incorrect because a failing readiness probe does not restart the container; it only marks the pod as not ready and removes it from service endpoints. Option C is incorrect: OOM would result in a different error message (OOMKilled). Option D is incorrect: repeated image pulls would cause ImagePullBackOff, not a restart after running.

Answer

The readiness probe is failing, causing the pod to be considered not ready and restarted.

Answer

The container is running out of memory (OOM).

Answer

The container image is being pulled repeatedly.

Question 9

Based on the exhibit, what should you do to determine why the container is failing?

Accepted Answer

Run 'kubectl logs backend' to view the container's stdout/stderr.. The container is failing, and the most direct way to determine why is to inspect its stdout/stderr logs using 'kubectl logs backend'. This command retrieves the container's log output, which typically contains error messages, stack traces, or application-level failure reasons. In CKAD scenarios, when a pod is in CrashLoopBackOff or Error state, logs are the first diagnostic step to identify the root cause.

Answer

Run 'kubectl describe pod backend' to see the pod's status.

Answer

Run 'kubectl get events' with a different filter to capture more details.

Answer

Check if the image tag '1.0' exists in the registry.

Question 10

Your team manages a microservices application on a Kubernetes cluster. A critical service 'order-service' is deployed with 3 replicas. Lately, customers have reported occasional timeouts when placing orders. You suspect that the service is overloaded during peak hours. You have configured a HorizontalPodAutoscaler (HPA) based on CPU utilization, but the autoscaler does not appear to be scaling up quickly enough. Upon inspection, you notice that the HPA is configured with a target CPU utilization of 80%, and the current CPU usage of the pods is around 70%. However, the pods' memory usage is high and growing. The application is also logging slow database queries. Which action is most likely to improve the responsiveness of the service during peak load?

Accepted Answer

Modify the HPA to also scale based on memory utilization, setting a target average value for memory.. The HPA is configured only for CPU, but the symptom (high memory usage, slow DB queries) indicates memory pressure is the bottleneck. Adding a memory-based metric to the HPA allows it to scale when memory exceeds the target, addressing the root cause of overload during peak hours. The current CPU at 70% is below the 80% threshold, so the HPA won't trigger on CPU alone, but memory scaling can react to the actual resource constraint.

Answer

Reduce the number of replicas to 2 to force the HPA to react more aggressively.

Answer

Increase the CPU target utilization to 90% so the HPA triggers earlier.

Answer

Optimize the database queries to reduce response time.

Question 11

You are a platform engineer for a large e-commerce site. The application is deployed on a Kubernetes cluster with 10 worker nodes. Recently, a new deployment 'checkout' was rolled out, and soon after, the cluster experienced network latency and intermittent connectivity issues between services. The 'checkout' pods are configured with a liveness probe that makes an HTTP request to an internal health endpoint. Upon investigation, you find that the kubelet on several nodes is consuming high CPU, and the number of iptables rules has increased significantly. You suspect that the 'checkout' deployment's configuration is causing excessive churn in the network rules. Which aspect of the deployment configuration is most likely the root cause?

Accepted Answer

The liveness probe is configured with a very short periodSeconds (e.g., 1) and a low failureThreshold.. A liveness probe with a very short `periodSeconds` (e.g., 1) and a low `failureThreshold` causes the kubelet to send HTTP requests to the health endpoint at a high frequency. Each probe failure triggers a pod restart, which in turn causes the kubelet to update iptables rules (e.g., for kube-proxy and network policies) to reflect the new pod IP. This rapid churn of pod restarts leads to a significant increase in iptables rules and high CPU consumption on the kubelet, as it must repeatedly reconcile the network state.

Answer

The liveness probe uses a TCP socket check instead of an HTTP GET.

Answer

The deployment sets resource requests and limits that are too low, causing pod throttling.

Answer

The deployment uses a large number of environment variables, causing slow container startup.

Question 12

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

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 14

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

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