CKAD Application Observability and Maintenance Practice Test 7 — 15 Questions

Question 1

Which THREE of the following are correct statements about the terminationGracePeriodSeconds field? (Select 3)

Accepted Answer

The default value is 30 seconds. The Kubernetes documentation specifies that the default value for terminationGracePeriodSeconds is 30 seconds. This field is part of the PodSpec and controls the duration between sending SIGTERM to the container and forcefully killing it with SIGKILL. If not set, Kubernetes applies this default to ensure a reasonable window for graceful shutdown.

Answer

The default value is 0 seconds

Answer

It is used to configure the readiness probe timeout

Question 2

Which TWO of the following are valid approaches to debug a pod that is in a CrashLoopBackOff state? (Select 2)

Accepted Answer

Use 'kubectl debug' to start an ephemeral container for troubleshooting. 'kubectl debug' can start an ephemeral container in the same pod as the crashing container, allowing you to inspect the environment (e.g., filesystem, network, processes) without the main container running. This is especially useful when the main container crashes immediately and you cannot exec into it. Ephemeral containers share the pod's namespaces (e.g., network, PID) and can mount the same volumes, giving you a live debugging environment.

Answer

Exec into the pod with 'kubectl exec -it' to inspect the environment

Answer

Check resource usage with 'kubectl top pod'

Answer

Create a new pod with 'kubectl run' using the same image

Question 3

You need to view the logs of a container named 'sidecar' inside a pod named 'app'. Which command should you use?

Accepted Answer

kubectl logs app -c sidecar. `kubectl logs app -c sidecar` explicitly targets the 'sidecar' container within the 'app' pod. In Kubernetes, when a pod runs multiple containers, you must use the `-c` flag to specify which container's logs to retrieve; otherwise, the command fails or returns ambiguous output.

Answer

kubectl logs app --previous -c sidecar

Answer

kubectl logs app sidecar

Answer

kubectl logs app -c sidecar -p

Question 4

You have a Deployment with a liveness probe using an exec command. The probe currently runs 'cat /tmp/healthy' and fails after 3 failures. You notice the pod is being restarted even though the application is healthy. What is the most likely cause?

Accepted Answer

The file /tmp/healthy does not exist or is not being updated by the application. The liveness probe executes 'cat /tmp/healthy' and fails after 3 consecutive failures. If the file /tmp/healthy does not exist or is not being updated by the application, the command returns a non-zero exit code, causing the probe to fail and Kubernetes to restart the container even though the application process itself is running and healthy.

Answer

The readiness probe is misconfigured and is shutting down the pod

Answer

The liveness probe is using the wrong HTTP endpoint

Answer

The probe timeoutSeconds is set too low, causing the probe to fail before the command completes

Question 5

Which command shows resource usage (CPU and memory) for pods in a namespace?

Accepted Answer

kubectl top pod -n . The `kubectl top pod` command is the correct way to view real-time CPU and memory usage for pods in a specific namespace. The `-n ` flag targets the desired namespace, and the command relies on the metrics-server to collect resource usage data from the kubelet's cAdvisor endpoint.

Answer

kubectl top node

Answer

kubectl top pods

Answer

kubectl get pods --show-labels

Question 6

A pod with a startup probe configured is taking longer than usual to start. The startup probe has 'failureThreshold: 10' and 'periodSeconds: 5'. What is the maximum time the pod has to start before it is restarted?

Accepted Answer

50 seconds. The maximum time a pod has to start before being restarted is calculated by multiplying the startup probe's `failureThreshold` (10) by its `periodSeconds` (5), which equals 50 seconds. This is because the startup probe runs every 5 seconds, and after 10 consecutive failures (i.e., the probe never succeeds within that window), the kubelet restarts the container. The startup probe is specifically designed to give slow-starting applications a grace period before the liveness probe takes over.

Answer

10 seconds

Answer

30 seconds

Answer

60 seconds

Question 7

You have a Deployment with 3 replicas. The pods have a readiness probe that checks an HTTP endpoint /ready. One pod's readiness probe is failing. What will happen?

Accepted Answer

The pod will be removed from the Service endpoints. C is correct because a failing readiness probe causes the kubelet to mark the pod as not ready, which removes its IP address from the Endpoints object (or EndpointSlice) backing the Service. The pod remains running and is not restarted or terminated; it simply stops receiving traffic from the Service. This ensures that only healthy pods serve requests, maintaining application reliability.

Answer

The pod will be restarted by the kubelet

Answer

The Deployment will create a new pod to maintain 3 replicas

Answer

The pod will be terminated gracefully

Question 8

You need to view events for a specific pod named 'web-1' in the 'default' namespace. Which command shows events related to this pod?

Accepted Answer

kubectl get events --field-selector involvedObject.name=web-1. `kubectl get events --field-selector involvedObject.name=web-1` filters events by the `involvedObject.name` field, which directly matches the pod name. This is the precise way to retrieve only events related to a specific pod in Kubernetes, as events are associated with objects via the `involvedObject` field, not labels.

Answer

kubectl get events

Answer

kubectl describe pod web-1 --events

Answer

kubectl get events --selector name=web-1

Question 9

What is the purpose of a readiness probe?

Accepted Answer

To indicate whether the container is ready to serve traffic. A readiness probe determines whether a container is ready to accept traffic. If the probe fails, the Pod's IP address is removed from the Endpoints of the associated Service, preventing traffic from being routed to an unready container. This is distinct from liveness probes, which restart containers, and startup probes, which indicate successful initialization.

Answer

To restart the container if it becomes unresponsive

Answer

To indicate that the container has started successfully

Answer

To measure the resource usage of the container

Question 10

A pod is stuck in 'Pending' state. You run 'kubectl describe pod' and see '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory.' What does this mean?

Accepted Answer

The pod's resource requests exceed available resources on any node. The 'Pending' state indicates the pod has been accepted by the Kubernetes API server but cannot be scheduled onto a node. The message '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory' means the scheduler evaluated all nodes and found that none had enough allocatable CPU and memory to satisfy the pod's resource requests. This is a scheduling failure caused by the pod's requests exceeding the available resources on any node.

Answer

The container image is not available

Answer

The liveness probe is failing

Answer

The container is crashing due to an error

Question 11

You want to configure a pod so that it receives a SIGTERM signal and has 60 seconds to shut down gracefully before being forcefully killed. Which field should you set?

Accepted Answer

terminationGracePeriodSeconds: 60. The `terminationGracePeriodSeconds` field in the Pod spec defines the duration (in seconds) that Kubernetes waits after sending a SIGTERM to the primary container process before sending a SIGKILL. Setting it to 60 gives the pod 60 seconds to shut down gracefully, which is exactly what the question requires.

Answer

lifecycle.preStop.exec.command with sleep 60

Answer

livenessProbe.initialDelaySeconds: 60

Answer

resources.limits.cpu

Question 12

You need to see the YAML definition of a running pod named 'app' including the current status. Which command should you use?

Accepted Answer

kubectl get pod app -o yaml. `kubectl get pod app -o yaml` retrieves the current live state of the pod from the Kubernetes API server and outputs it in YAML format, including the `status` field with the latest conditions, container states, and other runtime information. This command directly queries the API without modifying the object, making it the standard way to view the full definition and status of a running pod.

Answer

kubectl edit pod app

Answer

kubectl get pod app -o yaml --export

Answer

kubectl get pod app -o json

Question 13

Which TWO commands can be used to view the logs of a pod that has crashed?

Accepted Answer

kubectl logs --previous. `kubectl logs --previous` retrieves logs from the previous instance of a container in a pod that has crashed and been restarted. This is essential for debugging crash loops, as the current container may have no logs or only post-crash output. The `--previous` flag accesses the terminated container's logs stored by the kubelet.

Answer

kubectl logs <pod> --tail=0 -f

Answer

kubectl logs -c

Answer

kubectl logs <pod>

Question 14

Which THREE are valid types of probes in Kubernetes?

Accepted Answer

Startup probe. Startup probes are a valid Kubernetes probe type used to determine when a container application has started successfully. They are particularly useful for legacy applications that have slow startup times, as they delay the start of liveness and readiness probes until the startup probe succeeds, preventing premature container restarts.

Answer

Survival probe

Answer

Health probe

Question 15

Which TWO are valid ways to debug a pod using ephemeral containers?

Accepted Answer

kubectl debug -it --image=busybox -- sh. `kubectl debug -it --image=busybox -- sh` creates an ephemeral container in the target pod and attaches an interactive terminal to it. This is the standard Kubernetes mechanism for debugging a running pod without modifying its original container spec, using the ephemeral container feature (alpha in v1.16, stable in v1.23).

Answer

kubectl run debug --image=busybox -- sh

Answer

kubectl exec -it <pod> -- sh

Answer

kubectl attach to the pod