CKAD Application Observability and Maintenance Practice Test 11 — 15 Questions

Question 1

Which command streams logs from a pod in real-time?

Accepted Answer

kubectl logs -f pod-name. `kubectl logs -f` (the `-f` flag stands for 'follow') streams log output from a pod in real-time, similar to `tail -f` on a file. This is the standard Kubernetes command for continuous log monitoring, allowing you to see new log lines as they are written by the container.

Answer

kubectl logs --stream pod-name

Answer

kubectl logs --previous pod-name

Answer

kubectl logs pod-name

Question 2

You have a Deployment named 'api' with 3 replicas. You need to ensure that new pods are not added to the Service's endpoints until the application is ready to serve traffic. Which probe configuration should you add to the pod spec?

Accepted Answer

Readiness probe. A Readiness probe is the correct choice because it controls whether a pod is added to a Service's endpoints. Kubernetes will only mark a pod as Ready when the probe succeeds, and only Ready pods receive traffic from the Service. This ensures new pods are not added until the application is ready to serve traffic.

Answer

No probe is needed; pods are automatically added when running

Answer

Startup probe

Answer

Liveness probe

Question 3

You need to debug a pod that has no running containers because it is in a CrashLoopBackOff state. You want to start an ephemeral container with debugging tools in the same namespace. Which command accomplishes this?

Accepted Answer

kubectl debug -it pod-name --image=busybox --target=container-name. `kubectl debug` allows you to start an ephemeral container in an existing pod that is in a CrashLoopBackOff state. The `--target` flag attaches the ephemeral container to the same Linux namespace as the specified container, enabling debugging without restarting the pod. This is the only command that works when the pod has no running containers and `kubectl exec` fails.

Answer

kubectl run debug --image=busybox -it --restart=Never

Answer

kubectl attach pod-name

Answer

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

Question 4

You have a Deployment that uses a ConfigMap. You update the ConfigMap, but the pods are not picking up the changes. What is the MOST efficient way to force the pods to use the new ConfigMap values without downtime?

Accepted Answer

Run 'kubectl rollout restart deployment/deployment-name'. A is correct because `kubectl rollout restart deployment/deployment-name` triggers a new ReplicaSet and gracefully terminates old pods while creating new ones, which will mount the updated ConfigMap. This avoids downtime by leveraging the Deployment's rolling update strategy, ensuring the new pods read the current ConfigMap data from the volume mount or environment variable reference.

Answer

Delete the pods manually and let the ReplicaSet recreate them

Answer

Delete the ConfigMap and recreate it with the same name

Answer

Edit the Deployment to add an annotation, triggering a rollout

Question 5

You want to ensure your application shuts down gracefully when a pod is terminated. The application needs 30 seconds to clean up. Which field should you set in the pod spec?

Accepted Answer

terminationGracePeriodSeconds: 30. `terminationGracePeriodSeconds` defines the time Kubernetes waits for a pod to shut down gracefully after sending a SIGTERM signal. Setting it to 30 seconds gives the application the required cleanup window before a SIGKILL is forced.

Answer

spec.containers[].livenessProbe.initialDelaySeconds: 30

Answer

spec.containers[].lifecycle.preStop.exec.command: ["sleep", "30"]

Answer

spec.containers[].readinessProbe.periodSeconds: 30

Question 6

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 7

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 8

Which kubectl command streams logs from a pod named 'web-pod' in real-time?

Accepted Answer

kubectl logs -f web-pod. The `-f` flag (short for `--follow`) tells kubectl to stream logs from the pod in real-time, similar to `tail -f` on a file. This is essential for live monitoring of application output as it is generated.

Answer

kubectl logs --since=5m web-pod

Answer

kubectl logs --tail=100 web-pod

Answer

kubectl logs web-pod

Question 9

What is the purpose of a readiness probe in Kubernetes?

Accepted Answer

To control whether the pod receives traffic from Services. A readiness probe determines whether a container is ready to serve traffic. If the probe fails, the pod is removed from the endpoints of Services, thus it does not receive traffic. Option B describes a startup probe (to delay liveness/readiness probes for slow-starting containers). Option C describes resource monitoring, not a probe. Option D describes a liveness probe, which restarts the container if unhealthy.

Answer

To delay the start of other probes for slow-starting containers

Answer

To monitor resource usage of the container

Answer

To restart the container if it becomes unhealthy

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 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 11

You are debugging a pod that is running but not responding to network requests on port 8080. You suspect the application inside the container is faulty. You need to run an interactive shell inside the container to inspect the process. Which command should you use?

Accepted Answer

kubectl exec -it pod-name -- /bin/sh. `kubectl exec -it pod-name -- /bin/sh` opens an interactive shell inside the running container, allowing you to inspect processes, check network listeners, and debug the application directly. This is the standard command for gaining shell access to a container in Kubernetes.

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name -f

Answer

kubectl debug -it pod-name --image=busybox

Question 12

A developer configures a liveness probe for a container that takes a long time to start (about 120 seconds). The probe uses httpGet on port 8080 with a path '/healthz'. The probe is configured with initialDelaySeconds=10, periodSeconds=10, failureThreshold=3. The pod enters CrashLoopBackOff. What is the MOST likely cause?

Accepted Answer

The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container. The liveness probe is configured with initialDelaySeconds=10, which means Kubernetes will start probing 10 seconds after the container starts. Since the application takes about 120 seconds to become healthy, the probe will fail immediately. With failureThreshold=3 and periodSeconds=10, the probe will fail after 30 seconds (3 * 10s), causing Kubernetes to restart the container before it has finished initializing, leading to CrashLoopBackOff.

Answer

The failureThreshold should be increased to 10

Answer

The httpGet path '/healthz' is incorrect and should be '/ready'

Answer

The readiness probe is misconfigured and should be used instead of a liveness probe

Question 13

A pod has a startup probe with failureThreshold: 30 and periodSeconds: 10. The application takes up to 5 minutes to start. What should be changed to ensure the startup probe does not kill the container prematurely?

Accepted Answer

Increase failureThreshold to 40. Increasing failureThreshold to 40 (from 30) with periodSeconds: 10 gives a total timeout of 40 × 10 = 400 seconds (6 minutes 40 seconds), which exceeds the 5-minute startup time. Setting initialDelaySeconds (Option D) would also delay the first probe execution, but best practices recommend adjusting the probe's failure threshold and interval instead of using an initial delay for startup probes, as the purpose of a startup probe is to start probing immediately and replace the need for an initial delay.

Answer

Change periodSeconds to 5

Answer

Change timeoutSeconds to 30

Answer

Set initialDelaySeconds to 300

Question 14

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 means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification so the container has enough memory to run without being terminated by the Out-Of-Memory (OOM) killer.

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Answer

Delete the namespace and redeploy all workloads

Question 15

You need to configure a liveness probe for a container that starts a web server on port 8080. The probe should check the '/healthz' endpoint. Which YAML snippet correctly defines this probe?

Accepted Answer

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080. It defines an HTTP GET liveness probe that checks the '/healthz' endpoint on port 8080, which is the standard way to verify the health of a web server. The `httpGet` probe sends an HTTP GET request to the specified path and port, and the container is considered healthy if the response status code is between 200 and 399.

Answer

livenessProbe:
  exec:
    command: ["curl", "http://localhost:8080/healthz"]

Answer

livenessProbe:
  httpGet:
    port: 8080

Answer

livenessProbe:
  tcpSocket:
    port: 8080