CKAD Application Observability and Maintenance Practice Test 9 — 15 Questions

Question 1

A developer reports that a pod named 'api-pod' is restarted repeatedly. You run 'kubectl get events --field-selector involvedObject.name=api-pod' and see multiple events with reason 'BackOff' and message 'Back-off restarting failed container'. Which probe failure is MOST likely causing this?

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

Accepted Answer

Liveness probe failure. The 'BackOff' event with 'Back-off restarting failed container' indicates the kubelet is repeatedly restarting the container because it exited with a non-zero exit code. This behavior is directly caused by a liveness probe failure: when the liveness probe fails, kubelet kills the container and restarts it, leading to a crash loop and the BackOff state. Readiness and startup probes do not trigger restarts—they only control traffic routing or delay other probes.

Answer

Resource quota exceeded

Answer

Readiness probe failure

Answer

Startup probe failure

Question 2

You are writing a Deployment manifest for a container that takes up to 60 seconds to become ready. You want to ensure the liveness probe does not interfere during this startup period. What should you configure?

Accepted Answer

Configure a startup probe with a sufficient failureThreshold and period. A startup probe is specifically designed to handle slow-starting containers. It runs during the initial startup phase and, once successful, hands over responsibility to the liveness probe. By setting a sufficient failureThreshold and periodSeconds, you allow the container up to (failureThreshold * periodSeconds) time to start without the liveness probe killing it prematurely.

Answer

Set liveness probe failureThreshold to a high number

Answer

Set readiness probe initialDelaySeconds to 60

Answer

Set liveness probe initialDelaySeconds to 60

Question 3

A pod is stuck in 'Pending' state. You run 'kubectl describe pod pending-pod' and see the following condition: 'Status: False, Type: PodScheduled, Reason: Unschedulable, Message: 0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, 1 node(s) had taint {node.kubernetes.io/memory-pressure: }, 2 node(s) didn't match Pod's node affinity/selector.' What is the most specific reason the pod cannot be scheduled?

Accepted Answer

Node taints and/or affinity rules prevent scheduling. The pod is in 'Pending' state because the scheduler cannot find a node that satisfies both the taint tolerations and the node affinity/selector rules. The condition 'Unschedulable' with the message explicitly states that 1 node has disk-pressure taint, 1 node has memory-pressure taint, and 2 nodes don't match the pod's node affinity/selector. This means the pod lacks tolerations for the taints and/or its affinity rules exclude all available nodes, so the scheduler cannot place it.

Answer

Container image pull failure

Answer

Pod is in CrashLoopBackOff

Answer

Insufficient CPU resources

Question 4

You need to check the CPU and memory usage of a pod named 'monitored-pod' in the 'default' namespace. Which command should you run?

Accepted Answer

kubectl top pod monitored-pod. `kubectl top pod` is the command specifically designed to display real-time CPU and memory usage metrics for pods in Kubernetes. It relies on the metrics server to collect resource usage data and presents it in a concise table format, making it the appropriate tool for checking resource consumption of 'monitored-pod'.

Answer

kubectl get pod monitored-pod -o wide

Answer

kubectl describe pod monitored-pod

Answer

kubectl logs monitored-pod

Question 5

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 6

You want to debug a pod that has no shell or debugging tools installed. Which feature allows you to temporarily add a sidecar container with debugging tools to a running pod?

Accepted Answer

kubectl debug -it my-pod --image=busybox --target=my-container. `kubectl debug` allows you to create an ephemeral container (sidecar) in a running pod, using a specified image (e.g., busybox) that includes debugging tools, without requiring the original container to have a shell or tools. This feature leverages the Ephemeral Containers alpha feature (enabled by default in Kubernetes 1.23+) to inject a temporary container into an existing pod for debugging purposes.

Answer

kubectl exec -it my-pod -- /bin/bash

Answer

kubectl cp /tmp/debug-tool my-pod:/tmp/

Answer

kubectl port-forward my-pod 8080:80

Question 7

You need to configure a container to shut down gracefully when it receives a SIGTERM signal, with a timeout of 30 seconds before force kill. Which field in the Pod spec should you set?

Accepted Answer

terminationGracePeriodSeconds. The `terminationGracePeriodSeconds` field in a Pod spec defines the duration (in seconds) that Kubernetes waits after sending a SIGTERM signal to the container's main process before forcefully killing it with SIGKILL. Setting this to 30 seconds allows the container to perform graceful shutdown tasks (e.g., closing connections, flushing data) within that window, meeting the requirement.

Answer

activeDeadlineSeconds

Answer

livenessProbe.periodSeconds

Answer

restartPolicy

Question 8

You have a Deployment called 'web-deploy' with 3 replicas. One of the pods is not receiving traffic, but it shows 'Running' and passes its liveness probe. The readiness probe is configured as a TCP socket check on port 8080. You verify that the application is listening on port 8080. What is a likely reason the pod is not receiving traffic?

Accepted Answer

The readiness probe is succeeding even though the application is not truly ready, because TCP check only verifies the port is open. A TCP readiness probe only confirms that the TCP port is open and accepting connections, not that the application is fully ready to serve traffic. In this scenario, the application is listening on port 8080 (so the TCP check succeeds), but the pod may still be in a state where it cannot process requests (e.g., still initializing internal caches or waiting for dependencies). Since the readiness probe passes, the pod is added to the Service's endpoints, but traffic sent to it may be dropped or fail, causing the pod to not receive traffic effectively.

Answer

The service is configured to use a different port

Answer

The pod's node is cordoned

Answer

The liveness probe is failing and restarting the container

Question 9

You run 'kubectl get pods -o wide' and see that a pod 'worker-pod' is in 'Completed' state with 'Restart Count: 5'. The pod's restart policy is 'OnFailure'. What is the most likely reason the pod has restarted 5 times?

Accepted Answer

The container exited with non-zero exit code multiple times before succeeding. B is correct because the pod's restart policy is 'OnFailure', which means the kubelet will restart the container only when it exits with a non-zero exit code. The pod is in 'Completed' state with a restart count of 5, indicating the container exited with a non-zero code multiple times (triggering restarts) before finally exiting with a zero exit code and reaching completion.

Answer

The liveness probe failed and restarted the container

Answer

The pod's node was rebooted

Answer

The pod was evicted due to node pressure

Question 10

You deploy a pod with the following specification:

apiVersion: v1
kind: Pod
metadata:
  name: probe-pod
spec:
  containers:
  - name: app
    image: nginx
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 3

The application listens on port 80, not 8080. What will happen to the pod?

Accepted Answer

The container will be restarted repeatedly due to liveness probe failure. The liveness probe is configured to perform an HTTP GET request on port 8080, but the application (nginx) listens on port 80. Since the probe will never receive a successful HTTP response (it will get a connection refused or timeout), it will fail. With a failureThreshold of 3, after three consecutive failures the kubelet will consider the container unhealthy and restart it. This cycle repeats indefinitely, causing the container to be restarted repeatedly.

Answer

The pod will be terminated and not restarted

Answer

The pod will start and run normally

Answer

The pod will be stuck in 'Pending' state

Question 11

Which kubectl command shows detailed information about a pod, including events, labels, and container state?

Accepted Answer

kubectl describe pod my-pod. B is correct because `kubectl describe pod my-pod` provides a comprehensive summary of the pod, including its current state, labels, annotations, conditions, container states (waiting/running/terminated with reasons), and a chronological list of recent events (e.g., pulls, starts, restarts). This makes it the standard command for detailed troubleshooting of a pod's lifecycle and configuration.

Answer

kubectl logs my-pod

Answer

kubectl get pod my-pod -o yaml

Answer

kubectl top pod my-pod

Question 12

You want to view the events related to a specific pod named 'my-pod' in the 'default' namespace. Which command filters events to show only those pertaining to this pod?

Accepted Answer

kubectl get events --field-selector involvedObject.name=my-pod. `kubectl get events --field-selector involvedObject.name=my-pod` uses a field selector to filter events by the `involvedObject.name` field, which directly matches the pod's name. This approach is precise and avoids parsing unstructured output, ensuring only events related to that specific pod are returned.

Answer

kubectl describe pod my-pod

Answer

kubectl get events | grep my-pod

Answer

kubectl logs my-pod

Question 13

Which TWO of the following are valid liveness probe types in Kubernetes?

Accepted Answer

tcpSocket. In Kubernetes, liveness probes determine if a container is running properly. The valid probe types are `exec` (command), `tcpSocket`, and `httpGet`. Option B (`tcpSocket`) is correct because it attempts to open a TCP connection to a specified port; if the connection succeeds, the probe is considered successful.

Answer

command

Answer

portCheck

Answer

grpc

Question 14

Which THREE of the following are valid parameters for a probe?

Accepted Answer

initialDelaySeconds. `initialDelaySeconds` is a valid field in a Kubernetes probe specification that defines the number of seconds to wait before initiating the first probe after the container starts. This allows the application time to initialize before health checks begin, preventing premature failures.

Answer

maxRetries

Answer

backoffSeconds

Question 15

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff' state. Which TWO conditions could cause this state?

Accepted Answer

The container exits immediately with a non-zero exit code. A container that exits immediately with a non-zero exit code causes Kubernetes to restart it repeatedly, leading to the CrashLoopBackOff state. The kubelet detects the exit code and increments the restart counter, applying an exponential backoff delay. This is the classic symptom of an application crash or misconfiguration.

Answer

The node is out of disk space

Answer

The readiness probe is failing

Answer

The pod is pending because of insufficient resources