CKAD Application Observability and Maintenance Practice Test 2 — 15 Questions

Question 1

A pod has been scheduled on a node but is stuck in 'ContainerCreating' state. The team suspects a missing storage class. Which command would best confirm this?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` provides detailed event logs and status conditions for the pod, including specific error messages like 'failed to provision volume with StorageClass' or 'storageclass.storage.k8s.io "" not found'. This directly confirms whether a missing storage class is the root cause of the 'ContainerCreating' state, as the pod's events will surface the exact provisioning failure.

Answer

kubectl describe node

Answer

kubectl get pvc

Answer

kubectl get storageclass

Question 2

A pod is running but the application inside is not serving traffic. The team runs 'kubectl exec -it <pod> -- curl localhost:8080' and gets 'Connection refused'. What is the most likely cause?

Accepted Answer

Application is not listening on port 8080. The 'Connection refused' error from curl indicates that the TCP connection to port 8080 was actively rejected by the kernel, meaning no process is listening on that port inside the container. This is most commonly caused by the application not starting, crashing before binding, or being configured to listen on a different port (e.g., 3000, 8443). The error is immediate and does not suggest a timeout or network-level block.

Answer

Container logs are full and writing to disk is slow

Answer

NetworkPolicy is blocking traffic

Answer

Liveness probe is failing and restarting the container

Question 3

A developer wants to view the resource usage of all containers in a specific pod. Which command should they use?

Accepted Answer

kubectl top pod --containers. `kubectl top pod --containers` displays per-container CPU and memory metrics for a specific pod, which is exactly what the developer needs to view resource usage of all containers within that pod. The `--containers` flag is essential to break down the pod-level metrics into individual container-level metrics.

Answer

kubectl top pods --all-namespaces

Answer

kubectl top pods

Answer

kubectl top pod <pod>

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 best practices for configuring readiness probes?

Accepted Answer

Set initialDelaySeconds to avoid startup race conditions. Setting `initialDelaySeconds` in a readiness probe prevents the probe from starting before the container's application has had time to initialize. Without this delay, the probe might fail immediately during startup, causing the container to be prematurely marked as not ready and removed from service, even though the application would have become ready given a few more seconds. This avoids race conditions between container startup and probe evaluation.

Answer

Use the same endpoint as the liveness probe

Answer

Configure the probe to restart the container if it fails

Question 6

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 7

You are a platform engineer managing a production Kubernetes cluster. A team deploys a stateful application called 'inventory-service' with 3 replicas using a StatefulSet. Each pod writes logs to a persistent volume via a PersistentVolumeClaim. Recently, the team reports that the application becomes unresponsive after running for a few hours. You notice that the pods are still running (READY 1/1) but the application does not respond to HTTP requests. You exec into one pod and find that the disk is 100% full. The PVC is backed by a cloud disk (e.g., AWS EBS). You check the pod's resource limits and see that memory and CPU are not exhausted. The container logs are not rotated. Which course of action should you take to resolve the immediate issue and prevent recurrence?

Accepted Answer

Increase the size of the PVC to provide more disk space, and configure log rotation inside the container to limit log file size. The immediate issue is a full disk caused by unrotated logs. Increasing the PVC size provides temporary relief, while configuring log rotation inside the container (e.g., using logrotate or the application's own rotation) prevents the disk from filling up again. This directly addresses the root cause without changing the application's logging behavior or introducing unnecessary sidecars.

Answer

Add a sidecar container that compresses and archives logs to a remote storage every hour

Answer

Change the application to log to stdout and configure Docker log rotation on the host

Answer

Configure a log rotation sidecar that writes logs to an emptyDir volume with size limit

Question 8

You need to view metrics from a Pod running a web server. Which approach follows Kubernetes best practices?

Accepted Answer

Configure a Prometheus server to scrape the Pod's /metrics endpoint.. Prometheus is the de facto standard for monitoring in Kubernetes, and scraping a Pod's /metrics endpoint is the recommended approach for collecting application-level metrics. This follows the Kubernetes best practice of exposing metrics via an HTTP endpoint that a monitoring system can scrape, rather than relying on ephemeral commands or resource-level metrics.

Answer

Use kubectl top pod to view CPU and memory metrics.

Answer

Exec into the container and run curl to check health.

Answer

Create a ServiceMonitor resource to expose metrics.

Question 9

A Pod is running but not responding to requests. The liveness probe is a TCP check on port 8080. What is the most likely issue?

Accepted Answer

The application is listening on port 8080 but not processing requests correctly.. A is correct because a TCP liveness probe only checks if the port is open and accepting connections, not whether the application is actually processing requests. If the application is listening on port 8080 but is stuck or not handling HTTP traffic correctly, the TCP probe will still succeed, and Kubernetes will not restart the container. This is a common scenario where the application is 'alive' at the socket level but not 'healthy' at the application layer.

Answer

The container is being throttled due to CPU limits.

Answer

The probe's initial delay is too short.

Answer

The liveness probe is misconfigured and should be an HTTP GET.

Question 10

You need to debug a Pod that is in CrashLoopBackOff. Which command should you run first?

Accepted Answer

kubectl logs . When a Pod is in CrashLoopBackOff, the immediate priority is to see why the container is failing. `kubectl logs ` retrieves the container's stdout/stderr output, which typically contains the error message (e.g., missing config, runtime exception, or startup failure). This is the fastest way to get the root cause without modifying the Pod state.

Answer

kubectl get events --sort-by=.lastTimestamp

Answer

kubectl exec -it <pod-name> -- sh

Answer

kubectl describe pod <pod-name>

Question 11

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 12

The Pod 'myapp' is in CrashLoopBackOff. Based on the exhibit, what is the most likely cause?

Accepted Answer

The container is trying to bind to a port already used by a sidecar or previous instance.. The Pod is in CrashLoopBackOff, which indicates the container repeatedly crashes. The most likely cause is that the container is trying to bind to a port already in use by a sidecar or a previous instance of the same container that hasn't fully terminated. This is a common scenario when a sidecar container (e.g., a logging proxy) binds to the same port, or when the container's port is not released quickly enough after a restart, leading to an immediate crash on startup.

Answer

The init container failed to complete.

Answer

The readiness probe is misconfigured.

Answer

The liveness probe is failing and restarting the container.

Question 13

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 14

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 15

Refer to the exhibit. A pod named 'app-backend-6b4c9d8f7-2x4z5' is in CrashLoopBackOff state. What is the MOST likely cause of this issue?

Accepted Answer

The container is crashing due to a misconfiguration or application error.. A CrashLoopBackOff state indicates that the container in the pod is repeatedly crashing and being restarted by the kubelet. The most common cause is a misconfiguration (e.g., incorrect environment variables, missing dependencies, or a faulty entrypoint script) or an application error (e.g., a runtime exception or panic). The kubelet detects the crash via the container runtime (e.g., containerd) and applies an exponential backoff delay before restarting, leading to the CrashLoopBackOff status.

Answer

The container has exceeded its memory limit and is being OOMKilled.

Answer

The node running the pod is down, preventing the container from starting.

Answer

A network policy is blocking the container from accessing required services.