CKAD Application Observability and Maintenance Practice Test 10 — 15 Questions

Question 1

A developer needs to view the logs of a pod named 'web-app-84b7f6f5b6-abcde' that crashed and has been restarted. Which kubectl command should they use to see the logs from the previous (crashed) instance?

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

Accepted Answer

kubectl logs --previous web-app-84b7f6f5b6-abcde. The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has been restarted. This is essential for debugging a crashed pod, as the current container's logs only reflect the new instance after the restart.

Answer

kubectl logs web-app-84b7f6f5b6-abcde

Answer

kubectl logs --all-containers web-app-84b7f6f5b6-abcde

Answer

kubectl logs -f web-app-84b7f6f5b6-abcde

Question 2

You need to check the resource usage of nodes and pods in your cluster. Which TWO commands should you use? (Choose two)

Accepted Answer

kubectl top nodes. A is correct because `kubectl top nodes` retrieves real-time CPU and memory usage metrics for all nodes in the cluster, sourced from the metrics server (which collects resource usage from kubelets via the Summary API). This command is the standard way to check node-level resource consumption in Kubernetes.

Answer

kubectl logs

Answer

kubectl cluster-info

Answer

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

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 5

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 6

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 7

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 8

You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?

Accepted Answer

The memory limit is set too low; the container is being OOMKilled during traffic spikes.. The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.

Answer

The liveness probe is misconfigured and should use a TCP check instead.

Answer

The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.

Answer

The CPU limit is too low, causing the container to be throttled and timeout.

Question 9

Match each Kubernetes object field to its description.

Accepted Answer

livenessProbe: Indicates if the container is running. If fails, kubelet kills the container and restarts it.. Correct matches: livenessProbe checks container health, readinessProbe checks service readiness, startupProbe checks application startup, and imagePullPolicy controls image pulling. Common confusions involve swapping definitions with restartPolicy.

Answer

imagePullPolicy: Defines the policy for restarting the container after exit.

Answer

restartPolicy: Defines when to pull the container image.

Question 10

Match each Kubernetes resource to its API group.

Accepted Answer

Pod: v1. Kubernetes resources belong to specific API groups. Pods, Services, ConfigMaps, and PersistentVolumeClaims are in the core group (v1), while Deployments are in apps/v1, and Ingresses are in networking.k8s.io/v1.

Answer

Service: apps/v1

Answer

ConfigMap: networking.k8s.io/v1

Answer

PersistentVolumeClaim: apps/v1

Question 11

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The OOMKilled status indicates the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand, not a configuration error. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Question 12

You have a Deployment running a web server that takes 30 seconds to initialize. You want to ensure that the load balancer does not send traffic to the pod until it is ready. Which probe should you configure?

Accepted Answer

Readiness probe. A Readiness probe is the correct choice because it determines whether a Pod is ready to serve traffic. In this scenario, the web server takes 30 seconds to initialize, so a Readiness probe (e.g., an HTTP GET on the application's health endpoint) will prevent the Service (and thus the load balancer) from sending requests until the probe succeeds, ensuring zero traffic is routed to an uninitialized Pod.

Answer

Resource limit

Answer

Startup probe

Answer

Liveness probe

Question 13

You have a Deployment that must run a legacy application that takes up to 5 minutes to start. You need to ensure the liveness probe does not kill the container prematurely. Which probe configuration should you use?

Accepted Answer

Configure a startup probe with a high failureThreshold and appropriate initialDelaySeconds. A startup probe is specifically designed for slow-starting containers. It runs before the liveness probe and allows the container extra time to initialize without being killed. By setting a high failureThreshold (e.g., 30) and an appropriate initialDelaySeconds, the probe can wait up to 5 minutes for the application to start, after which the liveness probe takes over.

Answer

Use a HTTP GET liveness probe with path /healthz and port 8080

Answer

Set livenessProbe.initialDelaySeconds to 300

Answer

Set livenessProbe.periodSeconds to a high value, like 300

Question 14

You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?

Accepted Answer

kubectl debug -it --image=busybox --target=. `kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original container.

Answer

kubectl attach <pod>

Answer

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

Answer

kubectl run debug --image=busybox -it --restart=Never

Question 15

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly resolving the OOM condition.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads