CKAD Application Observability and Maintenance — 20 Questions

Question 1

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 2

You are tasked with improving the observability of a microservices application running in Kubernetes. The application is deployed with multiple replicas and experiences occasional high latency. Which TWO actions should you take to gain better insight into the application's performance?

Accepted Answer

Enable Prometheus metrics endpoints on each pod and configure a Prometheus server to scrape them.. Prometheus is the standard open-source monitoring toolkit in Kubernetes. By exposing metrics endpoints and scraping them, you collect performance data like latency and error rates, directly aiding high-latency diagnosis. Option E is correct because distributed tracing with Jaeger traces requests across services, pinpointing latency sources in microservices. Options A, C, and D address scaling or health checks, not performance insight.

Answer

Increase the replica count for each deployment to reduce latency.

Answer

Configure readiness probes to ensure only healthy pods receive traffic.

Answer

Add liveness probes to all containers to detect when they are unresponsive.

Question 3

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 4

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 pod's container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, a gradual memory leak or increased workload likely caused the usage to spike past the configured limit. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory demand without being killed, resolving the CrashLoopBackOff.

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Question 5

You want to debug a pod that is not responding. You need to run an interactive shell inside a running container. Which command should you use?

Accepted Answer

kubectl exec -it -- /bin/bash. `kubectl exec -it -- /bin/bash` attaches an interactive terminal session to an already-running container within the specified pod. The `-it` flags combine `--stdin` (keep STDIN open) and `--tty` (allocate a pseudo-TTY), which are required for an interactive shell. This is the standard command for debugging a running pod without creating a new container.

Answer

kubectl run -it <pod> --image=busybox -- /bin/sh

Answer

kubectl exec -i <pod> -- /bin/bash

Answer

kubectl debug -it <pod> --image=busybox -- /bin/sh

Question 6

You are tasked with debugging a pod that is crashing so quickly that you cannot exec into it. Which approach should you use to gain access to the pod's filesystem?

Accepted Answer

kubectl debug -it --copy-to=-debug --image=busybox. Both options B and D are correct approaches to access the filesystem of a crashing pod. Option B uses `kubectl debug` with `--copy-to` to create a copy of the pod with a debugging container that shares the original pod's filesystem. Option D uses `kubectl debug` without `--copy-to` to add an ephemeral container to the existing pod, which also shares the pod's filesystem and allows shell access even if the original container is crashing. Option A is incorrect because it creates a new standalone pod without access to the target pod's filesystem. Option C is incorrect because `kubectl exec` requires the target container to be running, which it is not in a crashing state.

Answer

kubectl run debug --image=busybox -it --rm

Answer

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

Answer

kubectl debug -it <pod> --image=busybox

Question 7

You need to view the logs of a container named 'sidecar' in a pod called 'app-pod' running in namespace 'dev'. Which command should you use?

Accepted Answer

kubectl logs app-pod -c sidecar -n dev. The correct command is `kubectl logs app-pod -c sidecar -n dev`. This uses the shorthand flags `-c` for container and `-n` for namespace, which are the typical syntax required in the CKAD exam. Option C uses long flags (`--container=sidecar --namespace=dev`), which are also valid in Kubernetes, but the CKAD exam focuses on shorthand flags for brevity and speed; the long form is considered less efficient and is not the expected answer in this context. Options A and B are incorrect because they omit the container specification or misplace the pod name argument.

Answer

kubectl logs sidecar -p app-pod -n dev

Answer

kubectl logs app-pod -n dev

Answer

kubectl logs app-pod --container=sidecar --namespace=dev

Question 8

A pod has a startup probe with failureThreshold: 30 and periodSeconds: 10. The application takes up to 5 minutes to start. What should be changed to ensure the startup probe does not kill the container prematurely?

Accepted Answer

Increase failureThreshold to 40. Increasing failureThreshold to 40 (from 30) with periodSeconds: 10 gives a total timeout of 40 × 10 = 400 seconds (6 minutes 40 seconds), which exceeds the 5-minute startup time. Setting initialDelaySeconds (Option D) would also delay the first probe execution, but best practices recommend adjusting the probe's failure threshold and interval instead of using an initial delay for startup probes, as the purpose of a startup probe is to start probing immediately and replace the need for an initial delay.

Answer

Change periodSeconds to 5

Answer

Change timeoutSeconds to 30

Answer

Set initialDelaySeconds to 300

Question 9

You have a pod that takes 2 minutes to start its application. You want to avoid the liveness probe from killing the pod during startup, but still have it active afterward. Which probe should you add to the pod spec?

Accepted Answer

Add a startup probe with a failureThreshold high enough to cover the startup time. A startup probe is designed specifically for slow-starting containers. It runs before the liveness probe and, if it fails, the container is killed. By setting a high failureThreshold (e.g., 10 with a 10-second period gives 100 seconds), you allow the application up to 2 minutes to start without the liveness probe interfering. Once the startup probe succeeds, the liveness probe takes over normally.

Answer

Increase the timeoutSeconds on the liveness probe

Answer

Set periodSeconds on the liveness probe to 120

Answer

Set initialDelaySeconds on the liveness probe to 120

Question 10

Which FOUR of the following are valid probe handlers in Kubernetes?

Accepted Answer

exec. Kubernetes supports four probe handler types: ExecAction (exec), HTTPGetAction (httpGet), TCPSocketAction (tcpSocket), and GRPCAction (gRPC). The gRPC probe handler was added in v1.24. UDP is not a supported probe handler. Since the question asks for THREE but there are four valid options, all four except udpSocket are correct in this context.

Answer

udpSocket

Question 11

You want to run a command inside an existing container 'app-container' in pod 'my-pod'. The pod has only one container. Which command enters an interactive shell?

Accepted Answer

kubectl exec -it my-pod -- /bin/sh. The correct command is `kubectl exec -it my-pod -- /bin/sh` because it provides an interactive shell session within the only container of the pod. The `-it` flags are essential for interactive mode, allocating a pseudo-TTY and connecting stdin, while `--` delimits the command from kubectl arguments.

Answer

kubectl exec my-pod -c app-container /bin/sh

Answer

kubectl run -it my-pod --image=busybox

Answer

kubectl attach my-pod

Question 12

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 13

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 14

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 15

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 16

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 17

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 18

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

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 20

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