CCNA Application Observability and Maintenance Questions — Page 2 of 3

Multi-Selectmedium

Which TWO statements are true about readiness probes? (Select two.)

Select 2 answers

A.Readiness probes are only executed when the pod is first started

B.Readiness probes can be configured as httpGet, exec, tcpSocket, or gRPC

C.A failing readiness probe causes the pod to be restarted

D.Readiness probes are defined in the pod spec under 'startupProbe'

E.A failing readiness probe removes the pod from the Service's endpoints

AnswersB, E

These are the supported probe types for readiness probes as well.

Why this answer

Readiness probes determine if a container is ready to serve traffic. If failing, the pod is removed from Service endpoints. They are independent of liveness probes.

Practice this question →

Multi-Selecthard

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

Select 2 answers

A.The node is out of disk space

B.The container exits immediately with a non-zero exit code

C.The readiness probe is failing

D.The pod is pending because of insufficient resources

E.The liveness probe is failing and restarting the container

AnswersB, E

Correct. Application crash causes restart loop.

Why this answer

CrashLoopBackOff means the container exits repeatedly and Kubernetes is delaying restarts. Common causes: application error causing exit, or liveness probe failure restarting the container.

Practice this question →

MCQmedium

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

A.The container image is not available

B.The liveness probe is failing

C.The pod's resource requests exceed available resources on any node

D.The container is crashing due to an error

AnswerC

The scheduler found no node with enough CPU and memory to satisfy the pod's requests.

Why this answer

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

Exam trap

CNCF often tests the distinction between pod lifecycle phases (Pending, Running, CrashLoopBackOff) and the specific error messages in 'kubectl describe pod', leading candidates to confuse scheduling failures with runtime issues like image pull errors or probe failures.

How to eliminate wrong answers

Option A is wrong because an unavailable container image would cause the pod to stay in 'Pending' or 'ImagePullBackOff' state, but the error message would reference 'ImagePullBackOff' or 'ErrImagePull', not resource insufficiency. Option B is wrong because a failing liveness probe would cause the pod to be restarted (CrashLoopBackOff) or become 'Running' but unhealthy, not stuck in 'Pending' — liveness probes are only checked after the container starts. Option D is wrong because a container crashing due to an error would result in 'CrashLoopBackOff' or 'Error' state, not 'Pending', and the describe output would show crash loop backoff or exit code details, not resource insufficiency.

Practice this question →

MCQmedium

A container in a pod is expected to shut down gracefully within 30 seconds when it receives SIGTERM. How should you configure the pod to ensure the container is given enough time to shut down before being forcefully killed?

A.Set spec.terminationGracePeriod: 35

B.Set spec.terminationGracePeriodSeconds: 35

C.Set spec.terminationGracePeriodSeconds: 300

D.Set spec.terminationGracePeriodSeconds: 20

AnswerB

This gives the container 35 seconds to shut down after SIGTERM before SIGKILL is sent.

Why this answer

terminationGracePeriodSeconds defines the time Kubernetes waits after sending SIGTERM before sending SIGKILL. Setting it to 35 seconds gives the container a 5-second buffer. Option B is correct.

Option A is not a valid field. Option C sets the grace period too short. Option D sets it to an excessively long time.

Practice this question →

MCQhard

A pod spec has terminationGracePeriodSeconds: 30. The main process ignores SIGTERM. After 30 seconds, what happens?

A.The pod remains running indefinitely

B.The pod enters a CrashLoopBackOff state

C.The pod is rescheduled to another node

D.SIGKILL is sent to forcefully terminate the container

AnswerD

After the grace period, the container is forcefully killed with SIGKILL.

Why this answer

If SIGTERM is ignored, Kubernetes waits for terminationGracePeriodSeconds, then sends SIGKILL to force termination. Option B is correct.

Practice this question →

MCQmedium

You want to run a command inside an existing container 'app-container' in pod 'my-pod'. The pod has only one container. Which command enters an interactive shell?

A.kubectl exec my-pod -c app-container /bin/sh

B.kubectl exec -it my-pod -- /bin/sh

C.kubectl run -it my-pod --image=busybox

D.kubectl attach my-pod

AnswerB

Correct. -it allocates a pseudo-TTY and keeps stdin open.

Why this answer

kubectl exec -it podname -- /bin/sh opens an interactive shell inside the container.

Practice this question →

MCQmedium

You need to debug a Pod that is in CrashLoopBackOff. Which command should you run first?

A.kubectl get events --sort-by=.lastTimestamp

B.kubectl logs <pod-name>

C.kubectl exec -it <pod-name> -- sh

D.kubectl describe pod <pod-name>

AnswerB

Logs often contain the error that caused the crash.

Why this answer

When a Pod is in CrashLoopBackOff, the immediate priority is to see why the container is failing. `kubectl logs <pod-name>` retrieves the container's stdout/stderr output, which typically contains the error message (e.g., missing config, runtime exception, or startup failure). This is the fastest way to get the root cause without modifying the Pod state.

Exam trap

CNCF often tests the misconception that `kubectl describe pod` provides enough debugging information, but it only shows the exit code and a brief termination message, not the full application logs that reveal the actual error.

How to eliminate wrong answers

Option A is wrong because `kubectl get events --sort-by=.lastTimestamp` shows cluster-level events (e.g., scheduling, pulling images) but does not show the container's application logs, which are essential for debugging a crash loop. Option C is wrong because `kubectl exec -it <pod-name> -- sh` attempts to start an interactive shell inside a running container, but if the Pod is in CrashLoopBackOff, the container is not running, so exec will fail with an error like 'error: unable to upgrade connection: container not found'. Option D is wrong because `kubectl describe pod <pod-name>` provides metadata, status, and events, but it does not include the container's stdout/stderr logs; it only shows the last termination state and exit code, which is less detailed than the actual logs.

Practice this question →

MCQmedium

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

A.kubectl get events

B.kubectl describe pod web-1 --events

C.kubectl get events --field-selector involvedObject.name=web-1

D.kubectl get events --selector name=web-1

AnswerC

Correctly filters events for the pod.

Why this answer

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

Exam trap

The trap here is that candidates confuse label selectors (`--selector`) with field selectors (`--field-selector`), assuming pod names are labels, when in fact events use the `involvedObject` field for association, not metadata labels.

How to eliminate wrong answers

Option A is wrong because `kubectl get events` returns all events in the namespace without any filtering, which is too broad and not specific to the pod 'web-1'. Option B is wrong because `kubectl describe pod web-1 --events` is not a valid command; the `--events` flag does not exist for `kubectl describe`, and even if it did, `describe` shows pod details but not a filtered list of events. Option D is wrong because `--selector name=web-1` uses label selectors, but events are not labeled with the pod's name; the pod name is stored in the `involvedObject.name` field, not as a label, so this selector would return no events or incorrect ones.

Practice this question →

MCQeasy

A container in your pod takes a long time to start (up to 5 minutes). You want to avoid the container being restarted by the liveness probe during this period. What should you configure?

A.Set a long 'initialDelaySeconds' on the liveness probe

B.Add a readiness probe

C.Increase the failureThreshold on the liveness probe

D.Add a startup probe with a longer failure threshold

AnswerD

A startup probe delays the liveness and readiness probes until the container has started successfully.

Why this answer

A startup probe is designed specifically for slow-starting containers. It runs at initialization and defers the liveness and readiness probes until it succeeds. By setting a high `failureThreshold` (e.g., 30) with a short `periodSeconds` (e.g., 10s), you allow up to 5 minutes for the container to start without the liveness probe killing it.

Exam trap

The trap here is that candidates confuse `initialDelaySeconds` (a static delay) with the startup probe (a dynamic, failure-tolerant mechanism), leading them to pick option A, which does not handle variable or long startup times reliably.

How to eliminate wrong answers

Option A is wrong because `initialDelaySeconds` only delays the start of the liveness probe by a fixed time, but if the container takes up to 5 minutes and the probe starts after that delay, it may still fail and restart the container before startup completes. Option B is wrong because a readiness probe controls traffic routing, not container restarts; it does not prevent the liveness probe from restarting the container during startup. Option C is wrong because increasing `failureThreshold` on the liveness probe only increases the number of consecutive failures allowed after the probe has started, but it does not prevent the probe from starting too early and potentially restarting the container before it is ready.

Practice this question →

MCQeasy

You need to view the logs of the previous (terminated) instance of a container in a pod. Which command should you use?

A.kubectl describe pod pod-name | grep -A 10 'Last State'

B.kubectl logs pod-name --tail=100

C.kubectl logs pod-name -p

D.kubectl logs pod-name -f

AnswerC

The -p flag is short for --previous and shows logs from the previous instance of the container.

Why this answer

The '--previous' flag is used to retrieve logs from the previous instance of a container that has been terminated or restarted. This is useful for debugging crash loops.

Practice this question →

MCQhard

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

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

B.kubectl attach pod-name

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

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

AnswerC

This adds an ephemeral container to the running pod (or creates a copy if the pod is not running) with the specified image.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

Which TWO actions can you perform using 'kubectl describe'? (Select two.)

Select 2 answers

A.View the conditions and status of a node

B.Execute a command inside a container

C.View the logs of a container

D.View the events associated with a pod

E.View the YAML manifest of a resource

AnswersA, D

'kubectl describe node' shows conditions, capacity, and other details.

Why this answer

'kubectl describe' provides detailed information about Kubernetes resources, including events and conditions. It can show the current state and recent events. It does not modify resources or show logs.

Practice this question →

MCQhard

You need to configure a liveness probe that checks if the container port 8080 is open. Which probe type should you use?

A.tcpSocket

B.grpc

C.exec

D.httpGet

AnswerA

tcpSocket probe succeeds if the TCP handshake completes.

Why this answer

A tcpSocket probe is the correct choice when you need to verify that a container is listening on a specific TCP port, such as port 8080. It works by attempting to open a TCP connection to the specified port; if the connection succeeds, the probe is considered successful. This is ideal for checking basic network-level readiness or liveness without requiring an HTTP endpoint or a custom command.

Exam trap

The trap here is that candidates often choose httpGet because they assume a web server on port 8080, but the question explicitly asks only to check if the port is open, not to validate an HTTP response, making tcpSocket the precise and minimal probe type.

How to eliminate wrong answers

Option B (grpc) is wrong because gRPC probes are used specifically for checking the health of gRPC services using the gRPC health checking protocol, not for verifying that a raw TCP port is open. Option C (exec) is wrong because exec probes run a command inside the container and check its exit code, which is unnecessary overhead when you only need to confirm a port is listening. Option D (httpGet) is wrong because httpGet probes require an HTTP endpoint that returns a valid status code (2xx or 3xx), and they cannot be used to simply check if a TCP port is open without an HTTP server.

Practice this question →

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

Used for slow-starting containers.

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

A failing readiness probe marks the pod as not ready, so the service removes it from endpoints.

Why this answer

A failing readiness probe causes the pod to be removed from the Service's endpoints, so it will not receive traffic. The pod continues running and can be restarted by a liveness probe if configured, but readiness only affects traffic routing.

Practice this question →

MCQmedium

A developer wants to debug a container that has crashed and is no longer running. Which command allows them to start an ephemeral container in the same pod for debugging?

A.kubectl attach <pod>

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

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

D.kubectl exec -it <pod> -- /bin/sh

AnswerB

This creates an ephemeral container in the target pod for debugging.

Why this answer

kubectl debug with the -it flag creates an ephemeral container for debugging. Option A is correct.

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

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

Why this answer

The '-f' flag (follow) allows you to stream logs in real-time.

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 gives more attempts (40*10=400 seconds), providing a safety margin.

Why this answer

The current probe allows 300 seconds (30 * 10) before marking the container as failed. The app needs 300 seconds (5 min), so it's borderline. Increasing failureThreshold gives more tolerance.

Option C is correct.

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

Readiness probes control whether a pod is included in the Service's load balancing pool. If it fails, the pod is removed from endpoints but continues running.

Why this answer

A readiness probe determines if a pod is ready to receive traffic. If it fails, the pod is removed from the Service endpoints, but it continues running.

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

Valid parameter to delay the first probe.

Why this answer

Option B is correct because `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 →

MCQeasy

You need to view the logs of a container named 'sidecar' in a pod called 'app-pod' running in namespace 'dev'. Which command should you use?

A.kubectl logs sidecar -p app-pod -n dev

B.kubectl logs app-pod -n dev

C.kubectl logs app-pod --container=sidecar --namespace=dev

D.kubectl logs app-pod -c sidecar -n dev

AnswerC, D

This command is equivalent to option B; it uses the long-form flags and is also correct.

Why this answer

The correct command is 'kubectl logs app-pod -c sidecar -n dev'. The -c flag specifies the container name when a pod has multiple containers. Option A omits the -c flag.

Options C and D use incorrect flags.

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

This performs a rolling restart, updating pods with the new ConfigMap without downtime.

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

Correct. A TCP socket check only confirms the port is open, not that the application is ready to serve HTTP traffic.

Why this answer

If the readiness probe passes, the pod should be in service endpoints. But if the probe passes incorrectly (e.g., TCP socket check succeeds even if app is not fully ready), the pod might be marked ready but not actually serve traffic. However, the question says readiness probe is TCP on 8080 and app listens on 8080, so it should work.

Another possibility: the pod might have a misconfigured service selector or the pod's labels do not match. But from the options, the most plausible is that the readiness probe is not properly checking application health.

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

Frequent probes can cause kubelet to update iptables often, especially if the probe goes through a 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 →

100

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 correctly implements the requirements using a TCP probe.

Why this answer

Option A is correct because 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 →

101

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

Ephemeral containers allow debugging without modifying the original pod.

Why this answer

Multiple methods exist: exec for interactive shell, logs for output, debug for ephemeral containers. Option B is not a valid command; Option D is for configuration files, not runtime debugging.

Practice this question →

102

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

Correct. Liveness probe restarts the container when it fails.

Why this answer

BackOff restarting failed container indicates that the container exited and is being restarted by the restart policy. This is commonly caused by a failing liveness probe that kills the container, or the container itself exits. The liveness probe is designed to restart unhealthy containers.

Practice this question →

103

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 event shows disk-pressure taints on 3 nodes. The pod cannot tolerate them, so it remains Pending.

Why this answer

The disk-pressure taint on 3 nodes indicates those nodes have disk pressure. The control-plane taint on 1 node is normal. The pod cannot be scheduled because nodes are tainted and the pod does not have corresponding tolerations.

The solution is to either free disk space on the nodes or add tolerations.

Practice this question →

104

MCQeasy

What is the purpose of a readiness probe in Kubernetes?

A.To control whether the pod receives traffic from Services

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

C.To monitor resource usage of the container

D.To restart the container if it becomes unhealthy

AnswerA

A failing readiness probe removes the pod from Service endpoints.

Why this answer

Option B is correct. Readiness probes determine if a container is ready to serve traffic. If they fail, the pod is removed from Service endpoints.

Option A describes liveness probes. Option C describes startup probes. Option D is incorrect.

Practice this question →

105

Multi-Selectmedium

Which TWO of the following are valid types of probes in Kubernetes? (Select 2)

Select 2 answers

A.Liveness probe

B.Survival probe

C.Readiness probe

D.Health probe

E.Startup probe

AnswersA, C

One of the three probe types.

Why this answer

Liveness, readiness, and startup are the three probe types. Option D is not a probe type. Option E is not a standard probe type.

Practice this question →

106

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

Correct. Startup probe delays liveness and readiness probes until the container is fully started.

Why this answer

A startup probe is designed for slow-starting containers. It runs at startup and only after it succeeds does the liveness probe take over.

Practice this question →

107

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 definition for an HTTP GET liveness probe.

Why this answer

A liveness probe using httpGet checks the specified path and port. The correct syntax includes the path and port fields.

Practice this question →

108

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

This outputs the complete YAML definition including status.

Why this answer

Option B is correct because `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 →

109

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

This runs the command 'ls -la /data' inside the pod's first 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 →

110

Multi-Selecthard

Which THREE of the following are valid methods to view logs of a container that has already terminated?

Select 3 answers

A.kubectl logs <pod> --all-containers

B.kubectl logs <pod> --tail=50

C.kubectl logs --all

D.kubectl logs <pod> --previous

E.kubectl logs <pod> -p

AnswersB, D, E

Shows last 50 lines of logs (if container still exists).

Why this answer

Option B is correct because `kubectl logs <pod> --tail=50` retrieves the last 50 lines of logs from the specified pod's container. Even if the container has terminated, the logs are still available from the pod's log history, and `--tail` limits the output to the most recent entries, which is useful for debugging recent failures.

Exam trap

CNCF often tests the distinction between `--previous` (which retrieves logs from a terminated container that has been restarted) and `--tail` (which limits output lines), and candidates may mistakenly think `--all-containers` or `--all` are valid for terminated containers without understanding the need for `--previous`.

Practice this question →

111

MCQhard

You are tasked with debugging a pod that is crashing so quickly that you cannot exec into it. Which approach should you use to gain access to the pod's filesystem?

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

B.kubectl debug <pod> -it --copy-to=<pod>-debug --image=busybox

C.kubectl exec -it <pod> -- /bin/sh

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

AnswerB

Creates a copy of the pod with a debug container, allowing you to explore the filesystem.

Why this answer

Option D is correct. kubectl debug with --copy-to creates a copy of the pod with a sidecar container for debugging. Option A works if the container is running, but not if it crashes immediately. Option B is for running commands in existing containers.

Option C adds an ephemeral container, but the original container may still crash; --copy-to is better for this scenario.

Practice this question →

112

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

This command shows the logs from the previous (crashed) container instance.

Why this answer

Option D is correct because 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 →

113

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

Retrieves kubelet logs via systemd journal.

Why this answer

Option D is correct because `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 →

114

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

Shows events like 'FailedMount' indicating missing storage class.

Why this answer

Option D is correct because `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 →

115

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

Correct. Shows CPU and memory usage.

Why this answer

The kubectl top pod command shows resource usage for pods.

Practice this question →

116

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

Logs provide insight into application behavior during probe failures.

Why this answer

Option D is correct because 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 →

117

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

If the probe times out before the app responds, it will fail and restart the container.

Why this answer

A timeoutSeconds value lower than the application's response time can cause the probe to fail even if the app is healthy. Option C is correct.

Practice this question →

118

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

This shows logs from the previous instance of the container, which is useful for debugging crashes.

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 →

119

Multi-Selectmedium

Which TWO of the following are valid ways to expose application metrics from a Pod in Kubernetes?

Select 2 answers

A.Write metrics to stdout and parse them with a log aggregator.

B.Use kubectl top to collect metrics and expose them via a Service.

C.Create a ServiceMonitor custom resource to push metrics to Prometheus.

D.Expose a /metrics HTTP endpoint and configure Prometheus to scrape it.

E.Use the Kubernetes custom metrics API to expose application-specific metrics.

AnswersD, E

Standard Prometheus metrics exposure.

Why this answer

Option D is correct because exposing a /metrics HTTP endpoint is the standard pattern for Prometheus-based monitoring. Prometheus uses a pull model, where it periodically scrapes metrics from the /metrics endpoint exposed by the application container. This approach is widely adopted in Kubernetes for application observability.

Exam trap

CNCF often tests the distinction between push-based and pull-based monitoring models, and the trap here is that candidates may think ServiceMonitor pushes metrics, when in fact it only configures Prometheus to pull from a target.

Practice this question →

120

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

This command lists events, which are automatically sorted by time.

Why this answer

Option C is correct because `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 →

121

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

This command opens an interactive shell inside the container, allowing you to run commands and inspect processes.

Why this answer

The correct command is 'kubectl exec -it pod-name -- /bin/sh'. The -it flags enable interactive terminal. Option B is for reading logs.

Option C is for debugging with an ephemeral container. Option D is for describing the pod.

Practice this question →

122

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 failing readiness probe removes the pod from Service endpoints.

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 →

123

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

The pod is not ready to serve traffic, so it is removed from the Service.

Why this answer

If a pod fails its readiness probe, it is removed from the Service endpoints. The pod remains running and is not restarted. Option B is correct.

Option A is wrong because liveness probes cause restarts. Option C is incorrect because readiness failure does not decrease replicas. Option D is wrong.

Practice this question →

124

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

Liveness probe failure triggers a container restart according to the restart policy.

Why this answer

When the file is deleted, the exec command fails, causing the liveness probe to fail. After failureThreshold attempts, the container is restarted. Option C is correct.

Practice this question →

125

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 command lists all events sorted by creation time, showing the most recent events last.

Why this answer

The 'kubectl get events --sort-by=.metadata.creationTimestamp' command retrieves all events sorted by creation timestamp. Option A is the correct syntax.

Practice this question →

126

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

A TCP probe only checks if the port is open, not if the application is healthy.

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 →

127

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

Correct. Both taints and node affinity are reported as reasons.

Why this answer

The message indicates multiple issues: taints and node affinity. The pod cannot be scheduled due to taints not being tolerated AND node affinity not matching.

Practice this question →

128

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 gives the container 30 seconds after SIGTERM before SIGKILL is sent.

Why this answer

Option D is correct because `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 →

129

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

Logs may show the application error causing the crash.

Why this answer

Option D is correct because 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 →

130

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 populated by pods matching the selector; if none match, endpoints remain empty.

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 →

131

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

This defines the timeout for each probe.

Why this answer

Option D is correct because `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 →

132

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

Correct. Field selector filters events by the object name.

Why this answer

kubectl get events --field-selector involvedObject.name=my-pod shows events for that pod.

Practice this question →

133

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

This shows the IP addresses of pods backing the service.

Why this answer

Option D is correct because `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 →

134

Multi-Selectmedium

You are designing a health check strategy for a web application. Which TWO probe types should you configure to ensure that traffic is only sent to pods that are ready to serve?

Select 2 answers

A.Readiness probe

B.TCP socket probe

C.Startup probe

D.HTTP GET probe

E.Liveness probe

AnswersA, C

Controls whether a pod is included in service endpoints.

Why this answer

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

Exam trap

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

Practice this question →

135

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

Filters events by the pod name.

Why this answer

Correct answers: B and D. kubectl describe pod shows events for that pod. kubectl get events --field-selector involvedObject.name=<pod> filters events by pod name. Option A shows all events without filtering. Option C does not show events.

Option E is not a valid command.

Practice this question →

136

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

-it provides interactive terminal access.

Why this answer

Option A is correct. kubectl exec with -it flags gives an interactive terminal. Option B does not allocate a TTY. Option C is for ephemeral containers, which is unnecessary.

Option D is incorrect syntax.

Practice this question →

137

MCQeasy

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

A.kubectl logs -f web-pod

B.kubectl logs --previous web-pod

C.kubectl logs --tail web-pod

D.kubectl logs web-pod --all-containers

AnswerA

The -f flag streams logs in real-time.

Why this answer

Option A is correct because `kubectl logs -f web-pod` uses the `-f` (follow) flag to stream logs from the pod in real-time, similar to `tail -f` in Linux. This flag keeps the connection open and continuously outputs new log lines as they are written by the container.

Exam trap

The trap here is that candidates confuse the `--tail` flag (which limits output to recent lines) with the `-f` flag (which streams logs), or assume `--all-containers` implies real-time streaming without the `-f` flag.

How to eliminate wrong answers

Option B is wrong because `kubectl logs --previous web-pod` retrieves logs from the previous instance of a crashed or restarted container, not real-time streaming. Option C is wrong because `kubectl logs --tail web-pod` is incomplete; `--tail` requires an integer (e.g., `--tail=10`) to specify the number of recent log lines to display, and it does not enable streaming. Option D is wrong because `kubectl logs web-pod --all-containers` shows logs from all containers in the pod but does not include the `-f` flag for real-time streaming.

Practice this question →

138

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

Correct. OnFailure restarts on non-zero exit. After multiple failures, it finally succeeded and pod is Completed.

Why this answer

A pod with restartPolicy: OnFailure will restart the container if it exits with a non-zero exit code. The pod is Completed, meaning the container exited with 0 eventually, but previous runs exited with non-zero.

Practice this question →

139

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

This command displays CPU and memory usage for nodes, provided metrics-server is installed.

Why this answer

kubectl top node shows resource usage (CPU and memory) for nodes.

Practice this question →

140

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

Displays CPU and memory usage of pods.

Why this answer

Option A is correct. kubectl top pod shows resource usage. Option B is for nodes. Option C and D are not valid commands.

Practice this question →

141

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

Prometheus is the de facto monitoring solution for Kubernetes.

Why this answer

Option A is correct because 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 →

142

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 metrics provide detailed performance data.

Why this answer

Option B is correct because Prometheus is the standard open-source monitoring and alerting toolkit in the Kubernetes ecosystem. By exposing metrics endpoints on each pod (typically at /metrics) and configuring a Prometheus server to scrape them, you can collect detailed performance data such as request latency, error rates, and resource utilization, which directly helps diagnose high-latency issues.

Exam trap

CNCF often tests the distinction between observability (monitoring, metrics, tracing) and reliability mechanisms (probes, scaling), so candidates mistakenly choose readiness or liveness probes as tools for performance insight instead of recognizing they only ensure basic health and traffic routing.

Practice this question →

143

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

C.Delete and recreate the pod to clear the crash loop

D.Delete the namespace and redeploy all workloads

AnswerA

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

Why this answer

The pod is in CrashLoopBackOff with an OOMKilled message, which indicates the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it has exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

144

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

If no node can satisfy the pod's resource requests, the pod remains unschedulable and shows Pending.

Why this answer

A Pending state typically means the pod cannot be scheduled, often due to insufficient resources or node selector issues. Other options like container crash or readiness failure would result in different states.

Practice this question →

145

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

If the application crashes immediately, it may not output any logs before exiting.

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 →

146

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

Correct. Shows detailed info including events.

Why this answer

kubectl describe pod provides detailed information about a pod.

Practice this question →

147

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

A startup probe delays liveness and readiness checks until the container has started successfully, preventing premature restarts.

Why this answer

Option C is correct because 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 →

148

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 allows the container extra time to start by disabling other probes until it succeeds. This is the recommended approach for slow-starting containers.

Why this answer

A startup probe is designed for slow-starting containers. It runs only during startup and disables liveness and readiness probes until it succeeds.

Practice this question →

149

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 container needs 120 seconds to start, but the liveness probe starts after only 10 seconds. It fails quickly and triggers restarts before the container can fully start.

Why this answer

The liveness probe starts after 10 seconds and will fail repeatedly because the application is not ready. After 3 failures (30 seconds total), the container is restarted, but it still needs ~120 seconds to start, causing a loop. A startup probe should be used to give the container time to start before liveness probes begin.

Practice this question →

150

MCQmedium

A.Delete and recreate the pod to clear the crash loop

B.Increase the memory limit in the pod's container resource specification

C.Increase the CPU request for the container

D.Delete the namespace and redeploy all workloads

AnswerB

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

Why this answer

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

Practice this question →