Courseiva

CCNA Ckad Observability Questions

34 questions · Ckad Observability topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQeasy

A pod is running but not responding to traffic. You suspect the application inside the container is unhealthy but the pod is still marked as 'Running'. Which probe should be configured to remove the pod from the service's endpoints automatically?

A.Readiness probe
B.Resource limits
C.Startup probe
D.Liveness probe
AnswerA

The readiness probe is the only probe that directly controls whether the Pod is added to or retained in the Endpoints object backing a Service. When it fails, the kubelet marks the Pod's Ready condition as False, and the endpoints controller removes its IP from all matching Service backends, so it stops receiving new traffic while it is still running. This precisely matches the symptom of a running Pod that is unresponsive: it should be taken out of rotation, not restarted.

Why this answer

A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, Kubernetes removes the pod's IP address from the endpoints of all Services that match the pod's labels, effectively stopping traffic from reaching the pod while it remains in the Running state. This is the correct probe for removing an unhealthy pod from Service endpoints without terminating it.

Exam trap

The CKAD exam often tests the distinction between Liveness and Readiness probes, and the trap here is that candidates mistakenly choose Liveness probe because they think 'unhealthy' always means 'restart', but the question specifically asks about removing the pod from Service endpoints, which is the Readiness probe's job.

How to eliminate wrong answers

Option B is wrong because resource limits (CPU/memory constraints) control how much resources a container can use but do not affect Service endpoint membership or health checking. Option C is wrong because a Startup probe is used to determine when a container has started successfully; it runs only during initialization and does not manage ongoing traffic routing after the pod is Running. Option D is wrong because a Liveness probe indicates whether the container is alive; if it fails, the kubelet restarts the container, but it does not remove the pod from Service endpoints—the pod remains in the endpoint list until it is terminated or its Readiness probe fails.

Practice this question →
2
Matchingmedium

Match each Kubernetes object field to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Maximum resources a container can use

Determines when to restart containers in a pod

Checks if container is running; restarts if fails

Checks if container is ready to serve traffic

Inject a secret value as an environment variable

Why these pairings

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.

Practice this question →
3
Matchingmedium

Match each Kubernetes resource to its API group.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

apps/v1

v1 (core)

networking.k8s.io/v1

autoscaling/v2

networking.k8s.io/v1

Why these pairings

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.

Practice this question →
4
MCQhard

You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?

A.kubectl attach <pod>
B.kubectl exec -it <pod> -- /bin/sh
C.kubectl run debug --image=busybox -it --restart=Never
D.kubectl debug -it <pod> --image=busybox --target=<container>
AnswerD

kubectl debug -it <pod> --image=busybox --target=<container> creates an ephemeral container inside the existing pod, sharing its network, volumes, and (if enabled) process namespace. The --target flag names the container whose namespaces the debug container will share, letting you inspect the failing container's filesystem and processes even while it is crashing. Because ephemeral containers do not restart or affect the original container's lifecycle, this is the correct way to inject a debugging tool into the pod without modifying the pod spec.

Why this answer

`kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original container.

Exam trap

The trap here is that candidates often choose `kubectl exec` or `kubectl attach` out of habit, not realizing those commands require a running container with a shell, whereas `kubectl debug` is the only option that can inject a new container into a pod that lacks debugging tools or is in a failed state.

How to eliminate wrong answers

Option A is wrong because `kubectl attach` attaches to a running container's stdin/stdout/stderr, but it requires the container to have a shell or process running; it cannot add a new container or work if the pod is in a CrashLoopBackOff state. Option B is wrong because `kubectl exec` requires the target container to have a shell (e.g., /bin/sh) and a running process; if the pod has no shell or is failing to start, exec will fail. Option C is wrong because `kubectl run` creates a new standalone pod, not an ephemeral container attached to an existing pod; it cannot debug the original pod's namespace or processes.

Practice this question →
5
MCQmedium

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?

A.Delete and recreate the pod to clear the crash loop
B.Increase the CPU request for the container
C.Increase the memory limit in the pod's container resource specification
D.Delete the namespace and redeploy all workloads
AnswerC

This is correct because the container's memory usage exceeded its configured limit, causing the kernel to invoke the OOM killer and terminate it. Increasing the memory limit in resources.limits.memory raises the cgroup memory ceiling, giving the container a larger allocation before it triggers an OOM kill. However, this is only viable if the node has sufficient allocatable memory; otherwise, the pod may fail to schedule or cause other pods to be evicted due to node pressure.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse OOMKilled with a CPU-related issue and incorrectly choose to adjust CPU resources, or they may think a simple pod restart will fix the problem, when in fact the memory limit must be increased.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod will not resolve the underlying memory exhaustion; the new pod will still hit the same memory limit and be OOMKilled again. Option B is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is caused by exceeding the memory limit, not CPU constraints. Option D is wrong because deleting the namespace and redeploying all workloads is an unnecessarily destructive and disruptive action that does not address the specific memory limit issue.

Practice this question →
6
MCQmedium

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?

A.Increase the memory limit in the pod's container resource specification
B.Delete and recreate the pod to clear the crash loop
C.Delete the namespace and redeploy all workloads
D.Increase the CPU request for the container
AnswerA

OOMKilled is the definitive signal that the container process exceeded its cgroup memory limit and was terminated by the kernel's OOM killer. Raising the memory limit in the pod's container resource specification directly expands the available memory budget, giving the process room to complete its allocation without triggering the kill. This is the correct fix because the restart policy only re-creates the container; without a higher limit the next run will hit the identical memory ceiling and crash again.

Why this answer

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.

Exam trap

The trap here is that candidates confuse OOMKilled with a general crash and choose to delete/recreate the pod, not realizing the underlying memory limit is the cause and must be adjusted.

How to eliminate wrong answers

Option B is wrong because deleting and recreating the pod does not address the root cause — the new pod will still have the same memory limit and will be OOMKilled again. Option C is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that disrupts other workloads and does not fix the memory limit issue. Option D is wrong because increasing the CPU request does not affect memory constraints; OOMKilled is a memory-related termination, not CPU-related.

Practice this question →
7
MCQmedium

You are debugging a pod that is crashing immediately on startup. You want to run an ephemeral container for debugging while the pod is running. Which command should you use?

A.kubectl debug -it pod --image=busybox --target=crashing-container
B.kubectl run debug --image=busybox -it --rm
C.kubectl attach pod
D.kubectl exec -it pod -- /bin/sh
AnswerA

This creates an ephemeral container in the same pod for debugging, even if the main container is failing.

Why this answer

`kubectl debug` with the `--target` flag allows you to attach an ephemeral container to a running pod that is crashing on startup, targeting the specific container that is failing. Ephemeral containers are designed for troubleshooting when `kubectl exec` is not possible (e.g., the container has no shell or crashes immediately), and they run in the pod's namespaces without restarting the pod.

Exam trap

The trap here is that candidates assume `kubectl exec` works on any pod, but it fails when the target container is not running, and they overlook `kubectl debug` as the correct tool for attaching ephemeral containers to crashing pods.

How to eliminate wrong answers

Option B is wrong because `kubectl run debug --image=busybox -it --rm` creates a standalone pod, not an ephemeral container inside the existing crashing pod, so it cannot access the same network or filesystem as the target pod. Option C is wrong because `kubectl attach pod` attaches to the main process of a running container, but if the container is crashing immediately on startup, there is no running process to attach to. Option D is wrong because `kubectl exec -it pod -- /bin/sh` requires the target container to be running and have a shell, which is not the case when the container crashes on startup.

Practice this question →
8
MCQmedium

You need to collect metrics from an application running in a pod. The application exposes metrics on port 8080 at /metrics in Prometheus format. Which resource should you configure to allow Prometheus to scrape these metrics?

A.Create an Ingress resource that exposes the /metrics endpoint externally.
B.Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.
C.Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.
D.Add a PrometheusRule resource that defines the scrape target.
AnswerC

This is the standard approach for Prometheus operator's annotation-based discovery: the service's annotations `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` allow the auto-discovery component to generate a scrape_config targeting the service's endpoints on port 8080. The Service provides a stable DNS name and selects the pods, so even if pod IPs change, Prometheus can dynamically look up the current endpoints. This is distinct from the static ConfigMap method because it enables automatic, label-based target discovery across the cluster.

Why this answer

Prometheus uses a pull-based model to scrape metrics from targets. By adding the `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` annotations to a Service that selects the pod, you enable Prometheus's built-in service discovery to automatically detect and scrape the `/metrics` endpoint on port 8080 without manual configuration.

Exam trap

The trap here is that candidates confuse Prometheus's pull-based scraping with push-based or external access patterns, leading them to choose Ingress (external exposure) or PrometheusRule (alerting) instead of the service annotation that enables automatic internal discovery.

How to eliminate wrong answers

Option A is wrong because an Ingress resource exposes HTTP/HTTPS routes externally for client access, not for Prometheus scraping; Prometheus scrapes internally and does not use Ingress for target discovery. Option B is wrong because while a ConfigMap can hold Prometheus scrape configuration, mounting it into the Prometheus pod is a manual configuration step, not the resource that enables automatic scraping of an application pod; the question asks which resource to configure on the application side to allow scraping. Option D is wrong because a PrometheusRule resource defines alerting and recording rules, not scrape targets; scrape targets are defined via ServiceMonitor, PodMonitor, or service annotations.

Practice this question →
9
MCQmedium

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?

A.Increase the memory limit in the pod's container resource specification
B.Increase the CPU request for the container
C.Delete and recreate the pod to clear the crash loop
D.Delete the namespace and redeploy all workloads
AnswerA

OOMKilled is the error Kubernetes records when the kernel's out-of-memory killer terminates a process because the container exceeded its `spec.containers[].resources.limits.memory` cgroup allotment. Raising that memory limit gives the container more headroom before the cgroup's OOM killer triggers, directly addressing the crash loop. Keep the limit below the node's allocatable memory and adjust the request proportionally so scheduling remains valid.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly resolving the OOM condition.

Exam trap

The trap here is that candidates may confuse OOMKilled with a general crash and choose to delete/recreate the pod, not realizing the OOMKilled status specifically indicates a memory limit violation that requires adjusting resource limits.

How to eliminate wrong answers

Option B is wrong because increasing CPU request does not affect memory allocation; OOMKilled is a memory issue, not a CPU issue. Option C is wrong because deleting and recreating the pod will not resolve the underlying memory limit; the pod will crash again with the same OOMKilled error. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that does not address the specific memory limit misconfiguration and would disrupt all workloads in the namespace.

Practice this question →
10
MCQeasy

You have a Deployment running a web server that takes 30 seconds to initialize. You want to ensure that the load balancer does not send traffic to the pod until it is ready. Which probe should you configure?

A.Readiness probe
B.Resource limit
C.Startup probe
D.Liveness probe
AnswerA

The readiness probe is the correct mechanism because it directly controls whether a pod is added to or removed from the endpoints of a Service. When the probe fails, the kubelet marks the pod as NotReady, and the endpoints controller immediately removes its IP from all backing Services, stopping new traffic. This is essential for deployments where the application needs time to warm up or load data before accepting requests, and it also enables zero-downtime rolling updates by holding back new pods until they are fully operational.

Why this answer

A Readiness probe is the correct choice because it determines whether a Pod is ready to serve traffic. In this scenario, the web server takes 30 seconds to initialize, so a Readiness probe (e.g., an HTTP GET on the application's health endpoint) will prevent the Service (and thus the load balancer) from sending requests until the probe succeeds, ensuring zero traffic is routed to an uninitialized Pod.

Exam trap

The trap here is that candidates confuse Startup probes with Readiness probes, thinking a Startup probe alone will gate traffic, but only the Readiness probe controls whether the Service routes traffic to the Pod.

How to eliminate wrong answers

Option B is wrong because a Resource limit (CPU/memory) controls resource usage and scheduling, not traffic routing; it does not prevent the load balancer from sending traffic to an unready Pod. Option C is wrong because a Startup probe checks if the application has started successfully and is used for slow-starting containers, but it does not control traffic routing from the load balancer; once the Startup probe succeeds, the Liveness and Readiness probes take over, and the Readiness probe is the one that gates traffic. Option D is wrong because a Liveness probe restarts the container if it fails, but it does not prevent traffic from being sent to an unready Pod; a Pod can be alive but not ready, and the Liveness probe would not stop traffic.

Practice this question →
11
MCQeasy

You want to view the logs of a pod named 'web-pod' that has two containers: 'nginx' and 'sidecar'. Which command correctly retrieves the logs from the 'nginx' container?

A.kubectl logs -c nginx web-pod
B.kubectl logs web-pod -c nginx
C.kubectl logs web-pod nginx
D.kubectl logs web-pod --container nginx
AnswerB

Correctly specifies the container with -c, but lacks -f flag to stream logs.

Why this answer

The correct command uses the proper syntax: `kubectl logs <pod-name> -c <container-name>`. Option B follows this syntax correctly. Option A places the container flag before the pod name, which is invalid.

Option C omits the -c flag, which is required when the pod has multiple containers. Option D uses the long form --container, which is valid but the question expects the short form as seen in B. Therefore, B is the best answer.

Practice this question →
12
MCQhard

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?

A.kubectl run debug --image=busybox -it --restart=Never
B.kubectl attach pod-name
C.kubectl debug -it pod-name --image=busybox --target=container-name
D.kubectl exec -it pod-name -- /bin/sh
AnswerC

kubectl debug -it pod-name --image=busybox --target=container-name creates an ephemeral container inside the existing Pod's sandbox, so it shares the same network namespace, IPC namespace, and (when --target is specified) the target container's process namespace. The ephemeral container includes the provided busybox image, giving you a shell (via -it) and common debugging tools even though the original container lacks a shell or has crashed. Because ephemeral containers are managed by the kubelet, the original Pod's spec and lifecycle are unaffected, and if the Pod is not running, kubectl debug will create a copy, so this is the right tool when no containers are running. The --target flag is what lets you see the crashed container's processes, but for ordinary filesystem inspection the ephemeral container also mounts the Pod's volumes.

Why this answer

`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.

Exam trap

The trap here is that candidates assume `kubectl exec` is the standard debugging tool, but it fails when no container is running; `kubectl debug` with `--target` is the correct approach for CrashLoopBackOff scenarios.

How to eliminate wrong answers

Option A is wrong because `kubectl run` creates a new standalone pod, not an ephemeral container in the existing pod, so it cannot debug the specific pod's namespace or filesystem. Option B is wrong because `kubectl attach` only connects to a running container's stdin/stdout/stderr, and it fails when the pod is in CrashLoopBackOff with no running containers. Option D is wrong because `kubectl exec` requires at least one running container in the pod to execute a command, which is not available in CrashLoopBackOff.

Practice this question →
13
MCQhard

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?

A.Increase failureThreshold to 40
B.Change periodSeconds to 5
C.Change timeoutSeconds to 30
D.Set initialDelaySeconds to 300
AnswerA

Increasing failureThreshold to 40 allows the startup probe to fail up to 40 consecutive times before the kubelet declares the container failed. Because the existing periodSeconds is 10, the new total grace period is 40 × 10 = 400 seconds (6m40s), which comfortably exceeds the application's 5-minute (300-second) startup requirement. This is the correct modification because it directly extends the cumulative time the kubelet tolerates an unready container without changing how frequently the probe runs or delaying the start of probing. The extra 100 seconds of tolerance eliminates the risk of premature termination while still allowing the probe to eventually catch a genuinely broken container.

Why this answer

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.

Exam trap

The trap is that candidates may consider setting initialDelaySeconds as a valid solution to extend the probe's grace period. However, for startup probes, the best practice is to adjust failureThreshold and periodSeconds to cover the expected startup time, rather than adding an initial delay which defeats the purpose of immediate probing.

How to eliminate wrong answers

Option B is wrong because changing periodSeconds to 5 reduces the interval between checks, but with failureThreshold: 30, the total timeout becomes 30 × 5 = 150 seconds (2.5 minutes), which is still less than the required 5 minutes. Option C is wrong because timeoutSeconds controls the timeout for a single probe check, not the overall startup window; it does not extend the total time the probe waits for success. Option D is wrong because initialDelaySeconds delays the start of the probe, but the probe still runs with the same failureThreshold and periodSeconds; after the delay, the probe would still kill the container prematurely if the total probe window (30 × 10 = 300 seconds) is not enough.

Practice this question →
14
MCQmedium

A pod is running but not receiving traffic from a Service. The readiness probe is failing. What is the likely effect on the pod?

A.The pod will be marked as CrashLoopBackOff
B.The pod will remain running but will not be included in the Service's endpoints
C.The pod will be terminated and restarted
D.The pod will be evicted from the node
AnswerB

This is the correct behavior. The kubelet continuously executes the readiness probe, and when it fails, the pod is marked as NotReady. As a result, the endpoints controller removes the pod's IP address from the Service's Endpoints object, preventing the Service from forwarding new requests to it — but the pod itself is not stopped, restarted, or evicted, and it can still receive direct traffic from other clients if they target its IP explicitly.

Why this answer

When a readiness probe fails, Kubernetes marks the pod as not ready. The pod continues running, but the associated Service removes the pod's IP from its Endpoints (or EndpointSlice) list. This ensures the Service does not route traffic to a pod that is not prepared to handle requests, while allowing the pod to remain alive for debugging or other internal operations.

Exam trap

The CKAD exam often tests the distinction between readiness and liveness probes, and the trap here is that candidates confuse a failing readiness probe with a failing liveness probe, assuming the pod will be killed or restarted when it will not.

How to eliminate wrong answers

Option A is wrong because CrashLoopBackOff is a status for pods whose containers repeatedly crash (e.g., due to a failing liveness probe or application error), not for pods with a failing readiness probe. Option C is wrong because a failing readiness probe does not trigger pod termination or restart; only a failing liveness probe would cause the kubelet to restart the container. Option D is wrong because pod eviction is caused by node resource pressure (e.g., memory or disk) or node-level failures, not by a readiness probe failure.

Practice this question →
15
MCQhard

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?

A.Run 'kubectl rollout restart deployment/deployment-name'
B.Delete the pods manually and let the ReplicaSet recreate them
C.Delete the ConfigMap and recreate it with the same name
D.Edit the Deployment to add an annotation, triggering a rollout
AnswerA

kubectl rollout restart deployment/deployment-name performs a rolling restart by adding a temporary annotation to the pod template, which forces the Deployment controller to create a new ReplicaSet and progressively swap old pods for new ones. This ensures zero downtime, as new pods are fully ready before old ones are terminated, and crucially, the new pods will read the updated ConfigMap from the API server at container startup. It is the cleanest, most declarative way to push a ConfigMap change to an existing Deployment.

Why this answer

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.

Exam trap

The trap here is that candidates assume ConfigMap updates are automatically reflected in running pods, but Kubernetes only refreshes mounted volumes after a sync interval (and never for environment variables), so a restart is required to pick up changes without downtime.

How to eliminate wrong answers

Option B is wrong because manually deleting pods causes the ReplicaSet to recreate them with the same old ConfigMap data, as the ConfigMap reference in the Pod template hasn't changed; it does not force a refresh. Option C is wrong because deleting and recreating the ConfigMap with the same name does not update the pods' in-memory data or mounted files unless the pods are restarted; the pods continue to use the cached version from the initial mount. Option D is wrong because adding an annotation to the Deployment triggers a rollout only if the annotation change is part of a spec change that causes the Pod template hash to differ; a simple metadata annotation update without a corresponding pod template change does not trigger a rollout in Kubernetes.

Practice this question →
16
MCQeasy

What is the purpose of a readiness probe in Kubernetes?

A.To control whether the pod receives traffic from Services
B.To delay the start of other probes for slow-starting containers
C.To monitor resource usage of the container
D.To restart the container if it becomes unhealthy
AnswerA

A failing readiness probe removes the pod from Service endpoints.

Why this answer

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.

Practice this question →
17
MCQmedium

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?

A.livenessProbe:\n exec:\n command: ["curl", "http://localhost:8080/healthz"]
B.livenessProbe:\n httpGet:\n port: 8080
C.livenessProbe:\n httpGet:\n path: /healthz\n port: 8080
D.livenessProbe:\n tcpSocket:\n port: 8080
AnswerC

This is the correct liveness probe because it declares an httpGet handler that instructs the kubelet to send an HTTP GET request to the container's /healthz endpoint on port 8080. Kubernetes considers the probe successful if the HTTP response status code is in the 200-399 range, so a 400 or 500 response would restart the container. This definition precisely matches the stated requirement of performing a HTTP GET liveness check against that path and port.

Why this answer

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.

Exam trap

The trap here is that candidates often choose a `tcpSocket` probe (option D) thinking it's sufficient for a web server, but the CKAD exam expects you to use an `httpGet` probe with the correct path to validate the application's health endpoint.

How to eliminate wrong answers

Option A is wrong because it uses an `exec` probe with a `curl` command, which is unnecessary when an `httpGet` probe can directly check the HTTP endpoint; also, `curl` may not be installed in the container image, leading to probe failures. Option B is wrong because it omits the `path` field, so the probe defaults to the root path '/' instead of '/healthz', which may not reflect the actual health check endpoint. Option D is wrong because it uses a `tcpSocket` probe, which only checks if the TCP port is open, not whether the web server is serving the correct HTTP response on '/healthz'.

Practice this question →
18
MCQmedium

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?

A.kubectl describe pod pod-name
B.kubectl logs pod-name -f
C.kubectl debug -it pod-name --image=busybox
D.kubectl exec -it pod-name -- /bin/sh
AnswerD

kubectl exec -it pod-name -- /bin/sh attaches directly to the primary container's process namespace and starts an interactive shell there. The -i flag keeps stdin open, and -t allocates a pseudo-TTY, giving you a real terminal session. This lets you run commands such as ps, cat /proc/1/cmdline, lsof, and netstat inside the exact runtime where the application is hanging, enabling direct inspection and troubleshooting of the live process. It is the only option that provides an interactive shell within the existing, running container.

Why this answer

`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.

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which creates a new ephemeral container), and they may choose option C thinking it provides interactive access, but it does not attach to the original application container's process space.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pod` shows pod metadata, events, and status but does not provide an interactive shell or allow process inspection inside the container. Option B is wrong because `kubectl logs -f` streams container logs, which is useful for viewing output but does not give you an interactive shell to run commands or inspect processes. Option C is wrong because `kubectl debug -it pod-name --image=busybox` creates a separate ephemeral container for debugging, not an interactive shell inside the original application container; it is used when the container image lacks debugging tools or the container is crashing, but the question specifies the pod is running and you need to inspect the existing application process.

Practice this question →
19
MCQmedium

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?

A.spec.containers[].livenessProbe.initialDelaySeconds: 30
B.spec.containers[].lifecycle.preStop.exec.command: ["sleep", "30"]
C.spec.containers[].readinessProbe.periodSeconds: 30
D.terminationGracePeriodSeconds: 30
AnswerD

This pod-level field defines the duration between when Kubernetes sends SIGTERM to the container's primary process and when it forcibly follows up with SIGKILL. Setting it to 30 seconds grants your application a full half-minute to finish in-flight requests, close connections, flush logs, and release external resources. Without this grace period, or if set too low, the kubelet will kill the process forcefully, likely causing data loss or incomplete cleanup.

Why this answer

`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.

Exam trap

CNCF often tests the misconception that a `preStop` hook alone guarantees graceful shutdown, but without adjusting `terminationGracePeriodSeconds`, the hook's execution time is counted against the default 30-second grace period, potentially causing a SIGKILL before cleanup completes.

How to eliminate wrong answers

Option A is wrong because `livenessProbe.initialDelaySeconds` controls how long to wait before starting the liveness probe, not the shutdown behavior. Option B is wrong because `preStop` hooks run before the SIGTERM is sent, but they do not extend the total grace period; the `terminationGracePeriodSeconds` must be set to accommodate both the hook and the application's cleanup. Option C is wrong because `readinessProbe.periodSeconds` sets the interval for readiness checks, which is unrelated to graceful termination.

Practice this question →
20
MCQhard

You are debugging a network issue: a pod 'frontend' cannot reach a service 'backend' in the same namespace. The service endpoints are empty. What is the most likely cause?

A.The pod 'frontend' is not in the same namespace as the service 'backend'.
B.The service selector does not match the labels of any running pod.
C.The pod's container port is different from the service port.
D.The kube-proxy is misconfigured and not updating iptables rules.
AnswerB

Endpoints are created by the endpoint controller, which watches pods and compares each pod's labels against the service's spec.selector. If no running pod carries every label key/value in that selector, the Endpoints object remains with an empty address list, even though the service itself exists. This is the textbook cause of an empty Endpoints resource and the correct answer to this symptom.

Why this answer

B is correct because the most common reason for empty endpoints in a Kubernetes service is that the service's selector does not match the labels of any running pod. The service controller continuously monitors pods and updates the Endpoints object to include only those pods whose labels match the service's selector. If no pods match, the endpoints list remains empty, causing the frontend pod to fail to reach the backend service.

Exam trap

The trap here is that candidates often confuse the cause of empty endpoints with other networking issues like port mismatches or kube-proxy problems, but the CKAD exam specifically tests the understanding that endpoints are directly tied to label selector matching, not to port configuration or proxy behavior.

How to eliminate wrong answers

Option A is wrong because the question explicitly states that both the pod and service are in the same namespace, so namespace mismatch is not the cause. Option C is wrong because a mismatch between the container port and the service port would cause connection failures but would not result in empty endpoints; the endpoints would still be populated with the pod's IP and the container port. Option D is wrong because a misconfigured kube-proxy would affect traffic routing (e.g., iptables rules not being updated) but would not cause the service's endpoints to be empty; endpoints are managed by the endpoint controller, not kube-proxy.

Practice this question →
21
Multi-Selectmedium

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?

Select 2 answers
A.Readiness probe
B.TCP socket probe
C.Startup probe
D.HTTP GET probe
E.Liveness probe
AnswersA, C

Controls whether a pod is included in service endpoints.

Why this answer

A Readiness probe (Option A) is specifically designed to determine whether a pod is ready to serve traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring traffic is only sent to pods that are ready. This directly fulfills the requirement of controlling traffic routing based on pod readiness.

Exam trap

The trap here is that candidates confuse probe handlers (like HTTP GET or TCP socket) with probe types (like readiness, liveness, startup), leading them to select handlers instead of the correct probe types that control traffic routing.

Practice this question →
22
MCQmedium

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?

A.Increase the memory limit in the pod's container resource specification
B.Increase the CPU request for the container
C.Delete and recreate the pod to clear the crash loop
D.Delete the namespace and redeploy all workloads
AnswerA

The OOMKilled status means the container's memory usage exceeded its configured memory limit, triggering the kernel's out-of-memory killer. Raising the memory limit in the container resource spec gives the application more headroom to work within, directly addressing the root cause by preventing the OOM kill and subsequent CrashLoopBackOff. Correctly sizing the limit requires observing actual memory usage, as an arbitrarily high limit may hide memory leaks but does stop the crash loop.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse CPU and memory resource management or think that restarting the pod will fix the issue, but OOMKilled is a persistent resource constraint problem that requires adjusting the memory limit.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory usage or prevent OOM kills; CPU and memory are independent resources in Kubernetes. Option C is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the pod will crash again with the same OOMKilled error. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that does not fix the memory limit configuration and would disrupt all other workloads in the namespace.

Practice this question →
23
MCQmedium

A Pod is stuck in CrashLoopBackOff. You run 'kubectl logs mypod' and get no output. What is the most likely cause?

A.The Pod is not ready yet.
B.The application crashes before writing any logs.
C.The liveness probe is failing.
D.The container never started due to a missing image.
AnswerB

The application crashes before writing any logs. This is the correct answer because empty output from `kubectl logs` means the process exited before emitting anything to stdout/stderr. Many applications crash during early startup—such as on missing configuration, failed dependency connection, or a panic in initialization—before reaching any logging call. The container repeatedly restarts, and each attempt produces no logs, so the crash loop yields empty log output.

Why this answer

When a Pod is in CrashLoopBackOff and `kubectl logs mypod` returns no output, the most likely cause is that the application crashes before it can write any logs to stdout/stderr. The container starts, runs briefly, and exits before the logging framework initializes, so no log data is captured by the container runtime.

Exam trap

CNCF often tests the distinction between a container that never starts (image pull failure) and one that starts but crashes immediately, with the key clue being the Pod status (CrashLoopBackOff vs ImagePullBackOff) and the absence of log output indicating a pre-log crash.

How to eliminate wrong answers

Option A is wrong because a Pod not being ready yet would typically show a status like 'ContainerCreating' or 'Init:0/1', not CrashLoopBackOff, and logs would still be available if the container had run. Option C is wrong because a failing liveness probe would cause the container to be restarted, but logs would still contain output from the application before the probe failure, unless the crash happens before any log output. Option D is wrong because if the container never started due to a missing image, the Pod would be in 'ImagePullBackOff' or 'ErrImagePull' status, not CrashLoopBackOff, and `kubectl logs` would return an error like 'container is waiting to start'.

Practice this question →
24
MCQhard

You have a Deployment that must run a legacy application that takes up to 5 minutes to start. You need to ensure the liveness probe does not kill the container prematurely. Which probe configuration should you use?

A.Use a HTTP GET liveness probe with path /healthz and port 8080
B.Set livenessProbe.initialDelaySeconds to 300
C.Configure a startup probe with a high failureThreshold and appropriate initialDelaySeconds
D.Set livenessProbe.periodSeconds to a high value, like 300
AnswerC

Configuring a startup probe with a high failureThreshold and an appropriate initialDelaySeconds is the correct approach: the kubelet runs the startup probe first and disables liveness and readiness probes until the startup probe succeeds. By setting failureThreshold high and periodSeconds short (for example, 30 failures x 2 seconds), you give the application up to 60 seconds to initialize without risking a restart, while still detecting a true startup failure. Once the startup probe passes, the normal liveness and readiness probes take over, ensuring ongoing health checks are responsive and do not interfere with the boot sequence.

Why this answer

A startup probe is specifically designed for slow-starting containers. It runs before the liveness probe and allows the container extra time to initialize without being killed. By setting a high failureThreshold (e.g., 30) and an appropriate initialDelaySeconds, the probe can wait up to 5 minutes for the application to start, after which the liveness probe takes over.

Exam trap

The trap here is that candidates often confuse initialDelaySeconds with a solution for slow starts, but it only delays the first probe and does not prevent the liveness probe from killing the container if the app takes longer than the sum of initialDelaySeconds and the failure threshold interval.

How to eliminate wrong answers

Option A is wrong because a simple HTTP GET liveness probe without any delay or threshold adjustments would start immediately and kill the container after the default failure threshold (3 failures) within seconds, not allowing the 5-minute startup time. Option B is wrong because setting livenessProbe.initialDelaySeconds to 300 only delays the first liveness check but does not prevent the probe from failing quickly after that; the container could still be killed if the application takes the full 5 minutes to respond, as the probe would fail after the initial delay and hit the failure threshold. Option D is wrong because setting livenessProbe.periodSeconds to a high value like 300 reduces the frequency of checks but does not prevent the probe from failing on its first check after the initial delay; the container could still be killed before the application starts if the probe fails immediately.

Practice this question →
25
MCQhard

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?

A.The failureThreshold should be increased to 10
B.The httpGet path '/healthz' is incorrect and should be '/ready'
C.The readiness probe is misconfigured and should be used instead of a liveness probe
D.The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container
AnswerD

The liveness probe is configured to begin only 10 seconds after container start (initialDelaySeconds=10), but the application requires 120 seconds to initialize and listen on its health endpoint. During those first 110 seconds, the probe returns HTTP 500 or fails to connect, and after the default failureThreshold (3) consecutive failures, Kubernetes kills and restarts the container. This restart loop never gives the application the 120 seconds it needs, so it never becomes healthy. By setting initialDelaySeconds to 120 or adding a startup probe with a longer period, the container can finish starting before liveness checks begin.

Why this answer

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.

Exam trap

The trap here is that candidates often focus on the probe path or failure threshold, but the real issue is that initialDelaySeconds is set too low for a slow-starting container, causing premature restarts.

How to eliminate wrong answers

Option A is wrong because increasing failureThreshold would only delay the inevitable restart by a few more cycles; the core issue is that the probe starts too early, not that it gives up too quickly. Option B is wrong because the path '/healthz' is a common and valid endpoint for liveness checks; the problem is timing, not the endpoint name. Option C is wrong because a readiness probe would not prevent the container from being restarted; liveness probes are responsible for restarting unhealthy containers, and readiness probes only control traffic routing.

Practice this question →
26
MCQmedium

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?

A.Delete and recreate the pod to clear the crash loop
B.Increase the memory limit in the pod's container resource specification
C.Increase the CPU request for the container
D.Delete the namespace and redeploy all workloads
AnswerB

Increasing the memory limit in the container's resource specification directly addresses the root cause of this CrashLoopBackOff: the kernel's out-of-memory killer is terminating the container because its memory usage exceeds the cgroup memory limit. By raising the limit to a value above the container's observed steady-state memory footprint, the OOM kill no longer triggers, assuming the node has enough allocatable memory to grant the new limit. This is the correct remediation because the container is not being killed for CPU or scheduling reasons—it is strictly a memory limit violation.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. The most appropriate action is to increase the memory limit in the pod's container resource specification, as this directly addresses the root cause—insufficient memory allocation—without requiring a full redeployment or affecting other workloads.

Exam trap

The CKAD exam often tests the distinction between memory and CPU resources, and the trap here is that candidates may confuse OOMKilled (a memory issue) with a CPU throttling or resource starvation problem, leading them to incorrectly adjust CPU settings instead of memory limits.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod would only restart the same container with the same memory limit, leading to an immediate repeat of the OOMKilled crash. Option C is wrong because increasing the CPU request does not affect memory constraints; OOMKilled is a memory issue, not a CPU issue. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that would disrupt all services in the namespace and does not solve the specific memory limit problem for this pod.

Practice this question →
27
MCQhard

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?

A.Readiness probe
B.No probe is needed; pods are automatically added when running
C.Startup probe
D.Liveness probe
AnswerA

Readiness probe is the only mechanism that determines whether a pod should receive traffic from a Service. When the probe fails, the kubelet sets the pod's Ready condition to false, and the EndpointSlice controller removes that pod's IP from the Service's endpoints. For a Deployment with 3 replicas, this ensures only fully initialized and healthy-app-ready pods are behind the Service, preventing connection errors during startup or temporary stalls.

Why this answer

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.

Exam trap

The trap here is that candidates confuse Liveness probes (which restart pods) with Readiness probes (which control traffic routing), or assume that a running pod is automatically considered ready for Service endpoints.

How to eliminate wrong answers

Option B is wrong because Kubernetes does not automatically add pods to Service endpoints when they are running; it only adds pods that pass their Readiness probe. Option C is wrong because a Startup probe is used to determine when an application has started, not when it is ready to serve traffic; it delays the start of Liveness and Readiness probes but does not control Service endpoint membership. Option D is wrong because a Liveness probe is used to determine if a pod should be restarted, not to control traffic routing; it does not affect whether a pod is added to a Service's endpoints.

Practice this question →
28
MCQmedium

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?

A.Delete the namespace and redeploy all workloads
B.Delete and recreate the pod to clear the crash loop
C.Increase the CPU request for the container
D.Increase the memory limit in the pod's container resource specification
AnswerD

The OOMKilled status means the container's memory usage exceeded the limit specified in resources.limits.memory. Raising this limit in the pod's container resource specification gives the process more headroom under the cgroup, allowing it to run without being killed by the kernel. This directly resolves the cause of the crash loop, provided the node has sufficient allocatable memory.

Why this answer

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.

Exam trap

The trap here is that candidates confuse CPU and memory resource constraints, thinking increasing CPU requests will solve an OOM issue, or they assume a simple pod restart is sufficient without addressing the underlying resource limit.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not address the root cause (memory exhaustion) and would cause unnecessary downtime. Option B is wrong because deleting and recreating the pod will only restart it with the same memory limit, leading to the same OOMKilled crash loop. Option C is wrong because increasing the CPU request does not affect memory allocation; the OOM killer is triggered by memory usage exceeding the limit, not CPU.

Practice this question →
29
MCQeasy

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

A.kubectl logs --since=5m web-pod
B.kubectl logs --tail=100 web-pod
C.kubectl logs -f web-pod
D.kubectl logs web-pod
AnswerC

The -f flag streams logs in real-time.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse flags like `--tail` or `--since` with real-time streaming, not realizing that only `-f` (or `--follow`) provides continuous log output.

How to eliminate wrong answers

Option A is wrong because `--since=5m` retrieves logs from the last 5 minutes but does not stream them; it prints the logs and exits. Option B is wrong because `--tail=100` shows only the last 100 lines of logs and then exits, without following new output. Option D is wrong because `kubectl logs web-pod` prints all available logs from the pod and exits, providing no real-time streaming capability.

Practice this question →
30
MCQhard

Based on the exhibit, why is the container being killed and restarted?

A.The readiness probe is failing, causing the pod to be considered not ready and restarted.
B.The liveness probe is failing, causing the container to be restarted.
C.The container is running out of memory (OOM).
D.The container image is being pulled repeatedly.
AnswerB

The liveness probe is the probe that determines whether the application inside the container is healthy; if it fails, the kubelet kills the container and restarts it according to the pod's restartPolicy. The exhibit shows a restart counter increasing while the container's status cycles through Running, then terminated, then Running again, which exactly matches the behavior of a failing liveness probe. A liveness probe failure would cause the kubelet to record the reason as "Liveness probe failed: <message>" in the pod events, leading to the automatic restart observed in the exhibit.

Why this answer

In Kubernetes, a failing liveness probe causes the kubelet to restart the container. The exhibit shows the container being killed and restarted, which is consistent with liveness probe failure. Option A is incorrect because a failing readiness probe does not restart the container; it only marks the pod as not ready and removes it from service endpoints.

Option C is incorrect: OOM would result in a different error message (OOMKilled). Option D is incorrect: repeated image pulls would cause ImagePullBackOff, not a restart after running.

Exam trap

A common pitfall is forgetting that readiness probes do not restart containers; only liveness probes do. The restart policy (e.g., Always) acts on liveness failures.

How to eliminate wrong answers

Option B is wrong because a failing liveness probe directly causes the container to be restarted by the kubelet, but the exhibit indicates the container is being killed and restarted due to a readiness probe failure, not a liveness probe failure. Option C is wrong because an OOM kill would result in a `CrashLoopBackOff` state with an `OOMKilled` reason in the pod status, not a readiness probe failure. Option D is wrong because repeated image pulls would cause `ErrImagePull` or `ImagePullBackOff` errors, not a readiness probe failure leading to container restarts.

Practice this question →
31
MCQhard

You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?

A.The liveness probe is misconfigured and should use a TCP check instead.
B.The memory limit is set too low; the container is being OOMKilled during traffic spikes.
C.The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.
D.The CPU limit is too low, causing the container to be throttled and timeout.
AnswerB

The container's memory limit is 256Mi, yet during traffic spikes memory reaches roughly 250Mi plus cache overhead, which pushes usage over the cgroup limit. When that limit is breached, the kernel OOM killer terminates the container, and restartPolicy causes the observed restarts. The liveness probe is not involved because the kernel acts independently of any probe status.

Why this answer

The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.

Exam trap

The trap here is that candidates often confuse CPU throttling (which causes slowness and timeouts) with OOM kills (which cause restarts), and they may overlook that memory limits are a hard cap enforced by the kernel, while CPU limits are a soft cap enforced by the scheduler.

How to eliminate wrong answers

Option A is wrong because the liveness probe is already an HTTP GET check, which is appropriate for an application that exposes an HTTP endpoint; switching to a TCP check would not prevent OOM kills and would only verify the port is open, not application health. Option C is wrong because the readiness probe failing would prevent traffic from being sent to the Pod, but the Pod would not be restarted; restarts are caused by liveness probe failures or OOM kills, not readiness probe failures. Option D is wrong because CPU throttling (due to low CPU limits) causes performance degradation and timeouts, not container restarts; the kernel does not kill containers for exceeding CPU limits—it only throttles them.

Practice this question →
32
MCQhard

You have a Deployment with a liveness probe that fails intermittently, causing the pod to restart. You want to reduce the sensitivity of the probe so that it only restarts after 3 consecutive failures. Which probe parameter should you adjust?

A.initialDelaySeconds
B.periodSeconds
C.failureThreshold
D.successThreshold
AnswerC

failureThreshold is the correct parameter to adjust because it specifies the number of consecutive liveness probe failures the kubelet must observe before restarting the container. By increasing this value from its default (often 1 for liveness) to 3, you require multiple failed probes in a row, making the restart decision less sensitive to transient errors. This directly addresses the problem of a probe that fails intermittently without causing immediate container restarts.

Why this answer

The `failureThreshold` parameter defines the number of consecutive probe failures required before Kubernetes considers the probe to have failed and triggers the configured action (e.g., restarting the container). By default, this value is 3, but if it is set lower (e.g., 1), a single failure causes a restart. Increasing `failureThreshold` to 3 (or higher) ensures that the liveness probe only restarts the pod after three consecutive failures, thereby reducing sensitivity to transient issues.

Exam trap

The trap here is that candidates often confuse `failureThreshold` with `periodSeconds`, thinking that reducing the probe frequency (period) will reduce sensitivity, but the correct way to require multiple consecutive failures is to increase the `failureThreshold` value.

How to eliminate wrong answers

Option A is wrong because `initialDelaySeconds` controls how long to wait after the container starts before initiating the first probe; it does not affect the number of consecutive failures required to trigger a restart. Option B is wrong because `periodSeconds` sets the frequency (in seconds) at which the probe is executed; adjusting it changes how often checks occur, not how many failures are needed. Option D is wrong because `successThreshold` defines the number of consecutive successes required for the probe to be considered successful after a failure; it is relevant for startup and readiness probes but not for liveness probes (where it is always 1 and cannot be changed).

Practice this question →
33
MCQeasy

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

A.kubectl logs --stream pod-name
B.kubectl logs -f pod-name
C.kubectl logs --previous pod-name
D.kubectl logs pod-name
AnswerB

The -f flag follows log output in real-time.

Why this answer

`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.

Exam trap

CNCF often tests the `-f` flag against the non-existent `--stream` flag, exploiting the candidate's assumption that a verbose flag name exists when the actual flag is a short form.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` does not have a `--stream` flag; the correct flag for real-time streaming is `-f` (or `--follow`). Option C is wrong because `--previous` shows logs from the previous instance of a container (e.g., after a restart), not real-time streaming. Option D is wrong because `kubectl logs pod-name` without any flag only displays the current log snapshot and exits, it does not stream new log entries.

Practice this question →
34
MCQmedium

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?

A.Delete the namespace and redeploy all workloads
B.Delete and recreate the pod to clear the crash loop
C.Increase the CPU request for the container
D.Increase the memory limit in the pod's container resource specification
AnswerD

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse 'OOMKilled' with a general crash and think restarting the pod (Option B) will fix it, but the OOM killer will immediately terminate the new container again because the memory limit remains unchanged.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that does not address the root cause (insufficient memory limit) and would cause unnecessary downtime. Option B is wrong because deleting and recreating the pod will only temporarily restart the container; it will still hit the same memory limit and crash again, resulting in the same CrashLoopBackOff state. Option C is wrong because increasing the CPU request does not affect memory constraints; OOMKilled is a memory-related issue, not CPU-related.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Ckad Observability questions.

Start 20-question session