CKAD Application Observability and Maintenance — 50 Questions

Question 1

A pod named 'web-app' is experiencing high CPU usage. You want to investigate which process inside the container is consuming the most CPU. Which command should you run?

Accepted Answer

kubectl exec web-app -- top. `kubectl exec web-app -- top` runs the `top` command inside the container of the pod 'web-app', which displays real-time process-level CPU usage. This allows you to identify the specific process consuming the most CPU, directly addressing the question's requirement to investigate inside the container.

Answer

kubectl logs -f web-app

Answer

kubectl describe node

Answer

kubectl top pod web-app

Question 2

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?

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 3

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

An application pod is logging sensitive data (e.g., passwords) to stdout. The security team requires that these logs be redacted before they are stored. Which approach should you recommend?

Accepted Answer

Modify the application code to stop logging sensitive data before redeploying.. The most reliable way to ensure sensitive data is never stored is to prevent it from being logged in the first place. Option D directly achieves the security requirement without introducing complex infrastructure or relying on a sidecar that cannot intercept stdout logs as described. The sidecar pattern is indeed useful for log processing, but it requires the main container to write logs to a file that is shared via a volume; it cannot read the stdout of another container. Node-level filtering (C) may introduce latency or leave brief on-disk exposure.

Answer

Set the log level to ERROR only to reduce verbosity and avoid logging sensitive data.

Answer

Add a sidecar container that reads the application's log file, redacts sensitive data, and writes to stdout.

Answer

Configure a LogCollector DaemonSet to filter logs at the node level.

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

You want to collect logs from a pod that has multiple containers. Which TWO approaches allow you to view logs from a specific container?

Accepted Answer

kubectl logs pod-name -c container-name. To view logs from a specific container in a multi-container pod, use `kubectl logs` with the container name. Option A uses the shorthand `-c` flag, and Option B uses the long form `--container`; both are equivalent and valid. Option D is a duplicate of Option B, so it is not a distinct approach. Option C (`--all-containers`) streams logs from all containers, not a specific one. Option E (no flags) returns logs from all containers by default, which is not what the question asks.

Answer

kubectl logs pod-name --all-containers

Answer

kubectl logs pod-name --container container-name

Answer

kubectl logs pod-name

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

Question 16

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

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 18

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

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

Option C is correct because a ServiceMonitor is a custom resource defined by the Prometheus Operator. It allows declarative configuration of which Services (or pods) to scrape, including the metrics path and interval. The ServiceMonitor is created in the same namespace as the target service, and Prometheus discovers it via label selectors. This is the recommended approach when using the Prometheus Operator.

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 20

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

Accepted Answer

Set initialDelaySeconds to avoid startup race conditions. 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