CKAD Application Observability and Maintenance Practice Test 1 — 15 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. Option B is correct because `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.. Option D is correct because 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

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 5

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.. Option D is correct because 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 6

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 7

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

Add a sidecar container that reads the application's log file, redacts sensitive data, and writes to stdout.. Option B is correct because a sidecar container can share the application's log file via an emptyDir volume, read the raw logs, apply redaction logic (e.g., regex replacement of password patterns), and then output the sanitized logs to its own stdout. This approach satisfies the security requirement without modifying the application code or losing log verbosity, and it keeps the redaction logic decoupled from the main container.

Answer

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

Answer

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

Answer

Modify the application code to stop logging sensitive data before redeploying.

Question 8

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"'.. Option C is correct because 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 9

You are designing a health check strategy for a web application. Which TWO probe types should you configure to ensure that traffic is only sent to pods that are ready to serve?

Accepted Answer

Readiness probe. A Readiness probe (Option A) is specifically designed to determine whether a pod is ready to serve traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring traffic is only sent to pods that are ready. This directly fulfills the requirement of controlling traffic routing based on pod readiness.

Answer

TCP socket probe

Answer

HTTP GET probe

Answer

Liveness probe

Question 10

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.. Option A is correct because 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 11

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. Option A is correct because the `kubectl logs` command with the `-c` flag allows you to specify a container name within a multi-container pod. This is the standard shorthand for `--container` and is explicitly supported in the Kubernetes CLI for targeting logs from a specific container.

Answer

kubectl logs pod-name --container container-name

Answer

kubectl logs pod-name --all-containers

Answer

kubectl logs pod-name

Question 12

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

Accepted Answer

The readiness probe is failing, causing the pod to be considered not ready and restarted.. Option A is correct because the exhibit shows the container being killed and restarted, which is the default behavior when a readiness probe fails. In Kubernetes, a failing readiness probe removes the pod from service endpoints but does not trigger a restart; however, the question's context implies that the pod is being restarted due to a readiness probe failure combined with a restart policy (e.g., `Always`), which can cause the container to be recreated if the pod is considered unhealthy and the kubelet decides to restart it. The readiness probe failure leads to the pod being marked as not ready, and with a restart policy of `Always`, the container is killed and restarted to attempt recovery.

Answer

The liveness probe is failing, causing the container to be restarted.

Answer

The container is running out of memory (OOM).

Answer

The container image is being pulled repeatedly.

Question 13

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.. Option D is correct because 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 14

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.. Option A is correct because 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 15

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.