CCNA Application Observability and Maintenance Questions — Page 2 of 2

Multi-Selecthard

Which THREE are valid types of probes in Kubernetes?

Select 3 answers

A.Startup probe

B.Readiness probe

C.Liveness probe

D.Survival probe

E.Health probe

AnswersA, B, C

The startup probe is the first probe executed for a container and is designed for applications that require a longer initialization time, such as Java applications or those loading large caches. It runs to completion, and once it succeeds, the kubelet switches to the liveness and readiness probes, allowing the container to be considered ready without being prematurely killed. This prevents the liveness probe from restarting a container that is still starting up.

Why this answer

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.

Exam trap

CNCF often tests the distinction between the three official probe types (liveness, readiness, startup) and common but incorrect terms like 'survival' or 'health', which candidates might confuse due to similar-sounding names or general cloud concepts.

Practice this question →

MCQmedium

A pod has a readiness probe configured with httpGet on port 8080. The probe is failing, but the pod is running. What is the immediate effect on the pod?

A.The pod will be removed from the Service's endpoints and will stop receiving traffic

B.The pod will be restarted

C.The pod will be evicted from the node

D.The pod will be deleted

AnswerA

When a readiness probe configured via httpGet fails consecutively beyond the failureThreshold, the kubelet marks the pod's Ready condition as False. The Kubernetes endpoints controller then removes the pod's IP address from all matching Endpoints and EndpointSlices, so kube-proxy no longer forwards Service traffic to it. The pod stays running and can be re-added once the probe succeeds again.

Why this answer

A readiness probe that fails means Kubernetes considers the pod not ready to serve traffic. The pod itself continues running, but the kubelet removes its IP from all matching Service endpoints, so it stops receiving new requests. This is the immediate effect because readiness probes only control traffic routing, not pod lifecycle.

Exam trap

The trap here is confusing readiness probes with liveness probes: candidates often think a failing probe restarts the pod, but readiness probes only affect traffic routing, not pod lifecycle.

How to eliminate wrong answers

Option B is wrong because a failing readiness probe does not trigger a restart; only a failing liveness probe would cause the kubelet to restart the pod. Option C is wrong because pod eviction is triggered by node resource pressure or taints, not by a readiness probe failure. Option D is wrong because the pod is not deleted; it remains running and can become ready again if the probe starts succeeding.

Practice this question →

MCQeasy

Which kubectl command can you use to stream the logs from a pod in real-time?

A.kubectl logs --previous

B.kubectl logs

C.kubectl logs -f

D.kubectl logs --tail=10

AnswerC

kubectl logs -f (the --follow flag) opens a live, continuous stream of logs from the container, sending each new log line to your terminal in real time. It keeps the connection open until you interrupt it (e.g., with Ctrl+C), making it the standard way to watch application logs as they are generated.

Why this answer

The `-f` flag (short for `--follow`) in `kubectl logs` streams the log output in real-time, similar to `tail -f` on a Linux system. This allows you to observe new log entries as they are written by the pod's containers, which is essential for debugging live issues or monitoring application behavior.

Exam trap

The trap here is that candidates often confuse `--previous` (which shows logs from a terminated container) with a streaming option, or assume that the basic `kubectl logs` command automatically streams output, when in fact it requires the explicit `-f` or `--follow` flag.

How to eliminate wrong answers

Option A is wrong because `kubectl logs --previous` retrieves logs from the previous instance of a container (e.g., after a restart), but it does not stream logs in real-time; it outputs the logs and exits. Option B is wrong because `kubectl logs` without any flags prints the current logs and then terminates, providing a snapshot rather than a live stream. Option D is wrong because `kubectl logs --tail=10` limits the output to the last 10 lines of the log, but like the basic command, it does not follow or stream new log entries.

Practice this question →

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 →

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 →

Multi-Selectmedium

Which TWO of the following are valid parameters for configuring probes in Kubernetes? (Select TWO.)

Select 2 answers

A.intervalSeconds

B.initialDelaySeconds

C.retryCount

D.failureThreshold

E.readinessProbe

AnswersB, D

`initialDelaySeconds` is a valid probe parameter that specifies how long the kubelet should wait after the container starts before performing the first probe. This delay gives the application time to initialize and become ready to respond, preventing premature failures that would disrupt startup. It is particularly important for containers with long initialization times.

Why this answer

`initialDelaySeconds` is a valid field in a Kubernetes probe configuration (liveness, readiness, or startup probe). It specifies the number of seconds to wait after the container starts before initiating the first probe, allowing the application to initialize before being checked.

Exam trap

The trap here is that candidates confuse the naming convention of probe parameters (e.g., `intervalSeconds` vs `periodSeconds`, `retryCount` vs `failureThreshold`) or mistake a top-level probe field like `readinessProbe` for a parameter within the probe configuration.

Practice this question →

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 →

MCQhard

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?

A.The service is configured to use a different port

B.The pod's node is cordoned

C.The liveness probe is failing and restarting the container

D.The readiness probe is succeeding even though the application is not truly ready, because TCP check only verifies the port is open

AnswerD

A TCP readiness probe only opens a raw socket connection to the specified port; it reports success if the TCP handshake completes, regardless of what the application does after that. For a web application, the server process may accept the connection and even return a 503 or a placeholder page while still initializing, causing the probe to pass prematurely. This makes the probe an insufficient indicator of true readiness; the pod is added to the Service's endpoints even though it cannot serve valid HTTP responses. Therefore the correct fix is to use an HTTP or exec probe that validates the application's own health endpoint.

Why this answer

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.

Exam trap

The trap here is that candidates assume a successful TCP socket check on the correct port guarantees the application is ready to serve traffic, overlooking that TCP only verifies the port is open, not that the application logic is functional.

How to eliminate wrong answers

Option A is wrong because if the Service used a different port, no pod would receive traffic, not just one pod. Option B is wrong because a cordoned node prevents new pods from being scheduled, but existing pods continue running and receiving traffic; the pod is already running, so cordoning would not affect its traffic reception. Option C is wrong because the liveness probe is passing (as stated), so the container is not being restarted; a failing liveness probe would cause restarts, but the pod shows 'Running' and passes its liveness probe.

Practice this question →

MCQhard

You are a platform engineer for a large e-commerce site. The application is deployed on a Kubernetes cluster with 10 worker nodes. Recently, a new deployment 'checkout' was rolled out, and soon after, the cluster experienced network latency and intermittent connectivity issues between services. The 'checkout' pods are configured with a liveness probe that makes an HTTP request to an internal health endpoint. Upon investigation, you find that the kubelet on several nodes is consuming high CPU, and the number of iptables rules has increased significantly. You suspect that the 'checkout' deployment's configuration is causing excessive churn in the network rules. Which aspect of the deployment configuration is most likely the root cause?

A.The liveness probe is configured with a very short periodSeconds (e.g., 1) and a low failureThreshold.

B.The liveness probe uses a TCP socket check instead of an HTTP GET.

C.The deployment sets resource requests and limits that are too low, causing pod throttling.

D.The deployment uses a large number of environment variables, causing slow container startup.

AnswerA

With periodSeconds set to 1 and failureThreshold to 1, the kubelet probes the container every second and restarts it after a single failure. This aggressive schedule causes rapid crash/restart cycles; each restart transitions the pod through NotReady and Ready states, toggling its membership in the Service endpoints. Every toggle notifies kube-proxy to recalculate and update the corresponding iptables DNAT/load-balancing rules, and in a large cluster this endpoint flapping produces substantial iptables churn on all nodes routing to that Service.

Why this answer

A liveness probe with a very short `periodSeconds` (e.g., 1) and a low `failureThreshold` causes the kubelet to send HTTP requests to the health endpoint at a high frequency. Each probe failure triggers a pod restart, which in turn causes the kubelet to update iptables rules (e.g., for kube-proxy and network policies) to reflect the new pod IP. This rapid churn of pod restarts leads to a significant increase in iptables rules and high CPU consumption on the kubelet, as it must repeatedly reconcile the network state.

Exam trap

The trap here is that candidates may focus on the probe type (HTTP vs. TCP) or resource limits, but the root cause is the probe frequency and failure threshold causing rapid pod restarts and iptables churn, not the probe mechanism itself.

How to eliminate wrong answers

Option B is wrong because a TCP socket check does not inherently cause more iptables churn than an HTTP GET; both probe types trigger restarts on failure, and the frequency of restarts is determined by `periodSeconds` and `failureThreshold`, not the probe protocol. Option C is wrong because low resource requests/limits cause pod throttling or OOM kills, which could lead to restarts, but the question specifically points to excessive iptables rule churn from the deployment configuration, not resource starvation. Option D is wrong because a large number of environment variables slows container startup but does not directly cause iptables rule churn or kubelet CPU spikes; environment variables are set once at pod creation and do not affect network rule updates.

Practice this question →

MCQhard

You need to configure a liveness probe for a container that listens on TCP port 8080. The probe should wait 5 seconds before starting, check every 10 seconds, and timeout after 2 seconds. Which YAML snippet correctly configures this?

A.livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 2

B.livenessProbe: exec: command: - echo - ok initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 2

C.livenessProbe: tcpSocket: port: 8080 initialDelay: 5 period: 10 timeout: 2

D.livenessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 2

AnswerA

This liveness probe is correct because it uses the tcpSocket handler to check that the container's port 8080 accepts a TCP connection, which is exactly the requirement. The initialDelaySeconds of 5 gives the container time to start before the first probe, periodSeconds of 10 runs the check every 10 seconds, and timeoutSeconds of 2 ensures a stalled connection is treated as a failure. The kubelet will restart the container if the connection fails after the timeout.

Why this answer

It uses the `tcpSocket` probe type to check TCP port 8080, which is appropriate for a container that listens on TCP. The fields `initialDelaySeconds: 5`, `periodSeconds: 10`, and `timeoutSeconds: 2` match the required timing parameters exactly as specified in the Kubernetes API.

Exam trap

The trap here is that candidates often confuse the probe types (tcpSocket vs. httpGet vs. exec) and may pick an httpGet probe (option D) because it is more common, or use incorrect field names (option C) due to familiarity with other orchestrators like Docker Compose.

How to eliminate wrong answers

Option B is wrong because it uses an `exec` probe with an `echo ok` command, which checks process health via command execution rather than a TCP socket check on port 8080. Option C is wrong because it uses incorrect field names `initialDelay`, `period`, and `timeout`; Kubernetes requires the `Seconds` suffix for these fields (e.g., `initialDelaySeconds`). Option D is wrong because it uses an `httpGet` probe, which performs an HTTP GET request on port 8080, not a TCP socket check; this would fail if the container only listens on TCP without an HTTP server.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid ways to debug a pod that is not responding? (Select three.)

Select 3 answers

A.Run 'kubectl debug -it pod-name --image=busybox --target=container-name' to start an ephemeral debug container

B.Run 'kubectl exec -it pod-name -- /bin/bash' to interact with the container

C.Run 'kubectl logs pod-name --tail=50' to view recent log output

D.Run 'kubectl attach pod-name' to attach to the container's main process

E.Run 'kubectl get pod pod-name -o yaml' to examine the pod's current YAML definition

AnswersA, B, C

kubectl debug creates an ephemeral container inside the running pod, injecting a fresh image (busybox) without restarting or altering the original containers; --target ties the new container's process namespace to the specified application container so you can inspect and signal real processes. This is ideal when the app image lacks a shell, a debugger, or curl, and it leaves the pod's original spec untouched, making it a non-invasive yet powerful debugging approach.

Why this answer

`kubectl debug` with `--target=container-name` creates an ephemeral container in the same pod, sharing the network and process namespace (if supported) with the target container. This allows you to run debugging tools (e.g., `busybox`) without modifying the original container image, which is essential when the container lacks a shell or necessary utilities.

Exam trap

The CKAD exam often tests the distinction between `kubectl attach` (which connects to the main process) and `kubectl exec` (which spawns a new process), leading candidates to mistakenly think attach is useful for interactive debugging when the container is unresponsive.

Practice this question →

MCQmedium

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?

A.Resource quota exceeded

B.Readiness probe failure

C.Startup probe failure

D.Liveness probe failure

AnswerD

Liveness probes are the kubelet's health check for container liveness; if a liveness probe fails, the kubelet kills the container and restarts it according to the pod's restartPolicy (default is Always). This is the standard self-healing mechanism designed to recover from deadlocks, unbounded memory leaks, or hung processes. When a developer sees a pod restart, the most common cause is an unhealthy container being restarted by a failed liveness probe. The event for this would be 'Liveness probe failed' with a subsequent container recreate.

Why this answer

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.

Exam trap

The trap here is that candidates confuse readiness probe failures (which only affect traffic) with liveness probe failures (which cause restarts), leading them to pick Option B when the BackOff event clearly indicates container restarts.

How to eliminate wrong answers

Option A is wrong because a resource quota exceeded would cause the pod to be in a 'Pending' state or fail to schedule, not produce BackOff events from a running container. Option B is wrong because a readiness probe failure only removes the pod from service endpoints; it does not cause container restarts or BackOff events. Option C is wrong because a startup probe failure prevents liveness and readiness probes from starting, but the container is not restarted—the pod would remain in a 'NotReady' state without triggering BackOff restarts.

Practice this question →

MCQhard

A pod is stuck in the Pending state. You run 'kubectl describe pod pod-name' and see the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 nodes had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.' What is the MOST likely cause?

A.The nodes have disk pressure and the pod lacks tolerations

B.The pod has a resource request that exceeds node capacity

C.The nodes have insufficient CPU

D.The nodes have insufficient memory

AnswerA

The `kubectl describe` output would show an event indicating that each node has a taint such as `node.kubernetes.io/disk-pressure`. Because the pod defines no tolerations for that taint, the scheduler filters out those nodes, leaving the pod Pending. Disk pressure is a node condition that the kubelet automatically encodes as a taint, and pods must explicitly tolerate it to be scheduled. This matches the event description exactly, unlike resource-based failures.

Why this answer

The event explicitly states that 1 node had a control-plane taint and 3 nodes had a disk-pressure taint, all of which the pod did not tolerate. The pod remains in Pending state because no node can schedule it until either the taints are removed or the pod includes matching tolerations. This directly matches the condition described in the event.

Exam trap

The trap here is that candidates often confuse taint-based scheduling failures with resource insufficiency (CPU/memory) and select options B, C, or D, even though the event explicitly names taints as the cause.

How to eliminate wrong answers

Option B is wrong because the event does not mention any resource request or capacity issues; it only lists taints as the reason for scheduling failure. Option C is wrong because insufficient CPU would appear as a different event, such as 'Insufficient cpu' in the node conditions, not as a taint-based message. Option D is wrong because insufficient memory would similarly produce an 'Insufficient memory' event, not a taint-related message.

Practice this question →

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

Readiness probes determine pod readiness; failing pods are removed from Service endpoint slices, so kube-proxy stops forwarding traffic to them. This directly satisfies the stem's requirement to control whether the pod receives traffic from Services, unlike liveness probes which restart containers.

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 →

Multi-Selectmedium

Which THREE of the following are valid types of probes in Kubernetes? (Select 3)

Select 3 answers

A.Liveness probe

B.Survival probe

C.Readiness probe

D.Health probe

E.Startup probe

AnswersA, C, E

Liveness probe is a standard Kubernetes probe type that checks the health of a running container and restarts it if the probe fails. It helps recover from deadlocks or stuck processes where the container is still running but no longer functioning correctly. When a liveness probe fails, the kubelet kills the container and replaces it according to the pod's restart policy, enabling self-healing applications.

Why this answer

Liveness, Readiness, and Startup probes are all valid probe types in Kubernetes. Liveness probes check if a container is still running and can restart it if needed. Readiness probes determine if a container is ready to serve traffic.

Startup probes delay liveness and readiness checks until the container has started successfully. Options B (Survival) and D (Health) are not valid Kubernetes probe types.

Exam trap

The CKAD exam expects you to know that there are three valid probe types: Liveness, Readiness, and Startup. This question asks for three, so all three correct options must be selected.

Practice this question →

MCQmedium

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?

A.Set liveness probe failureThreshold to a high number

B.Set readiness probe initialDelaySeconds to 60

C.Set liveness probe initialDelaySeconds to 60

D.Configure a startup probe with a sufficient failureThreshold and period

AnswerD

This is the correct approach because a startup probe gives the kubelet an explicit phase for container initialization. While the startup probe is failing, liveness and readiness probes are not executed at all; only after the startup probe succeeds do the steady-state probes take over. By configuring a sufficient failureThreshold and periodSeconds, you define the maximum startup window (failureThreshold * periodSeconds) during which the container is allowed to initialize without being killed. This is the canonical pattern for slow-starting containers, as it avoids guessing an exact initialDelaySeconds and automatically adapts to the container's actual startup behavior, then hands off to normal liveness checking.

Why this answer

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.

Exam trap

The trap here is that candidates confuse the purpose of initialDelaySeconds (which only delays the first probe) with the need for a startup probe, which completely suppresses liveness checks until the container is confirmed to have started.

How to eliminate wrong answers

Option A is wrong because increasing the liveness probe failureThreshold only delays the inevitable; the probe still starts immediately and will fail repeatedly, potentially causing restarts or unnecessary resource consumption. Option B is wrong because readiness probe initialDelaySeconds only affects when the container is considered ready to serve traffic; it does not prevent the liveness probe from interfering during startup. Option C is wrong because setting liveness probe initialDelaySeconds to 60 still leaves a gap: if the container takes exactly 60 seconds, the first probe may fail and cause a restart before the container is fully ready.

Practice this question →

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 →

MCQmedium

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

A.kubectl edit pod app

B.kubectl get pod app -o yaml

C.kubectl get pod app -o yaml --export

D.kubectl get pod app -o json

AnswerB

kubectl get pod app -o yaml is correct because it directly retrieves the live Pod object from the Kubernetes API server and serializes it into YAML, printing the full definition to stdout. This output includes the complete metadata, spec, status, and other fields such as resourceVersion and managedFields, giving you the exact current state of the Pod as known by the cluster. It is the canonical read-only command for viewing a resource's YAML manifest, and unlike editing, it does not require interaction or risk unintended modifications.

Why this answer

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

Exam trap

The trap here is that candidates may confuse `kubectl get pod -o yaml` with `kubectl describe pod`, which provides a human-readable summary but not the raw YAML definition, or they may mistakenly choose `--export` thinking it cleans up the output, not realizing it removes the very status information the question requires.

How to eliminate wrong answers

Option A is wrong because `kubectl edit pod app` opens the pod's specification in an editor for modification; while it shows the current state, its primary purpose is editing, not just viewing, and it may inadvertently change the object if saved. Option C is wrong because `--export` is a deprecated flag that strips cluster-specific fields like `status`, `nodeName`, and `uid`, which contradicts the requirement to include the current status. Option D is wrong because `-o json` outputs the pod definition in JSON format, not YAML, so it does not satisfy the explicit request for YAML output.

Practice this question →

MCQmedium

You need to run a command inside a running pod's container. The container has a shell available. Which command allows you to execute 'ls -la /data' inside the container?

A.kubectl exec pod-name

B.kubectl run pod-name -- ls -la /data

C.kubectl exec pod-name -- ls -la /data

D.kubectl attach pod-name -c container-name

AnswerC

The command `kubectl exec pod-name -- ls -la /data` is correct because it instructs kubectl to run the `ls -la /data` process inside the first container of the existing pod `pod-name`. The `--` separates kubectl's local flags from the remote command to be executed, ensuring that arguments like `-la` are passed to `ls` rather than being interpreted by kubectl. This is the canonical method for executing ad-hoc commands in a running pod's container.

Why this answer

The `kubectl exec` command is designed to execute arbitrary commands inside a running container. The `--` separator tells kubectl that everything after it is the command to run inside the container, not a kubectl flag. Option C correctly uses `kubectl exec pod-name -- ls -la /data` to run `ls -la /data` inside the specified pod's primary container.

Exam trap

The trap here is confusing `kubectl exec` (which runs a command inside an existing container) with `kubectl run` (which creates a new pod), leading candidates to pick Option B, which would create a new pod instead of executing in the running one.

How to eliminate wrong answers

Option A is wrong because `kubectl exec pod-name` without a command after `--` will open an interactive shell (if available) or fail, but it does not execute `ls -la /data`. Option B is wrong because `kubectl run` creates a new pod from an image, not executes a command inside an existing running pod; it would launch a new pod and run `ls -la /data` in that new pod, not the target pod. Option D is wrong because `kubectl attach` attaches to a running container's main process (stdin/stdout/stderr), not to execute a new command; it does not support running `ls -la /data` as a separate process.

Practice this question →

MCQmedium

A pod named 'db-pod' is running but not responding as expected. You want to check its logs from the previous instantiation (after a crash). Which command should you use?

A.kubectl exec db-pod -- cat /var/log/app.log

B.kubectl logs -f db-pod

C.kubectl describe pod db-pod

D.kubectl logs db-pod --previous

AnswerD

The --previous flag instructs kubectl to fetch the log file from the last container instance that terminated, which is exactly the data you need when the current container was restarted due to a crash. This works even if the current container is now running, as long as a previous instance exists; if the pod has multiple containers, you must add -c <container-name> to target the right one.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instantiation of a container in a pod that has crashed or restarted. This allows you to inspect the logs from the terminated container before the current running instance, which is essential for debugging why the pod is not responding as expected after a crash.

Exam trap

The trap here is that candidates often confuse `kubectl logs` with `kubectl describe` or assume that `kubectl exec` into the running container can access logs from a previous crash, but the `--previous` flag is the only way to retrieve logs from a terminated container instance.

How to eliminate wrong answers

Option A is wrong because `kubectl exec db-pod -- cat /var/log/app.log` attempts to read a log file from the current running container, which may not exist or may not contain logs from the previous crashed instance; it also assumes the application writes logs to a specific file path, which is not the standard Kubernetes logging mechanism. Option B is wrong because `kubectl logs -f db-pod` streams the logs of the currently running container in real-time, but it does not show logs from the previous instantiation after a crash. Option C is wrong because `kubectl describe pod db-pod` provides metadata, events, and status of the pod, but it does not retrieve container logs, let alone logs from a previous instantiation.

Practice this question →

MCQhard

A cluster has a node that is NotReady. The kubelet on that node is not responding. Which command should be used to investigate the kubelet logs on the node?

A.kubectl logs <pod> --node=<node>

B.kubectl describe node <node>

C.kubectl get events --field-selector involvedObject.kind=Node

D.journalctl -u kubelet

AnswerD

journalctl -u kubelet is correct because on systemd-based Linux distributions, the kubelet is managed as a systemd service, and its stdout, stderr, and syslog messages are captured by the journal daemon. Running this command on the affected node retrieves the complete, timestamped log stream from that unit, revealing startup errors, connection failures, or config file issues. This is the standard method to inspect kubelet logs for diagnosing why a node is NotReady.

Why this answer

`journalctl -u kubelet` directly queries the systemd journal for logs from the kubelet service on the node. Since the kubelet is not responding, you cannot use `kubectl` to access its logs remotely; you must SSH into the node and use `journalctl` (or `systemctl status kubelet`) to read the kubelet's logs locally.

Exam trap

The trap here is that candidates assume `kubectl` can retrieve kubelet logs remotely, but `kubectl` only accesses pod/container logs via the kubelet API; when the kubelet itself is down, you must use node-level tools like `journalctl` or `systemctl`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod> --node=<node>` is not a valid syntax; `kubectl logs` retrieves logs from a specific pod container, not from the kubelet process, and the `--node` flag does not exist. Option B is wrong because `kubectl describe node <node>` shows the node's status and conditions (including NotReady) but does not provide the kubelet's logs, which are needed to diagnose why the kubelet is not responding. Option C is wrong because `kubectl get events --field-selector involvedObject.kind=Node` displays cluster events related to nodes, but these events are generated by the control plane, not by the kubelet itself, and they do not contain the detailed kubelet log output required to investigate a non-responsive kubelet.

Practice this question →

MCQmedium

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

A.kubectl describe node

B.kubectl get pvc

C.kubectl get storageclass

D.kubectl describe pod <pod>

AnswerD

kubectl describe pod <pod> displays the pod's full status, including the volume list, associated PVCs, container states, and crucially the Events section at the bottom. If the pod is stuck in ContainerCreating, the kubelet emits a FailedMount event with a message such as "unable to find storage class" or "no persistent volumes available for this claim," which directly identifies the missing storage class. This event is the authoritative source for the reason the pod cannot start, and the output also shows current conditions and volume definitions for a complete diagnostic picture.

Why this answer

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

Exam trap

The trap here is that candidates assume checking the StorageClass list (`kubectl get storageclass`) or PVC status (`kubectl get pvc`) will reveal the missing class, but only the pod's detailed description shows the specific provisioning failure event tied to the missing StorageClass.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node` shows node-level conditions, capacity, and resource usage, but does not reveal pod-level storage provisioning errors or missing storage class details. Option B is wrong because `kubectl get pvc` lists PersistentVolumeClaims and their status (e.g., Pending), but does not show the underlying error message about a missing storage class; a PVC might be stuck in Pending for other reasons like insufficient PV capacity. Option C is wrong because `kubectl get storageclass` only lists available storage classes in the cluster, but does not indicate which storage class a specific pod or PVC is trying to use, nor does it show the failure event.

Practice this question →

MCQmedium

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

A.kubectl get pod monitored-pod -o wide

B.kubectl describe pod monitored-pod

C.kubectl top pod monitored-pod

D.kubectl logs monitored-pod

AnswerC

`kubectl top pod` is the only command here that talks to the Kubernetes Metrics API, which the Metrics Server populates by scraping kubelet's cAdvisor endpoint. It prints the actual instantaneous CPU and memory utilization per container, e.g., `100m` and `120Mi`, giving you a direct view of live usage. That exactly matches the task of checking the pod's CPU and memory usage.

Why this answer

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

Exam trap

The trap here is that candidates may confuse `kubectl describe` or `kubectl get -o wide` as sources of live resource usage, when in fact they only show static resource requests/limits or network info, not dynamic CPU/memory consumption.

How to eliminate wrong answers

Option A is wrong because `kubectl get pod -o wide` shows additional networking details like node IP and pod IP, but does not include CPU or memory usage metrics. Option B is wrong because `kubectl describe pod` provides detailed metadata, events, and container resource requests/limits, but not live CPU and memory usage. Option D is wrong because `kubectl logs` retrieves container log output (stdout/stderr), not resource utilization data.

Practice this question →

MCQeasy

A deployment is configured with a liveness probe that checks an HTTP endpoint. The probe fails intermittently, causing pod restarts. What is the best first step to diagnose the issue?

A.Check the liveness probe events via 'kubectl describe pod' to see the exact probe responses.

B.Run 'kubectl exec' to curl the endpoint from another pod to test network connectivity.

C.Review the liveness probe parameters in the deployment YAML and increase the failureThreshold.

D.Examine the container logs via 'kubectl logs' for error messages around the time of the failures.

AnswerD

Container logs are the most direct source of information about what the application was doing when the liveness probe failed, because the application often writes an error, panic, or timeout message immediately before it becomes unresponsive. Use `kubectl logs <pod>` to view the current logs, and `kubectl logs <pod> --previous=true` if the container has been restarted, to find logs from the failed run. Correlating log timestamps with probe failure events from `kubectl describe` lets you pinpoint the exact code path or dependency failure causing the probe to fail.

Why this answer

Container logs provide the application's perspective on why the HTTP endpoint is failing intermittently. The liveness probe failure is a symptom; the root cause (e.g., a transient error, resource exhaustion, or a bug) is most directly visible in the application's own log output around the failure timestamps. This aligns with the CKAD domain of Application Observability and Maintenance, where logs are the primary diagnostic tool for application-level issues.

Exam trap

The trap here is that candidates assume the liveness probe failure is a network or configuration issue (options A, B, C) rather than recognizing that intermittent failures are almost always an application-level problem best diagnosed via container logs.

How to eliminate wrong answers

Option A is wrong because 'kubectl describe pod' shows probe events (e.g., 'Liveness probe failed: HTTP probe failed with statuscode: 503') but only reports the failure itself, not the application's internal state or the reason for the failure. Option B is wrong because testing network connectivity from another pod (e.g., via 'kubectl exec' and curl) checks network-level reachability, but the probe is failing intermittently, not due to a network partition; the issue is likely application-level. Option C is wrong because increasing failureThreshold only masks the symptom by allowing more failures before restart, without diagnosing or fixing the underlying intermittent problem.

Practice this question →

100

MCQmedium

A pod with a liveness probe using 'httpGet' is restarting repeatedly. The probe checks '/healthz' on port 8080. The application is healthy and responds with HTTP 200. What is the most likely cause?

A.The initialDelaySeconds is too high

B.The timeoutSeconds value is too low

C.The liveness probe is checking the wrong port

D.The readiness probe is misconfigured

AnswerB

When timeoutSeconds is set too low, the kubelet gives the HTTP GET request insufficient time to receive a response. If the application's health endpoint occasionally takes longer than the timeout, the probe is marked failed, and after exceeding failureThreshold the container is restarted. This matches the observed behavior of a container that restarts repeatedly even though the app itself is functional, making this the correct explanation.

Why this answer

The liveness probe is restarting the pod despite the application returning HTTP 200 on /healthz. A timeoutSeconds value that is too low can cause the probe to fail if the application takes longer than the timeout to respond, even though it is healthy. Kubernetes will restart the container when the probe fails, leading to repeated restarts.

Exam trap

The trap here is that candidates assume a healthy application always responds instantly, but Kubernetes probes have strict timeouts; a low timeoutSeconds can cause restarts even when the app is functioning correctly.

How to eliminate wrong answers

Option A is wrong because a high initialDelaySeconds delays the start of probing but does not cause repeated restarts once the probe begins; it would only prevent early failures. Option C is wrong because the probe is explicitly checking port 8080 and the application is healthy on that port, so the port is correct. Option D is wrong because a readiness probe misconfiguration affects traffic routing, not container restarts; liveness probes control restarts, and readiness probes do not trigger restarts.

Practice this question →

101

MCQmedium

A pod named 'web' is in a CrashLoopBackOff state. You suspect the application is failing due to a configuration error. You want to see the logs from the previous instance of the container. Which command should you use?

A.kubectl logs web

B.kubectl logs -f web

C.kubectl logs web --previous

D.kubectl describe pod web

AnswerC

kubectl logs web --previous is the correct approach because it retrieves the captured output from the last terminated container instance before the restart. When a container is in CrashLoopBackOff, the current container may crash too quickly to produce useful logs, but the previous instance's logs contain the error or stack trace that explains the failure. This flag directly targets the most recent failed container, which is the standard diagnostic step for this scenario.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container in a pod that has restarted. Since the pod is in CrashLoopBackOff, the current container has likely crashed and a new one has started; `--previous` shows the logs from the terminated container that caused the crash, helping diagnose the configuration error.

Exam trap

The trap here is that candidates assume `kubectl logs` alone shows all logs, but they forget that a crashed container's logs are only accessible with `--previous`, and they may mistakenly choose `kubectl describe pod` thinking it includes logs.

How to eliminate wrong answers

Option A is wrong because `kubectl logs web` only shows logs from the currently running container, which may be empty or unhelpful if the container has already crashed and restarted. Option B is wrong because `kubectl logs -f web` streams logs from the current container in real-time, but does not show logs from the previous terminated instance. Option D is wrong because `kubectl describe pod web` provides pod metadata, events, and status, but does not show container logs, which are needed to see the application error output.

Practice this question →

102

MCQeasy

You want to see a list of all events in the 'default' namespace, sorted by timestamp. Which command should you use?

A.kubectl describe events

B.kubectl get pods

C.kubectl get events

D.kubectl logs --all-containers

AnswerC

kubectl get events directly queries the events API and is the idiomatic way to list all events in the current namespace. It returns a sorted table (by timestamp) containing columns like LAST SEEN, TYPE, REASON, OBJECT, and MESSAGE, giving a complete but concise view of cluster activity. This is the correct answer because it gives exactly the requested information.

Why this answer

`kubectl get events` retrieves all events in the current namespace (default) and, by default, sorts them by the `lastTimestamp` field in ascending order, which is the timestamp of the event. This command directly answers the requirement to list events sorted by timestamp without additional flags.

Exam trap

The trap here is that candidates confuse `kubectl describe events` with `kubectl get events`, assuming the `describe` verb provides a sorted list, but `describe` does not sort by timestamp and may omit events due to pagination limits.

How to eliminate wrong answers

Option A is wrong because `kubectl describe events` shows detailed information about events but does not sort them by timestamp; it groups events by resource and may truncate the list. Option B is wrong because `kubectl get pods` lists pods, not events, and has no timestamp sorting relevant to events. Option D is wrong because `kubectl logs --all-containers` retrieves container logs, not events, and logs are not sorted by event timestamps.

Practice this question →

103

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 →

104

MCQeasy

Which probe type is used to determine if a container is ready to serve traffic?

A.Liveness probe

B.Readiness probe

C.Startup probe

D.Resource probe

AnswerB

A readiness probe determines whether the container is ready to accept traffic; if it fails, the pod is removed from the endpoints of all Services. This directly controls traffic routing, making it the correct probe type to determine if a container is ready to receive requests. It does not restart the container, but only influences Service endpoint membership, allowing traffic to resume when the probe succeeds again.

Why this answer

A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, the container is removed from the Service's endpoints, ensuring no requests are routed to an unready pod. This is defined in the PodSpec under `readinessProbe` and is essential for rolling updates and traffic management.

Exam trap

The trap here is that candidates confuse Liveness and Readiness probes, thinking both control traffic, but only the Readiness probe affects Service endpoints, while Liveness only triggers container restarts.

How to eliminate wrong answers

Option A is wrong because a Liveness probe checks if the container is still running (i.e., not deadlocked or crashed) and restarts it if it fails, but it does not control traffic routing. Option C is wrong because a Startup probe is used to delay Liveness and Readiness checks until the container has fully started, especially for slow-booting applications, but it does not directly determine traffic readiness. Option D is wrong because there is no standard 'Resource probe' in Kubernetes; resource management is handled via requests and limits, not probes.

Practice this question →

105

MCQhard

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?

A.The pod will be restarted by the kubelet

B.The Deployment will create a new pod to maintain 3 replicas

C.The pod will be removed from the Service endpoints

D.The pod will be terminated gracefully

AnswerC

When the readiness probe fails, the kubelet updates the pod's status to NotReady, and the EndpointSlice controller consequently removes the pod's IP address from all Services whose selectors match the pod. This decoupling of pod lifecycle from traffic routing is the primary purpose of a readiness probe. The pod remains running and part of the ReplicaSet, but until the probe begins succeeding again, it will not be listed as an endpoint and will receive no incoming requests from those Services.

Why this answer

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.

Exam trap

The trap here is confusing readiness probes with liveness probes: candidates often assume any probe failure restarts the pod, but CKAD tests the specific behavior that readiness probes only affect traffic routing, not pod lifecycle.

How to eliminate wrong answers

Option A is wrong because readiness probe failures do not trigger a restart; only liveness probe failures cause the kubelet to restart the pod. Option B is wrong because the Deployment's replica count is managed by the ReplicaSet controller based on the desired number of pods, not readiness status; a failing readiness probe does not reduce the replica count, so no new pod is created. Option D is wrong because the pod is not terminated; it continues to run but is removed from Service endpoints, and termination only occurs if a liveness probe fails or the pod is explicitly deleted.

Practice this question →

106

MCQmedium

A pod uses a liveness probe with exec command 'cat /tmp/healthy'. The file /tmp/healthy exists initially but is deleted by the application after 60 seconds. Which behavior will occur?

A.The pod will continue running because the liveness probe only checks at startup

B.The pod will be deleted and recreated by the Deployment

C.The pod will be marked as NotReady and removed from the Service

D.The liveness probe will fail and the container will be restarted

AnswerD

The liveness probe runs `cat /tmp/healthy` inside the container; if the file does not exist, the command exits non-zero, so the probe is marked failed and the kubelet kills and restarts the container according to the Pod's restartPolicy (usually Always). This restart is performed in-place by the kubelet and is exactly the designed response to a liveness probe failure.

Why this answer

The liveness probe in Kubernetes periodically checks the health of a container by executing the specified command. When the file /tmp/healthy is deleted, the 'cat /tmp/healthy' command fails (returns non-zero exit code), causing the liveness probe to fail. After consecutive failures (default threshold is 3), kubelet restarts the container to attempt recovery, which is the expected behavior for a failing liveness probe.

Exam trap

The trap here is confusing liveness probes with readiness probes: candidates often think a failing liveness probe removes the pod from the Service (which is a readiness probe behavior) or triggers a pod-level action like deletion, rather than the correct container restart by kubelet.

How to eliminate wrong answers

Option A is wrong because liveness probes are not startup-only; they run continuously at the configured interval (default 10 seconds) throughout the container's lifetime. Option B is wrong because the Deployment does not delete and recreate the pod; the kubelet restarts the container within the same pod, and the pod itself is not deleted. Option C is wrong because a failing liveness probe does not mark the pod as NotReady or remove it from the Service; that behavior is associated with readiness probes, not liveness probes.

Practice this question →

107

MCQeasy

You need to get a list of all events in the cluster sorted by timestamp. Which command should you use?

A.kubectl top events

B.kubectl describe events

C.kubectl get events --sort-by=.metadata.creationTimestamp

D.kubectl logs --events

AnswerC

This is the correct command because kubectl get is the list-oriented verb for Kubernetes resources, and its --sort-by flag accepts a JSONPath expression to order the returned objects. By specifying .metadata.creationTimestamp, all events are sorted chronologically from oldest to newest based on when they were first recorded. The command prints the events in a clean tabular format, making it easy to see the sequence of cluster activity.

Why this answer

`kubectl get events --sort-by=.metadata.creationTimestamp` retrieves all cluster events and sorts them by the creation timestamp field in the event object's metadata. This is the standard Kubernetes approach for ordering events chronologically, as events are stored in etcd and can be sorted client-side using JSONPath expressions against the resource's metadata.

Exam trap

The trap here is that candidates often confuse `kubectl get events` (which lists events) with `kubectl describe events` (which shows details but no sorting), or they assume `kubectl top` or `kubectl logs` have event-related subcommands, leading them to pick a syntactically plausible but incorrect option.

How to eliminate wrong answers

Option A is wrong because `kubectl top events` is not a valid kubectl command; `kubectl top` is used for resource usage metrics (node/pod CPU/memory), not for listing events. Option B is wrong because `kubectl describe events` displays events in a human-readable format but does not support sorting by timestamp; it shows events in an arbitrary order (typically by last seen time, not creation timestamp). Option D is wrong because `kubectl logs --events` is invalid syntax; `kubectl logs` retrieves container logs, not cluster events, and the `--events` flag does not exist for this command.

Practice this question →

108

MCQhard

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

A.The application is listening on port 8080 but not processing requests correctly.

B.The container is being throttled due to CPU limits.

C.The probe's initial delay is too short.

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

AnswerA

This is the correct answer because a TCP liveness probe only checks whether the TCP port accepts a connection; even if the application is deadlocked, hung, or failing to process requests, the kernel will still complete the handshake, and the probe will report success. In this scenario, the pod is running but not responding to requests, meaning the application has an application-level failure that is invisible to a socket-connect check. As a result, Kubernetes sees the container as healthy and does not restart it, so the unresponsive state persists indefinitely. An HTTP GET probe — which verifies an actual HTTP response with the expected status code — would catch this failure.

Why this answer

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

Exam trap

The trap here is that candidates assume a successful TCP probe means the application is healthy, but Kubernetes only checks port availability, not application responsiveness, leading to a false sense of health.

How to eliminate wrong answers

Option B is wrong because CPU throttling does not prevent a TCP port from being open; the application can still accept connections even if it is throttled, and the liveness probe would succeed. Option C is wrong because a short initial delay would cause the probe to fail early, but the question states the Pod is running and not responding to requests, implying the probe is succeeding (port is open) but the app is unresponsive. Option D is wrong because a TCP check on port 8080 is a valid liveness probe configuration; an HTTP GET probe would be more appropriate for application-level health, but the probe itself is not misconfigured—it's the application's behavior that is the issue.

Practice this question →

109

MCQmedium

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?

A.Node taints and/or affinity rules prevent scheduling

B.Container image pull failure

C.Pod is in CrashLoopBackOff

D.Insufficient CPU resources

AnswerA

Node taints and/or affinity rules prevent scheduling. In the pod's events, you would see reasons like 'Unschedulable' or '0/N nodes are available: N node(s) had untolerated taint.' Taints require matching tolerations, and node affinity/anti-affinity or nodeSelector rules constrain eligible nodes; if none satisfy all constraints, the scheduler leaves the pod Pending. This is exactly what the described message indicates.

Why this answer

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.

Exam trap

The CKAD exam often tests the distinction between scheduling failures (Pending state with Unschedulable reason) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates must read the condition message carefully to identify taint/affinity issues rather than assuming resource shortages or image problems.

How to eliminate wrong answers

Option B is wrong because container image pull failure would result in a different condition (e.g., 'ErrImagePull' or 'ImagePullBackOff') in the pod status, not an 'Unschedulable' scheduling condition. Option C is wrong because 'CrashLoopBackOff' is a container runtime state that occurs after the pod is scheduled and running, not while it is still in 'Pending' state. Option D is wrong because insufficient CPU resources would typically produce a message like 'Insufficient cpu' or '0/4 nodes are available: 4 Insufficient cpu', not the specific taint and affinity messages shown in the question.

Practice this question →

110

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 →

111

MCQmedium

Based on the exhibit, what should you do to determine why the container is failing?

A.Run 'kubectl describe pod backend' to see the pod's status.

B.Run 'kubectl get events' with a different filter to capture more details.

C.Check if the image tag '1.0' exists in the registry.

D.Run 'kubectl logs backend' to view the container's stdout/stderr.

AnswerD

kubectl logs backend fetches the container's captured stdout/stderr streams, which is exactly where a typical application writes its error, panic, or stack trace before exiting. For a pod in CrashLoopBackOff, kubectl logs with --previous can show the logs from the crashed container instance, revealing the root cause of the non-zero exit. This is the most direct way to determine why the process terminates.

Why this answer

The container is failing, and the most direct way to determine why is to inspect its stdout/stderr logs using 'kubectl logs backend'. This command retrieves the container's log output, which typically contains error messages, stack traces, or application-level failure reasons. In CKAD scenarios, when a pod is in CrashLoopBackOff or Error state, logs are the first diagnostic step to identify the root cause.

Exam trap

CNCF often tests the distinction between pod-level metadata (describe/events) and application-level output (logs), and the trap here is that candidates may choose 'kubectl describe pod' thinking it shows all failure details, but it does not include the container's stdout/stderr logs.

How to eliminate wrong answers

Option A is wrong because 'kubectl describe pod backend' shows the pod's status and events, but it does not show the container's stdout/stderr logs; it only provides metadata and conditions, not the application's error output. Option B is wrong because 'kubectl get events' with a different filter may show cluster-level events but does not capture the container's application logs; events are for infrastructure-level issues, not application errors. Option C is wrong because checking if the image tag '1.0' exists in the registry is a valid step only if the issue is an ImagePullBackOff, but the question states the container is failing (likely running then crashing), not failing to pull the image.

Practice this question →

112

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 →

113

Multi-Selectmedium

Which TWO parameters can be configured for a probe to control its behavior? (Choose two.)

Select 2 answers

A.maxRetries

B.backoffSeconds

C.retryIntervalSeconds

D.timeoutSeconds

E.initialDelaySeconds

AnswersD, E

The `timeoutSeconds` parameter is a valid probe setting that defines the maximum duration (in seconds) allowed for a single probe to complete before it is considered failed. This prevents the kubelet from waiting indefinitely on a hanging check. Setting `timeoutSeconds` too high can delay failure detection, while setting it too low may cause false failures for slow applications.

Why this answer

`timeoutSeconds` defines the maximum time a probe waits for a response before considering the probe failed. Option E is correct because `initialDelaySeconds` configures the delay before the probe starts after the container starts, allowing the application to initialize. Both are standard fields in the Kubernetes probe specification (liveness, readiness, startup).

Exam trap

CNCF often tests the distinction between probe parameters and unrelated concepts like retry logic or backoff strategies, leading candidates to confuse fields from other systems (e.g., Spring Boot retry) with Kubernetes probe configuration.

Practice this question →

114

MCQmedium

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?

A.kubectl get events --field-selector involvedObject.name=my-pod

B.kubectl describe pod my-pod

C.kubectl get events | grep my-pod

D.kubectl logs my-pod

AnswerA

This command queries the Events API directly and uses a server-side field selector to filter events whose involvedObject.name equals my-pod. It returns the full event history for that pod as structured YAML/JSON without any client-side text parsing, making it the idiomatic, precise way to list pod-related events. You can extend it with -w to watch live events or add additional field selectors, such as reason=Failed, to narrow the results.

Why this answer

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

Exam trap

The trap here is that candidates often choose `kubectl describe pod my-pod` (option B) thinking it shows all events for the pod, but it only shows a truncated, non-filterable subset of recent events, not the full event history.

How to eliminate wrong answers

Option B is wrong because `kubectl describe pod my-pod` shows a summary of the pod's state and recent events, but it does not filter or display all events from the cluster's event stream; it only shows a limited subset of events embedded in the pod's description. Option C is wrong because `kubectl get events | grep my-pod` relies on text parsing, which can produce false positives if the pod name appears in other event fields (e.g., message text) and is not robust for automation or scripting. Option D is wrong because `kubectl logs my-pod` retrieves container logs, not Kubernetes events; logs are application output, not cluster-level event objects.

Practice this question →

115

MCQmedium

You are troubleshooting a service connectivity issue. You have a pod named 'client' and a service named 'server'. You want to check if the service's endpoints are populated. Which command should you run?

A.kubectl describe pod client

B.kubectl get pods -l app=server

C.kubectl get svc server

D.kubectl get endpoints server

AnswerD

kubectl get endpoints server outputs the Endpoints resource for the named service, listing concrete IP addresses and ports of the ready pods behind it. An empty address list proves the service has no eligible endpoints, while populated entries let you verify a pod's IP matches what the client would reach. Because Endpoints are the runtime result of the service selector, this command directly exposes the data that load balancing uses.

Why this answer

`kubectl get endpoints server` directly retrieves the Endpoints object associated with the service named 'server'. Endpoints are automatically managed by Kubernetes and list the IP addresses and ports of pods that match the service's selector. If the endpoints list is empty, it indicates that no pods are matching the service's selector, which is a common cause of connectivity issues.

Exam trap

The trap here is that candidates often confuse checking the service itself (which shows the selector) with checking the actual endpoints (which shows the resolved pod IPs), leading them to pick Option C when they need to verify if pods are actually backing the service.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pod client` shows details of the client pod, not the service's endpoints; it does not reveal whether the server service has any backing pods. Option B is wrong because `kubectl get pods -l app=server` lists pods with the label 'app=server', but it does not confirm whether those pods are actually registered as endpoints for the 'server' service; a mismatch in selectors or pod readiness could prevent endpoint population. Option C is wrong because `kubectl get svc server` shows the service's cluster IP, ports, and selector, but does not display the actual endpoint IPs; it only indicates the desired state, not the actual backing pods.

Practice this question →

116

Multi-Selectmedium

Which TWO of the following commands can be used to view events related to a specific pod? (Select TWO.)

Select 2 answers

A.kubectl get events --field-selector involvedObject.name=<pod>

B.kubectl events --pod=<pod>

C.kubectl describe pod <pod>

D.kubectl logs <pod>

E.kubectl get events

AnswersA, C

The `--field-selector` flag filters the Kubernetes Event API server-side, using `involvedObject.name=<pod>` to return only events whose involved object is the named pod. This leverages field selectors on the Event object to identify the specific resource (the pod) that the event references, making it a precise and scriptable way to view pod-scoped events.

Why this answer

`kubectl get events --field-selector involvedObject.name=<pod>` filters events by the `involvedObject.name` field, which directly corresponds to the pod's name. This command retrieves all events where the pod is the involved object, such as scheduling, pulling images, or container restarts. Option C is correct because `kubectl describe pod <pod>` includes a dedicated 'Events' section at the bottom of its output, showing recent events for that specific pod in chronological order.

Exam trap

The CKAD exam often tests the distinction between `kubectl get events` (which requires a field selector to filter) and `kubectl describe pod` (which implicitly includes events), and candidates mistakenly think `kubectl events --pod=<pod>` is a valid shorthand, but it does not exist in the kubectl command set.

Practice this question →

117

MCQhard

A developer reports that a container in a pod is not responding correctly. You need to get an interactive shell in the container to investigate. Which command should you run?

A.kubectl run -it --rm debug --image=busybox

B.kubectl exec -it <pod> -- /bin/bash

C.kubectl exec <pod> -- /bin/bash

D.kubectl debug -it <pod> --image=busybox --target=<container>

AnswerB

The kubectl exec command with -- /bin/bash starts a shell process inside the already-running container, while the -it flags allocate a TTY and attach standard input, producing a fully interactive session. This lets you run diagnostic commands, inspect environment variables, and view logs from the exact context of the problematic container. If the container has multiple containers, you would add -c <container-name>, but for a single-container Pod this is the most direct debugging method.

Why this answer

`kubectl exec -it <pod> -- /bin/bash` attaches an interactive terminal to a running container within an existing pod, allowing direct shell access for debugging. The `-it` flags enable interactive mode with a TTY, and `/bin/bash` starts a shell if available in the container image. This is the standard method for troubleshooting a container that is already deployed and running.

Exam trap

The trap here is that candidates may confuse `kubectl exec` with `kubectl run` or `kubectl debug`, mistakenly thinking they need to create a new pod or debug container instead of using the simpler exec command to directly access the running container's shell.

How to eliminate wrong answers

Option A is wrong because `kubectl run -it --rm debug --image=busybox` creates a new standalone pod rather than attaching to the existing problematic pod, which does not allow investigation of the specific container reported as failing. Option C is wrong because `kubectl exec <pod> -- /bin/bash` lacks the `-it` flags, so it does not allocate a TTY or enable interactive input, making it impossible to run an interactive shell session. Option D is wrong because `kubectl debug -it <pod> --image=busybox --target=<container>` is used for ephemeral containers in Kubernetes 1.18+ to add a debugging sidecar, but it does not provide an interactive shell inside the original container; it creates a separate container sharing the same network namespace, which is not the direct shell access requested.

Practice this question →

118

MCQhard

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?

A.The liveness probe failed and restarted the container

B.The container exited with non-zero exit code multiple times before succeeding

C.The pod's node was rebooted

D.The pod was evicted due to node pressure

AnswerB

Under a restartPolicy of OnFailure, a container exiting with a non-zero code triggers a restart, and each failure increments the restart count. If the container eventually exits with code 0, the pod reaches the Completed phase, preserving a restart count that records the earlier failed attempts. This exactly matches a pod that shows Completed but has restarts.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse 'Completed' with 'CrashLoopBackOff' — but 'Completed' means the container exited successfully (exit code 0) after the restarts, while 'CrashLoopBackOff' would indicate ongoing failures with no successful exit.

How to eliminate wrong answers

Option A is wrong because a liveness probe failure would cause the container to be restarted regardless of the exit code, and the pod would typically remain in 'Running' state, not 'Completed'; also, liveness probe restarts are counted but the pod would not show 'Completed' unless the container exited successfully. Option C is wrong because a node reboot would restart all containers on the node, but the pod would show a 'Running' or 'Pending' state after reboot, not 'Completed', and the restart count would increment for all containers, not just this one. Option D is wrong because pod eviction due to node pressure results in the pod being terminated and possibly recreated on another node, but the pod would show a 'Failed' or 'Evicted' status, not 'Completed', and the restart count would not increment from eviction.

Practice this question →

119

MCQeasy

You want to see detailed information about a node's resource usage. Which command should you run?

A.kubectl describe node

B.kubectl logs node

C.kubectl get nodes -o wide

D.kubectl top node

AnswerD

kubectl top node retrieves live CPU and memory usage for each node from the Kubernetes metrics API, which is typically served by metrics-server, and reports both raw values and the percentage of allocatable resources consumed. It is the Kubernetes equivalent of the top utility and the standard way to see current node utilization. If metrics-server is not installed or unavailable, the command fails with an error like 'error: metrics not available'.

Why this answer

`kubectl top node` retrieves real-time CPU and memory usage metrics for nodes from the metrics server, which is essential for monitoring resource consumption. This command directly answers the question about detailed resource usage, unlike other options that provide configuration or log data.

Exam trap

The trap here is that candidates confuse `kubectl describe node` (which shows static resource capacity) with `kubectl top node` (which shows dynamic usage), leading them to choose option A for resource monitoring questions.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node` shows node metadata, conditions, and capacity/allocatable resources, but not real-time usage metrics. Option B is wrong because `kubectl logs node` is invalid; logs are fetched for pods, not nodes, and this command would fail. Option C is wrong because `kubectl get nodes -o wide` displays additional node details like internal IP and OS image, but not dynamic resource usage.

Practice this question →

120

MCQeasy

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

A.kubectl top node

B.kubectl resource pod

C.kubectl top pod

D.kubectl metrics pod

AnswerC

This is the correct command. `kubectl top pod` retrieves real-time CPU and memory usage metrics from the Metrics API, which is typically backed by metrics-server. It displays per-pod usage and supports flags like `--containers` to drill down into individual container utilization, making it the standard tool for troubleshooting pod resource consumption.

Why this answer

The `kubectl top pod` command retrieves and displays real-time CPU and memory usage metrics for pods from the metrics server, which aggregates resource usage data from kubelets via the Resource Metrics API. This is the correct command to view per-pod resource consumption in a Kubernetes cluster.

Exam trap

The trap here is that candidates may confuse `kubectl top pod` with `kubectl top node` (option A) or invent a non-existent command like `kubectl metrics pod` (option D), because the CKAD exam often tests the exact syntax of the `top` subcommand for resource monitoring.

How to eliminate wrong answers

Option A is wrong because `kubectl top node` shows resource usage for nodes, not pods, and is used to view aggregate node-level CPU and memory metrics. Option B is wrong because `kubectl resource pod` is not a valid kubectl command; the correct verb for viewing metrics is `top`, not `resource`. Option D is wrong because `kubectl metrics pod` is not a valid kubectl command; the metrics are accessed via the `top` subcommand, not a `metrics` subcommand.

Practice this question →

121

MCQeasy

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

A.Configure a Prometheus server to scrape the Pod's /metrics endpoint.

B.Use kubectl top pod to view CPU and memory metrics.

C.Exec into the container and run curl to check health.

D.Create a ServiceMonitor resource to expose metrics.

AnswerA

Configuring a Prometheus server to scrape the Pod's /metrics endpoint is the correct approach because Prometheus is the de facto standard for collecting and storing application-level metrics in Kubernetes. You define a scrape job—either statically in prometheus.yml or via Kubernetes service discovery—that targets the pod's address and the /metrics path, and Prometheus periodically retrieves the metrics over HTTP. This provides persistent time-series data queryable with PromQL, and it enables alerting and visualization through Grafana, making it the proper foundation for application monitoring.

Why this answer

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

Exam trap

The trap here is that candidates confuse resource-level metrics (CPU/memory) with application-level metrics, or assume that kubectl top pod or exec commands are sufficient for observability, when Kubernetes best practices emphasize using a dedicated monitoring system like Prometheus for application metrics.

How to eliminate wrong answers

Option B is wrong because kubectl top pod only shows CPU and memory usage from the resource metrics pipeline, not application-level metrics like request latency or error rates. Option C is wrong because execing into a container and running curl is an ad-hoc debugging method, not a scalable or best-practice approach for ongoing observability. Option D is wrong because a ServiceMonitor is a Prometheus Operator custom resource that requires the Operator to be installed and is not a native Kubernetes resource; it is not a general best practice for all clusters.

Practice this question →

122

Multi-Selecthard

You are tasked with improving the observability of a microservices application running in Kubernetes. The application is deployed with multiple replicas and experiences occasional high latency. Which TWO actions should you take to gain better insight into the application's performance?

Select 2 answers

A.Increase the replica count for each deployment to reduce latency.

B.Enable Prometheus metrics endpoints on each pod and configure a Prometheus server to scrape them.

C.Configure readiness probes to ensure only healthy pods receive traffic.

D.Add liveness probes to all containers to detect when they are unresponsive.

E.Implement distributed tracing using Jaeger to trace requests across services.

AnswersB, E

Prometheus scraping per-pod metrics endpoints exposes latency histograms and request rates across every replica, satisfying the need to diagnose occasional high latency in a multi-replica deployment. Unlike node-level or aggregated monitoring, it attributes performance data to individual pods, revealing whether specific replicas degrade.

Why this answer

Option B is correct because exposing Prometheus metrics endpoints on each pod and configuring a Prometheus server to scrape them provides quantitative observability into request rates, error rates, and latency histograms per service and replica, which is essential for diagnosing occasional high latency in a microservices application. Option E is correct because implementing distributed tracing with Jaeger captures end-to-end request flows across service boundaries, letting you pinpoint which service or call in a chain contributes to latency spikes, something metrics alone cannot attribute to a specific request path. The unmarked options do not belong: A (increasing replica count) is a scaling remediation, not an observability action, and may mask rather than reveal the root cause; C (readiness probes) and D (liveness probes) are availability and health-management mechanisms that affect traffic routing and container restarts but do not provide performance insight into latency.

Exam trap

CNCF often tests the distinction between observability (monitoring, metrics, tracing) and reliability mechanisms (probes, scaling). Candidates mistakenly choose readiness or liveness probes as tools for performance insight instead of recognizing they only ensure basic health and traffic routing. Similarly, scaling replicas is a performance fix, not an observability improvement.

Practice this question →

123

MCQmedium

You run 'kubectl get pods' and see that a pod is in 'Pending' state. What is the most likely cause?

A.The readiness probe is failing

B.The container command exited with an error

C.The pod's imagePullPolicy is set to Never

D.The node has insufficient resources to run the pod

AnswerD

A pod remains in Pending when the scheduler cannot find a node that meets its resource requests (CPU and memory). The scheduler's predicate filters out nodes with insufficient allocatable capacity, so no node is selected, the PodScheduled condition is set to False, and the pod waits indefinitely—this is why Pending is the correct answer. Unlike container-level failures, this is a pre-scheduling issue; kubectl describe events would show a FailedScheduling message with reasons like FailedNodeSelector or OutOfRange.

Why this answer

A pod in 'Pending' state indicates that the pod has been accepted by the Kubernetes API server but is not yet scheduled to a node. The most common cause is insufficient resources (CPU, memory, or ephemeral storage) on any available node, which prevents the scheduler from binding the pod. This is confirmed by running 'kubectl describe pod <pod-name>' and checking the 'Events' section for messages like '0/1 nodes are available: Insufficient cpu'.

Exam trap

The trap here is that candidates confuse pod lifecycle phases: 'Pending' is specifically about scheduling or container image download delays, not about runtime failures like probe failures or command errors, which occur after the pod is already running.

How to eliminate wrong answers

Option A is wrong because a failing readiness probe causes the pod to be in 'Running' state but not ready to serve traffic, not 'Pending'. Option B is wrong because a container command exiting with an error results in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option C is wrong because imagePullPolicy: Never only affects image pulling behavior and can cause 'ImagePullBackOff' or 'ErrImageNeverPull' if the image is not present locally, but the pod would still be scheduled and move past 'Pending' to a container-creation phase.

Practice this question →

124

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 →

125

MCQeasy

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

A.kubectl logs my-pod

B.kubectl describe pod my-pod

C.kubectl get pod my-pod -o yaml

D.kubectl top pod my-pod

AnswerB

kubectl describe pod my-pod is the correct command because it produces a human-readable, aggregated summary of the pod's configuration, current status, and lifecycle conditions. Crucially, it also displays recent events (e.g., pulls, scheduling, errors) at the bottom, which are essential for diagnosing why a pod is not running as expected.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `kubectl get pod -o yaml` with `kubectl describe pod`, not realizing that `describe` includes the event history and a human-readable state summary that `get -o yaml` omits.

How to eliminate wrong answers

Option A is wrong because `kubectl logs my-pod` only streams the stdout/stderr output from the container(s), not metadata like events, labels, or container state. Option C is wrong because `kubectl get pod my-pod -o yaml` outputs the full Kubernetes object manifest in YAML, which includes labels and container state but does NOT include the event history or the human-readable summary of conditions and recent state transitions. Option D is wrong because `kubectl top pod my-pod` shows real-time CPU and memory usage metrics from the metrics-server, not events, labels, or container state details.

Practice this question →

126

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 →

127

MCQhard

You have a pod that takes 2 minutes to start its application. You want to avoid the liveness probe from killing the pod during startup, but still have it active afterward. Which probe should you add to the pod spec?

A.Add a startup probe with a failureThreshold high enough to cover the startup time

B.Increase the timeoutSeconds on the liveness probe

C.Set periodSeconds on the liveness probe to 120

D.Set initialDelaySeconds on the liveness probe to 120

AnswerA

A startup probe is the idiomatic solution because Kubernetes keeps the liveness and readiness probes disabled until this startup probe succeeds, so a slow-starting process is not repeatedly killed. Configure failureThreshold and periodSeconds together so their product comfortably exceeds the ~2 minute startup window (e.g., failureThreshold: 20, periodSeconds: 10). Once the startup probe succeeds, the normal liveness and readiness probes take over, and if the app later fails, it gets restarted.

Why this answer

A startup probe is designed specifically for slow-starting containers. It runs before the liveness probe and, if it fails, the container is killed. By setting a high failureThreshold (e.g., 12 with a 10-second period gives 120 seconds), you allow the application up to 2 minutes to start without the liveness probe interfering.

Once the startup probe succeeds, the liveness probe takes over normally.

Exam trap

The trap here is that candidates often choose initialDelaySeconds (option D) thinking it's the standard way to handle slow starts, but it doesn't account for variable startup times and can mask real failures after the delay expires.

How to eliminate wrong answers

Option B is wrong because increasing timeoutSeconds on the liveness probe only extends how long Kubernetes waits for a single probe response, not the total startup window; the probe still starts immediately and can kill the pod before the app is ready. Option C is wrong because setting periodSeconds to 120 on the liveness probe only makes it check every 2 minutes, but the first check still occurs immediately (or after initialDelaySeconds), so it could kill the pod before the app starts. Option D is wrong because initialDelaySeconds on the liveness probe delays the first probe by 120 seconds, but this is a static delay that doesn't adapt to actual startup time; if the app takes longer than expected, the probe still kills it, and it also delays detection of real failures after startup.

Practice this question →

128

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 →

129

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 →

130

MCQeasy

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

A.kubectl top pods --all-namespaces

B.kubectl top pods

C.kubectl top pod <pod>

D.kubectl top pod <pod> --containers

AnswerD

kubectl top pod <pod> --containers is the correct command because it lists each container within the specified pod separately, showing its individual CPU and memory consumption. This gives the developer the exact per-container resource usage needed, making it the only option that satisfies the requirement directly.

Why this answer

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

Exam trap

The trap here is that candidates often assume `kubectl top pod <pod>` alone shows container-level details, but without the `--containers` flag it only shows pod-level aggregates, leading them to choose option C instead of D.

How to eliminate wrong answers

Option A is wrong because `kubectl top pods --all-namespaces` shows pod-level resource usage across all namespaces, not per-container metrics for a specific pod. Option B is wrong because `kubectl top pods` shows pod-level resource usage in the current namespace, but does not break down usage by individual containers. Option C is wrong because `kubectl top pod <pod>` shows aggregate resource usage for the entire pod, not per-container details, which fails to meet the requirement of viewing all containers' usage.

Practice this question →

131

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 follows the log stream, keeping the connection open and outputting new entries as they are generated rather than returning existing logs and exiting. This delivers the real-time streaming required for the named pod.

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 →

132

Multi-Selectmedium

You need to check the resource usage of nodes and pods in your cluster. Which TWO commands should you use? (Choose two)

Select 2 answers

A.kubectl top nodes

B.kubectl logs

C.kubectl cluster-info

D.kubectl describe pod

E.kubectl top pods

AnswersA, E

kubectl top nodes queries the metrics server to retrieve CPU and memory utilization for each cluster node, aggregated across all pods. It displays both the current usage and percentage of allocatable capacity, providing a quick cluster-wide view of resource pressure. This command is essential for identifying overall node resource saturation and planning capacity, but it requires the metrics server to be installed and operational.

Why this answer

A is correct because `kubectl top nodes` retrieves real-time CPU and memory usage metrics for all nodes in the cluster, sourced from the metrics server (which collects resource usage from kubelets via the Summary API). This command is the standard way to check node-level resource consumption in Kubernetes.

Exam trap

The CKAD exam often tests the distinction between `kubectl top` (actual resource usage) and `kubectl describe` (resource requests/limits), leading candidates to mistakenly choose `kubectl describe pod` thinking it shows live usage.

Practice this question →

133

MCQmedium

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?

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

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

C.kubectl debug -it my-pod --image=busybox --target=my-container

D.kubectl port-forward my-pod 8080:80

AnswerC

kubectl debug -it my-pod --image=busybox --target=my-container is correct because it creates a new ephemeral container in the same pod, sharing the pod's network namespace and, with --target, the process namespace of my-container. Busybox comes with a built-in ash shell and standard diagnostic utilities (ps, netstat, ls, cat), giving you an interactive shell without needing anything preinstalled in the original container. The ephemeral container has its own filesystem and can run commands that see and signal the target container's processes, exactly what you need to debug a pod that lacks a shell or debugging tools.

Why this answer

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

Exam trap

The trap here is that candidates often assume `kubectl exec` can always provide a shell, but the CKAD exam tests the specific scenario where the container lacks a shell or tools, making `kubectl debug` the only viable option for injecting debugging capabilities.

How to eliminate wrong answers

Option A is wrong because `kubectl exec -it my-pod -- /bin/bash` attempts to run a shell inside the existing container, which fails if the container has no shell or debugging tools installed. Option B is wrong because `kubectl cp` copies files into the container's filesystem but does not install or run debugging tools; it requires the container to already have a shell or executable to use the copied files. Option D is wrong because `kubectl port-forward` forwards network traffic to a pod's port and does not provide any debugging tools or shell access.

Practice this question →

134

MCQhard

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

A.The init container failed to complete.

B.The readiness probe is misconfigured.

C.The container is trying to bind to a port already used by a sidecar or previous instance.

D.The liveness probe is failing and restarting the container.

AnswerC

The container is trying to bind to a port already used by a sidecar or previous instance. The error 'address already in use' (EADDRINUSE) indicates that the application's listen() call failed because the port is already occupied in the shared network namespace. In a pod, containers share the same network namespace, so a sidecar bound to the same port would cause this conflict. Additionally, if a previous instance of the pod is still shutting down and holding the socket in TIME_WAIT, a rapid restart can trigger the same bind failure.

Why this answer

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

Exam trap

The trap here is that candidates often assume CrashLoopBackOff is always caused by a failing liveness probe (Option D), but they overlook that the container must actually start and run for the liveness probe to be checked; if the container crashes immediately on startup (e.g., due to port conflict), the liveness probe never even runs, and the root cause is a startup failure, not a probe failure.

How to eliminate wrong answers

Option A is wrong because if the init container had failed to complete, the Pod would remain in Init:CrashLoopBackOff or Init:Error, not in CrashLoopBackOff for the main container. Option B is wrong because a misconfigured readiness probe would cause the container to be marked as not ready (removed from service endpoints), but it would not cause the container to crash or enter CrashLoopBackOff; the container would continue running. Option D is wrong because a failing liveness probe would cause the container to be restarted, but the Pod would show a restart count and potentially a CrashLoopBackOff only if the container crashes immediately after restart; however, the question asks for the 'most likely cause' given the exhibit (not provided here), and port binding conflicts are a classic cause of immediate crash on startup, whereas liveness probe failures typically occur after the container has started and run for a short time.

Practice this question →

135

MCQmedium

A pod named 'db-backup' is in CrashLoopBackOff. The team needs to understand why it keeps crashing. Which approach should be taken first to diagnose the issue?

A.Increase the restart policy to Always

B.Run kubectl describe pod

C.View the logs of the pod using kubectl logs

D.Check the pod's events with kubectl get events

AnswerC

kubectl logs reads the container's captured stdout/stderr and directly exposes the panic, exception, or configuration error triggering the CrashLoopBackOff. Since the pod is in CrashLoopBackOff, use kubectl logs db-backup --previous to retrieve logs from the last terminated instance, as the current container may have already exited. This is the fastest way to identify the exact failing statement and then patch the manifest or fix the code.

Why this answer

C is correct because `kubectl logs` directly shows the stdout/stderr output from the container's main process, which typically contains the error message or stack trace explaining why the application crashed. Since the pod is in CrashLoopBackOff, the container is repeatedly starting and failing, so viewing the logs from the last (or previous) attempt is the fastest way to identify the root cause, such as a missing configuration file, a failed dependency, or an unhandled exception.

Exam trap

The trap here is that candidates often choose `kubectl describe pod` (Option B) because it shows events and exit codes, but they overlook that `kubectl logs` directly reveals the application's error message, which is the most efficient first step for debugging a crash.

How to eliminate wrong answers

Option A is wrong because changing the restart policy to Always does not diagnose the crash; it only changes the behavior after a crash, and the pod already has a restart policy (default Always) that is causing the CrashLoopBackOff. Option B is wrong because `kubectl describe pod` provides metadata, events, and status but does not show the application's stdout/stderr logs; it can show why the container exited (e.g., exit code) but not the specific error message from the application. Option D is wrong because `kubectl get events` shows cluster-level events (e.g., pulling images, scheduling) but not the application's internal error output; it may show the container restart count but not the crash reason.

Practice this question →

136

MCQeasy

You want to see all events in the default namespace sorted by timestamp. Which command should you use?

A.kubectl get events

B.kubectl logs --all-containers

C.kubectl top events

D.kubectl describe pods

AnswerA

kubectl get events retrieves all Event API objects in the current namespace (default) and prints them in a table. By default, the output is sorted by the lastTimestamp field, so the most recent events appear at the bottom. This is the standard way to inspect namespace-wide activity such as scheduling, pulling images, or failing probes.

Why this answer

`kubectl get events` retrieves all events in the current namespace (default) and displays them in a table sorted by the `LAST SEEN` timestamp by default. Events are Kubernetes API objects that record actions and state changes (e.g., pod scheduling, container restarts), making this command the standard way to observe cluster activity in a namespace.

Exam trap

The trap here is that candidates may confuse `kubectl get events` with `kubectl describe` (which shows events only for a specific resource) or assume `kubectl top` can list events because of the word 'top', but `kubectl top` is exclusively for resource usage metrics (CPU/memory).

How to eliminate wrong answers

Option B is wrong because `kubectl logs --all-containers` streams container logs from a specific pod, not cluster-wide events, and has no concept of timestamps for events. Option C is wrong because `kubectl top events` is not a valid kubectl command; `kubectl top` is used for resource usage metrics (e.g., `kubectl top pods`), not events. Option D is wrong because `kubectl describe pods` shows detailed information about specific pods, including recent events embedded in the output, but it does not list all events in the namespace and is not sorted by timestamp.

Practice this question →

137

MCQmedium

A container in a pod is crashing repeatedly. You want to see the logs from the previous (crashed) instance of the container. Which command should you use?

A.kubectl logs --tail=10 <pod>

B.kubectl logs <pod> --previous

C.kubectl logs -c <container> <pod>

D.kubectl logs -f <pod>

AnswerB

kubectl logs <pod> --previous retrieves the logs written by the previous container instance before it terminated — exactly the data needed to diagnose a repeated crash. Kubernetes keeps a copy of the terminated container's logs on the node as long as the pod exists and the restart count is at least one, allowing --previous to replay them. The flag is the standard kubectl method to inspect the last incarnation of a failing container. This is the correct approach.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and restarted. This allows you to inspect the logs of the terminated container to diagnose the crash, even though the current container instance is running or has restarted.

Exam trap

The trap here is that candidates often confuse `--previous` with `--tail` or `-f`, thinking they need to limit output or follow logs, when the key requirement is accessing logs from a terminated container instance.

How to eliminate wrong answers

Option A is wrong because `--tail=10` only limits the output to the last 10 lines of the current container's logs, not the logs from the previous (crashed) instance. Option C is wrong because `-c <container>` specifies a container name within a multi-container pod, but does not retrieve logs from a previous crashed instance. Option D is wrong because `-f` follows (streams) the current container's logs in real time, which is irrelevant for viewing logs from a previous crash.

Practice this question →

138

MCQeasy

You need to view resource usage (CPU and memory) for all pods in the 'default' namespace. Which command should you use?

A.kubectl top pods

B.kubectl logs pods

C.kubectl describe pods

D.kubectl top nodes

AnswerA

kubectl top pods is correct because it queries the Metrics API and prints real-time CPU and memory utilization for each pod in the current namespace. This command depends on the metrics-server (or a compatible metrics provider) being deployed in the cluster; without it, kubectl top pods fails with an error. It directly surfaces the live resource usage values needed to answer the question.

Why this answer

`kubectl top pods` is the command specifically designed to display real-time CPU and memory usage metrics for pods in a Kubernetes cluster. 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 viewing resource consumption in the 'default' namespace.

Exam trap

The trap here is that candidates often confuse `kubectl top pods` with `kubectl describe pods` or `kubectl logs`, mistakenly thinking that descriptive or log commands provide resource usage data, but only `kubectl top` accesses the metrics server for real-time utilization.

How to eliminate wrong answers

Option B is wrong because `kubectl logs pods` is used to retrieve log output from containers in a pod, not to view CPU or memory usage metrics. Option C is wrong because `kubectl describe pods` provides detailed metadata and status information about pods, including resource requests and limits, but does not show real-time CPU and memory usage. Option D is wrong because `kubectl top nodes` displays resource usage at the node level (aggregate CPU and memory for all pods on a node), not per-pod metrics in the 'default' namespace.

Practice this question →

139

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 →

140

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 →

141

Multi-Selectmedium

Which FOUR of the following are valid probe handlers in Kubernetes?

Select 4 answers

A.exec

B.gRPC

C.httpGet

D.tcpSocket

E.udpSocket

AnswersA, B, C, D

The `exec` handler runs a command inside the container, treating exit code 0 as success. It satisfies the stem's requirement for a valid probe handler, alongside `httpGet`, `tcpSocket` and `grpc`. This mechanism suits liveness and readiness checks needing custom logic unavailable through network or command probes alone.

Why this answer

In Kubernetes, the kubelet supports exactly four probe handler mechanisms for liveness, readiness, and startup probes. Option A (exec) is correct because it runs a command inside the container and uses the exit code to determine success. Option B (gRPC) is correct because Kubernetes supports gRPC health checking (GA since v1.24) via the gRPC Health Checking Protocol.

Option C (httpGet) is correct because it performs an HTTP GET request against the container's IP and port, treating 200-399 status codes as success. Option D (tcpSocket) is correct because it attempts a TCP connection to the specified port, succeeding if the connection is established. Option E (udpSocket) is not a valid handler, as Kubernetes does not provide a UDP-based probe type; probes use exec, httpGet, tcpSocket, or gRPC only.

Exam trap

Candidates may mistakenly think only the original three (exec, httpGet, tcpSocket) are valid, overlooking gRPC which has been supported since v1.24. Conversely, they might include udpSocket because it is a common network protocol.

Practice this question →

142

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 →

143

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 the log stream, continuously tailing new output from the container rather than printing existing entries and exiting. This satisfies the real-time streaming requirement in the stem, unlike a plain `kubectl logs pod-name` invocation, which returns the current log buffer and terminates immediately.

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 →

144

MCQmedium

You have a pod that is stuck in 'Pending' state. Which command would you run first to diagnose the issue?

A.kubectl logs <pod>

B.kubectl get pods

C.kubectl get events

D.kubectl describe pod <pod>

AnswerD

kubectl describe pod <pod> is the standard diagnostic for a Pending pod because it shows the pod's Conditions (PodScheduled, Initialized, ContainersReady) and a dedicated Events section containing the exact scheduler or kubelet warnings. For example, it will display FailedScheduling with node resource pressure, FailedMount for volume issues, or taint/toleration mismatches. This output, combined with the assigned node and container statuses, directly pinpoints the blocker so you can take corrective action.

Why this answer

`kubectl describe pod <pod>` provides detailed information about the pod's current state, including events, conditions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims pending). This is the first diagnostic step for a 'Pending' pod, as it surfaces the root cause (e.g., node resource pressure, PVC binding failures) without requiring additional commands.

Exam trap

The trap here is that candidates often jump to `kubectl logs` (Option A) thinking it shows startup errors, but logs are only available after containers start, making it useless for a 'Pending' pod; instead, `kubectl describe pod` is the standard first diagnostic tool for scheduling and resource issues.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod>` retrieves container logs, which are only available if the pod has started running; a 'Pending' pod has not yet scheduled or started containers, so logs are empty or inaccessible. Option B is wrong because `kubectl get pods` only shows the pod's status (e.g., 'Pending') and basic metadata, not the underlying reasons for the pending state (e.g., unschedulable, image pull errors). Option C is wrong because `kubectl get events` lists cluster-wide events, which may include relevant scheduling failures, but it is less targeted than `kubectl describe pod`, which filters events specific to the pod and presents them alongside other critical details like node selector mismatches or taint tolerations.

Practice this question →

145

Drag & Dropmedium

Order the steps to update a Kubernetes Secret and ensure a Pod uses the new secret.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Update secret, then if mounted as volume, Pod picks it up automatically; if env, need restart.

Practice this question →

146

MCQeasy

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

A.kubectl logs app -c sidecar

B.kubectl logs app --previous -c sidecar

C.kubectl logs app sidecar

D.kubectl logs app -c sidecar -p

AnswerA

The command `kubectl logs app -c sidecar` is correct because it explicitly targets the `sidecar` container within the `app` pod using the `-c` flag. This is the required syntax for retrieving logs from a specific container in a multi-container pod. Without the `-c` flag, kubectl would either fail or default to the first container, so this option precisely fetches the current logs of the desired container.

Why this answer

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

Exam trap

The trap here is that candidates often forget the `-c` flag for multi-container pods and assume the container name can be passed as a positional argument, leading them to choose option C.

How to eliminate wrong answers

Option B is wrong because `--previous` retrieves logs from the previous instance of a terminated container, not from the currently running 'sidecar' container, and is unnecessary for viewing live logs. Option C is wrong because `kubectl logs app sidecar` treats 'sidecar' as a pod name, not a container name, leading to an error or incorrect log retrieval. Option D is wrong because `-p` is a shorthand for `--previous`, which again fetches logs from a terminated container, not the current 'sidecar' container.

Practice this question →