CKAD Application Observability and Maintenance — 20 Questions

Question 1

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 2

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. The Readiness probe (A) is correct because Kubernetes uses it to determine whether a pod is ready to receive traffic; when the readiness probe fails, the pod is removed from the Service's endpoints, so traffic is only sent to pods that can serve requests. The Startup probe (C) is correct because it protects slow-starting containers by disabling liveness and readiness checks until the application has successfully initialized, ensuring that traffic is not routed to pods that are still starting up and not yet ready. The TCP socket probe (B) and HTTP GET probe (D) are not correct as answers here because they are merely probe mechanisms (handlers) that can be used by readiness, liveness, or startup probes, not distinct probe types that by themselves guarantee traffic is only sent to ready pods. The Liveness probe (E) is incorrect because it only determines whether a container should be restarted, not whether the pod should receive traffic.

Answer

TCP socket probe

Answer

HTTP GET probe

Answer

Liveness probe

Question 3

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 4

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 5

Which THREE of the following are valid methods to view logs of a container that has already terminated?

Accepted Answer

kubectl logs --tail=50. `kubectl logs --tail=50` retrieves the last 50 lines of logs from the specified pod's container. Even if the container has terminated, the logs are still available from the pod's log history, and `--tail` limits the output to the most recent entries, which is useful for debugging recent failures.

Answer

kubectl logs <pod> --all-containers

Answer

kubectl logs --all

Question 6

Which TWO of the following are valid ways to expose application metrics from a Pod in Kubernetes?

Accepted Answer

Expose a /metrics HTTP endpoint and configure Prometheus to scrape it.. Exposing a /metrics HTTP endpoint is the standard pattern for Prometheus-based monitoring. Prometheus uses a pull model, where it periodically scrapes metrics from the /metrics endpoint exposed by the application container. This approach is widely adopted in Kubernetes for application observability.

Answer

Write metrics to stdout and parse them with a log aggregator.

Answer

Use kubectl top to collect metrics and expose them via a Service.

Answer

Create a ServiceMonitor custom resource to push metrics to Prometheus.

Question 7

A company runs a Kubernetes cluster with multiple namespaces. The operations team wants to ensure that any application crash or container restart is automatically detected and the team is notified. Which built-in Kubernetes resource should they configure to achieve this?

Accepted Answer

Event. Kubernetes Events are the built-in resource that records state changes, including pod crashes and container restarts. By configuring a monitoring tool or custom controller to watch Events (e.g., via the Kubernetes API or `kubectl get events`), the operations team can automatically detect application failures and trigger notifications. Events provide the necessary metadata (reason, message, timestamp) to identify crash loops or restart backoffs.

Answer

ConfigMap

Answer

Secret

Answer

CronJob

Question 8

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 9

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 10

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 11

You have a pod with two containers: 'web' and 'sidecar'. You want to view the logs of only the 'sidecar' container. Which command should you use?

Accepted Answer

kubectl logs pod-name -c sidecar. `kubectl logs pod-name -c sidecar` explicitly specifies the container name within the pod using the `-c` flag, allowing you to view logs from only the 'sidecar' container. In Kubernetes, when a pod contains multiple containers, you must specify the container name to isolate logs from a particular container.

Answer

kubectl attach pod-name -c sidecar

Answer

kubectl logs pod-name

Answer

kubectl logs pod-name --container sidecar

Question 12

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

Question 13

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 14

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 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 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container more memory to operate without being killed by the Out-of-Memory (OOM) killer.

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 16

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 17

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 with an OOMKilled message, which indicates the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it has exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause.

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

Question 18

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 --container=sidecar --namespace=dev. Both `kubectl logs app-pod -c sidecar -n dev` (D) and `kubectl logs app-pod --container=sidecar --namespace=dev` (C) are valid and equivalent kubectl commands. The explanation incorrectly dismisses C on the grounds that the CKAD exam prefers shorthand; however, CKAD accepts both short and long flags. Therefore, the question is ambiguous and should be corrected to accept both C and D.

Answer

kubectl logs sidecar -p app-pod -n dev

Answer

kubectl logs app-pod -n dev

Question 19

You want to view the resource usage of all pods running on a node named 'node01'. Which command should you use?

Accepted Answer

kubectl top pods --all-namespaces --field-selector spec.nodeName=node01. `kubectl top pods` retrieves real-time CPU and memory usage metrics for pods, and the `--field-selector spec.nodeName=node01` filter restricts the output to only pods scheduled on the specified node. This directly answers the requirement to view resource usage of all pods on 'node01'.

Answer

kubectl top nodes node01

Answer

kubectl get pods -o wide --all-namespaces --field-selector spec.nodeName=node01

Answer

kubectl describe node node01 | grep -A 10 'Non-terminated Pods'

Question 20

You need to debug a pod that is crashing immediately upon start. You cannot exec into the container because it exits before you can run commands. Which approach should you use to inspect the container's file system?

Accepted Answer

kubectl debug -it pod-name --image=busybox --target=container-name. The correct approach is to use 'kubectl debug' with an ephemeral container (option A). This command creates a temporary container in the same pod, sharing the same volumes and process namespace (if requested), allowing you to inspect the filesystem even when the original container has crashed and exited. Option B fails because the container exits before 'exec' can run. Option C only retrieves logs from the previous instance, not filesystem access. Option D displays pod metadata and events, not filesystem contents.

Answer

kubectl exec -it pod-name -- /bin/sh

Answer

kubectl logs pod-name --previous

Answer

kubectl describe pod pod-name