CKAD Application Observability and Maintenance — Timed 10 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