Knowledge + Practice

CCNA Application Observability and Maintenance Questions

75 of 171 questions · Page 1/3 · Application Observability and Maintenance · Answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

Refer to the exhibit. A pod named 'app-backend-6b4c9d8f7-2x4z5' is in CrashLoopBackOff state. What is the MOST likely cause of this issue?

A.The container is crashing due to a misconfiguration or application error.

B.The container has exceeded its memory limit and is being OOMKilled.

C.The node running the pod is down, preventing the container from starting.

D.A network policy is blocking the container from accessing required services.

AnswerA

CrashLoopBackOff indicates repeated crashes, often from configuration or code issues.

Why this answer

A CrashLoopBackOff state indicates that the container in the pod is repeatedly crashing and being restarted by the kubelet. The most common cause is a misconfiguration (e.g., incorrect environment variables, missing dependencies, or a faulty entrypoint script) or an application error (e.g., a runtime exception or panic). The kubelet detects the crash via the container runtime (e.g., containerd) and applies an exponential backoff delay before restarting, leading to the CrashLoopBackOff status.

Exam trap

CNCF often tests the distinction between CrashLoopBackOff and other pod failure states like OOMKilled or ImagePullBackOff, and the trap here is that candidates may assume any crash is due to resource limits or network issues without checking the specific exit code or pod events.

How to eliminate wrong answers

Option B is wrong because an OOMKilled container would show a status of 'OOMKilled' in the pod's last state, not CrashLoopBackOff; CrashLoopBackOff is a generic restart loop, not a specific resource limit violation. Option C is wrong because if the node were down, the pod would be in 'NodeLost' or 'Unknown' state, and the kubelet would not be able to restart the container; CrashLoopBackOff requires the kubelet to be actively managing the pod. Option D is wrong because a network policy blocking access would cause the application to fail to connect to services, but the container itself would still start and run (possibly with errors), not crash immediately; CrashLoopBackOff implies the container process exits with a non-zero code at startup.

Practice this question →

2

MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' Which action should you take?

A.Increase the CPU limits on the pod to give it more resources.

B.Reduce the CPU request of the pod and reapply the manifest.

C.Add another node to the cluster to increase overall CPU capacity.

D.Add a nodeSelector to the pod to target a specific node.

AnswerB

Lowering CPU request may allow the pod to fit on a node with available CPU.

Why this answer

The pod is stuck in 'Pending' because the scheduler cannot find a node with enough allocatable CPU to satisfy the pod's CPU request. Reducing the CPU request (the amount guaranteed to the container) makes the pod schedulable on existing nodes. Increasing limits would only worsen the problem, as limits are a cap on usage, not a scheduling constraint.

Exam trap

The trap here is that candidates confuse CPU requests with CPU limits, assuming that increasing limits gives the pod more resources, when in fact the scheduler only checks requests for admission, and limits are a runtime constraint.

How to eliminate wrong answers

Option A is wrong because increasing CPU limits does not affect scheduling; the scheduler only considers requests, not limits. Option C is wrong because adding a node is an operational overhead and not the immediate fix; the issue is that the pod's request is too high for the current cluster capacity. Option D is wrong because a nodeSelector targets a specific node but does not resolve the underlying resource insufficiency; if no node has enough CPU, the pod will still remain Pending.

Practice this question →

3

MCQeasy

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

A.Readiness probe

B.Resource limits

C.Startup probe

D.Liveness probe

AnswerA

Correct. Readiness probe indicates whether the container is ready to serve traffic; failure removes the pod from service backends.

Why this answer

A readiness probe determines if a container is ready to serve traffic. If it fails, the pod is removed from service endpoints.

Practice this question →

4

Matchingmedium

Match each Kubernetes object field to its description.

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

Concepts

Matches

Maximum resources a container can use

Determines when to restart containers in a pod

Checks if container is running; restarts if fails

Checks if container is ready to serve traffic

Inject a secret value as an environment variable

Why these pairings

These fields are essential for pod configuration and health checks.

Practice this question →

5

MCQeasy

A DevOps engineer needs to set up resource monitoring for pods in a namespace. Which built-in Kubernetes resource provides CPU and memory metrics out-of-the-box?

A.Metrics Server

B.Prometheus

C.CoreDNS

D.Kubernetes Dashboard

AnswerA

Built-in cluster addon for resource metrics.

Why this answer

The Metrics Server is the built-in Kubernetes resource that collects resource metrics (CPU and memory) from the kubelet on each node via the Summary API and exposes them through the metrics.k8s.io API. It provides these metrics out-of-the-box without requiring any additional configuration or external storage, making it the standard solution for horizontal pod autoscaling and kubectl top commands.

Exam trap

CNCF often tests the distinction between built-in Kubernetes components and third-party add-ons, so candidates may mistakenly choose Prometheus because it is a popular monitoring tool, but the question specifically asks for a built-in resource that provides metrics out-of-the-box.

How to eliminate wrong answers

Option B is wrong because Prometheus is a third-party monitoring system that is not built into Kubernetes; it requires separate installation and configuration, and while it can scrape metrics, it is not the built-in resource for CPU and memory metrics. Option C is wrong because CoreDNS is a DNS server for service discovery within the cluster, not a metrics provider; it has no capability to expose CPU or memory metrics. Option D is wrong because Kubernetes Dashboard is a web UI for managing the cluster, not a metrics source; it relies on the Metrics Server or another backend to display resource usage data.

Practice this question →

6

Multi-Selecthard

Which TWO of the following are true about the 'kubectl describe pod' output? (Select 2)

Select 3 answers

A.It shows the exact resource requests and limits of each container

B.It shows the last few lines of the container logs

C.It shows recent events related to the pod

D.It shows the current CPU and memory usage of the pod

E.It shows the node name where the pod is scheduled

AnswersA, C, E

kubectl describe pod shows both requests and limits.

Why this answer

kubectl describe shows events related to the pod and the container state. Option A is wrong because it shows resource limits, not just requests. Option D is incorrect because it does not show logs.

Practice this question →

7

MCQeasy

What is the purpose of a readiness probe?

A.To restart the container if it becomes unresponsive

B.To indicate whether the container is ready to serve traffic

C.To indicate that the container has started successfully

D.To measure the resource usage of the container

AnswerB

Readiness probe determines if traffic should be sent to the pod.

Why this answer

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

Exam trap

The trap here is confusing readiness probes with liveness probes, as both are health checks, but readiness probes control traffic routing while liveness probes trigger container restarts.

How to eliminate wrong answers

Option A is wrong because restarting an unresponsive container is the purpose of a liveness probe, not a readiness probe. Option C is wrong because indicating that the container has started successfully is the purpose of a startup probe, which is used for slow-starting containers to delay liveness checks. Option D is wrong because measuring resource usage is done by metrics servers or resource monitoring tools (e.g., cAdvisor, Prometheus), not by probes.

Practice this question →

8

Matchingmedium

Match each Kubernetes resource to its API group.

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

Concepts

Matches

apps/v1

v1 (core)

networking.k8s.io/v1

autoscaling/v2

networking.k8s.io/v1

Why these pairings

Knowing API groups is important for writing correct manifests.

Practice this question →

9

MCQhard

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

A.kubectl attach <pod>

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

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

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

AnswerD

This attaches a debug container (ephemeral container) to the pod, allowing debugging without modifying the original container.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

10

Multi-Selecteasy

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

Select 2 answers

A.kubectl debug -it <pod> --image=busybox -- sh

B.kubectl run debug --image=busybox -- sh

C.Adding an ephemeral container to the pod's spec under ephemeralContainers

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

E.kubectl attach to the pod

AnswersA, C

Creates an ephemeral container with busybox for debugging.

Why this answer

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

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 also mistakenly think `kubectl run` or `kubectl attach` can inject a debug container into a running pod.

Practice this question →

11

Multi-Selectmedium

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

Select 3 answers

A.The default value is 30 seconds

B.It gives the container time to shut down gracefully after receiving SIGTERM

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

D.The default value is 0 seconds

E.It is used to configure the readiness probe timeout

AnswersA, B, C

Correct: default is 30.

Why this answer

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

Exam trap

CNCF often tests the exact default value (30 seconds) and the distinction between SIGTERM (graceful) and SIGKILL (forceful), so candidates must not confuse terminationGracePeriodSeconds with probe settings like readiness or liveness probe timeouts.

Practice this question →

12

MCQhard

You deploy a pod with the following specification: apiVersion: v1 kind: Pod metadata: name: probe-pod spec: containers: - name: app image: nginx livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 3 The application listens on port 80, not 8080. What will happen to the pod?

A.The pod will be terminated and not restarted

B.The pod will start and run normally

C.The container will be restarted repeatedly due to liveness probe failure

D.The pod will be stuck in 'Pending' state

AnswerC

Correct. The liveness probe will fail, causing restarts.

Why this answer

The liveness probe will fail because it checks port 8080 but the app listens on 80. After failureThreshold failures (3 * periodSeconds = 30 seconds after initial delay), the container will be restarted.

Practice this question →

13

MCQmedium

You have a pod with two containers: 'web' and 'sidecar'. You want to view the logs of only the 'sidecar' container. Which command should you use?

A.kubectl logs pod-name -c sidecar

B.kubectl attach pod-name -c sidecar

C.kubectl logs pod-name

D.kubectl logs pod-name --container sidecar

AnswerA

The -c flag specifies which container's logs to show.

Why this answer

Option A is correct because `kubectl logs pod-name -c sidecar` explicitly specifies the container name within the pod using the `-c` flag, allowing you to view logs from only the 'sidecar' container. In Kubernetes, when a pod contains multiple containers, you must specify the container name to isolate logs from a particular container.

Exam trap

The trap here is that candidates may confuse the `-c` flag with `--container` and use an incorrect syntax, or they may forget that multi-container pods require explicit container specification, leading them to choose the ambiguous `kubectl logs pod-name` option.

How to eliminate wrong answers

Option B is wrong because `kubectl attach` attaches to a running container's standard input/output streams, not to its logs; it is used for interactive debugging, not for viewing historical log output. Option C is wrong because `kubectl logs pod-name` without the `-c` flag will fail if the pod has more than one container, as Kubernetes requires explicit container selection to avoid ambiguity. Option D is wrong because `--container sidecar` is not a valid flag; the correct flag is `-c sidecar` or `--container=sidecar` (with an equals sign), and the provided syntax `--container sidecar` is incorrect and will cause a parsing error.

Practice this question →

14

MCQmedium

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

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

B.Increase the CPU request for the container

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

D.Delete the namespace and redeploy all workloads

AnswerC

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

OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. Increasing the memory limit in the container's resource specification is the appropriate fix.

Practice this question →

15

MCQeasy

You have a pod 'app-pod' that keeps restarting. You want to see the logs from the previous (crashed) container instance. Which command should you use?

A.kubectl logs app-pod --previous

B.kubectl logs app-pod -p

C.kubectl logs app-pod -f

D.kubectl describe pod app-pod

AnswerA

Correct. --previous shows logs from the last terminated container.

Why this answer

The --previous flag shows logs from the previous instance of a container.

Practice this question →

16

MCQmedium

A pod named 'web-app' is experiencing high CPU usage. You want to investigate which process inside the container is consuming the most CPU. Which command should you run?

A.kubectl logs -f web-app

B.kubectl exec web-app -- top

C.kubectl describe node

D.kubectl top pod web-app

AnswerB

Executes 'top' inside the container, showing per-process CPU usage.

Why this answer

Option B is correct because `kubectl exec web-app -- top` runs the `top` command inside the container of the pod 'web-app', which displays real-time process-level CPU usage. This allows you to identify the specific process consuming the most CPU, directly addressing the question's requirement to investigate inside the container.

Exam trap

The trap here is that candidates confuse `kubectl top pod` (which shows pod-level resource usage) with the ability to inspect processes inside the container, leading them to choose Option D instead of using `kubectl exec` to run a process inspection command like `top`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs -f web-app` streams the container's stdout/stderr logs, which do not show process-level CPU usage or running processes. Option C is wrong because `kubectl describe node` provides node-level resource allocation and conditions, not process-level details inside a specific pod's container. Option D is wrong because `kubectl top pod web-app` shows aggregate CPU and memory usage of the pod's containers, but does not reveal individual processes inside the container.

Practice this question →

17

Multi-Selectmedium

Which TWO of the following are valid liveness probe types in Kubernetes?

Select 2 answers

A.command

B.tcpSocket

C.portCheck

D.httpGet

E.grpc

AnswersB, D

Valid liveness probe type.

Why this answer

The valid liveness probe types are httpGet, tcpSocket, exec, and grpc. gRPC is also valid since v1.24.

Practice this question →

18

Multi-Selecthard

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

Select 2 answers

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

B.Check resource usage with 'kubectl top pod'

C.Use 'kubectl debug' to start an ephemeral container for troubleshooting

D.View logs from the previous container instance with 'kubectl logs --previous'

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

AnswersC, D

kubectl debug can add an ephemeral container to the pod even if the main container is crashing.

Why this answer

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

Exam trap

CNCF often tests the distinction between 'kubectl exec' (requires a running container) and 'kubectl debug' (works even when the container is crashing), and candidates mistakenly think exec can be used on a CrashLoopBackOff pod.

Practice this question →

19

MCQeasy

A deployment 'web-app' is running with 3 replicas. Users report that the application is slow. The team suspects a memory leak. Which command provides the most immediate insight into the memory usage of the pods?

A.kubectl describe deployment web-app

B.kubectl get events

C.kubectl logs <pod>

D.kubectl top pod

AnswerD

Shows real-time CPU and memory usage per pod.

Why this answer

Option D is correct because `kubectl top pod` directly queries the metrics server to display real-time CPU and memory usage for each pod, providing the most immediate insight into whether a pod is consuming excessive memory due to a suspected leak. Unlike logs or events, it gives quantitative resource utilization data without requiring additional configuration or parsing.

Exam trap

The trap here is that candidates may choose `kubectl logs` thinking application logs will reveal memory leak details, but logs only show application output, not raw memory metrics, and `kubectl top pod` is the standard tool for immediate resource usage insight.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment web-app` shows the deployment's configuration and status, not the actual runtime memory usage of individual pods. Option B is wrong because `kubectl get events` lists cluster events (e.g., scheduling failures, restarts) but does not provide memory usage metrics. Option C is wrong because `kubectl logs <pod>` outputs application logs, which may contain memory-related error messages but do not give direct, real-time memory consumption numbers.

Practice this question →

20

MCQmedium

You need to debug a pod that is crashing immediately upon start. You cannot exec into the container because it exits before you can run commands. Which approach should you use to inspect the container's file system?

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

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

C.kubectl logs pod-name --previous

D.kubectl describe pod pod-name

AnswerA

The debug command creates an ephemeral container that can share the same process namespace or volumes as the crashed container, allowing inspection.

Why this answer

The 'kubectl debug' command with an ephemeral container allows you to attach a debug container to a running pod, even if the original container is not running. You can share the process namespace or mount volumes to inspect files. Option A is not possible if the container crashes.

Option C shows configuration, not runtime state. Option D is for logs, not filesystem.

Practice this question →

21

Multi-Selectmedium

Which THREE of the following are valid parameters for configuring probes? (Select 3)

Select 3 answers

A.retryIntervalSeconds

B.timeoutSeconds

C.cooldownSeconds

D.initialDelaySeconds

E.periodSeconds

AnswersB, D, E

Valid probe parameter.

Why this answer

initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, and successThreshold are all valid. The correct three are A, B, C.

Practice this question →

22

MCQmedium

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

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

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

C.Delete the namespace and redeploy all workloads

D.Increase the CPU request for the container

AnswerA

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

Why this answer

The 'OOMKilled' status indicates the pod's container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, a gradual memory leak or increased workload likely caused the usage to spike past the configured limit. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory demand without being killed, resolving the CrashLoopBackOff.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

23

Multi-Selecthard

Which THREE of the following are best practices for configuring readiness probes?

Select 3 answers

A.Use the same endpoint as the liveness probe

B.Configure the probe to restart the container if it fails

C.Set initialDelaySeconds to avoid startup race conditions

D.Use a separate endpoint from the liveness probe

E.Use an HTTP GET request to a lightweight endpoint

AnswersC, D, E

Gives the app time to start before probing.

Why this answer

Option C is correct because setting `initialDelaySeconds` in a readiness probe prevents the probe from starting before the container's application has had time to initialize. Without this delay, the probe might fail immediately during startup, causing the container to be prematurely marked as not ready and removed from service, even though the application would have become ready given a few more seconds. This avoids race conditions between container startup and probe evaluation.

Exam trap

The trap here is that candidates confuse readiness probes with liveness probes, mistakenly thinking readiness probes can restart containers or that sharing the same endpoint is acceptable, when in fact readiness probes only control traffic routing and should use a separate, dependency-aware endpoint.

Practice this question →

24

MCQeasy

Which probe type is used to indicate that a container is ready to serve traffic and should be added to Service endpoints?

A.Readiness probe

B.Liveness probe

C.Startup probe

D.Both liveness and readiness probes

AnswerA

Readiness probes indicate whether the container is ready to serve traffic.

Why this answer

Readiness probes determine if a pod is ready to receive traffic. Option A is correct.

Practice this question →

25

MCQhard

You have a pod with two containers: app and sidecar. The sidecar logs are verbose and you want to view only the app container logs. Which command should you use?

A.kubectl logs pod-name --container app

B.kubectl logs pod-name

C.kubectl logs pod-name -c app

D.kubectl logs -l app=pod-name

AnswerC

The -c flag selects the specific container to view logs from.

Why this answer

Use the -c flag to specify the container name when a pod has multiple containers.

Practice this question →

26

MCQeasy

A developer needs to view the logs of a pod named 'web-app-84b7f6f5b6-abcde' that crashed and has been restarted. Which kubectl command should they use to see the logs from the previous (crashed) instance?

A.kubectl logs web-app-84b7f6f5b6-abcde

B.kubectl logs --all-containers web-app-84b7f6f5b6-abcde

C.kubectl logs --previous web-app-84b7f6f5b6-abcde

D.kubectl logs -f web-app-84b7f6f5b6-abcde

AnswerC

The --previous flag retrieves logs from the previous instance of the container.

Why this answer

Option C is correct. The --previous flag in 'kubectl logs' shows logs from the previous instance of a container, which is useful for debugging crashes. Option A shows current logs only.

Option B tails logs but only current. Option D shows logs for all containers, but not the previous instance.

Practice this question →

27

MCQmedium

Which command outputs the pod's full YAML specification including status?

A.kubectl describe pod <pod-name>

B.kubectl get pod <pod-name> --export

C.kubectl get pod <pod-name> -o json

D.kubectl get pod <pod-name> -o yaml

AnswerD

This outputs the pod's full YAML manifest including status.

Why this answer

kubectl get pod <pod-name> -o yaml outputs the complete YAML. Option A is correct.

Practice this question →

28

MCQhard

You are asked to ensure that a pod with a slow-starting container (requires 60 seconds to initialize) is not prematurely restarted by the liveness probe. The liveness probe should start only after the container is fully initialized. Which probe type should you add to the pod spec?

A.startupProbe

B.readinessProbe

C.livenessProbe with initialDelaySeconds=60

D.lifecycle preStop hook

AnswerA

Startup probes are specifically for slow-starting containers. They delay liveness probes until the startup probe succeeds.

Why this answer

A startupProbe is specifically designed for slow-starting containers. It runs at pod startup and only after it succeeds does the liveness probe begin. This prevents the liveness probe from restarting the container during its 60-second initialization period, as the startupProbe will keep failing until the container is fully ready.

Exam trap

CNCF often tests the misconception that initialDelaySeconds on a liveness probe is sufficient for slow-starting containers, but the trap is that initialDelaySeconds is a fixed delay that does not account for variable startup times, whereas a startupProbe dynamically waits until the container is actually ready.

How to eliminate wrong answers

Option B is wrong because a readinessProbe controls whether the pod receives traffic, not whether the container is restarted; it does not prevent the liveness probe from killing the container during initialization. Option C is wrong because initialDelaySeconds only delays the first liveness probe check by 60 seconds, but if the container takes exactly 60 seconds to initialize and the probe fires immediately after, a single slow response could still trigger a restart; moreover, initialDelaySeconds is a static delay and does not adapt to variable startup times. Option D is wrong because a lifecycle preStop hook runs before a container is terminated, not at startup, and has no effect on preventing premature restarts during initialization.

Practice this question →

29

MCQmedium

You want to ensure your containerized application handles SIGTERM gracefully and shuts down within 30 seconds. Which field should you set in the Pod spec?

A.terminationPeriodSeconds

B.terminationGracePeriodSeconds

C.shutdownTimeoutSeconds

D.gracefulShutdownPeriod

AnswerB

Defines the time given for graceful shutdown after SIGTERM.

Why this answer

Option B is correct because `terminationGracePeriodSeconds` is the Pod spec field that controls the duration Kubernetes waits between sending a SIGTERM signal to the container and forcibly killing it with SIGKILL. Setting this to 30 seconds ensures the application has up to 30 seconds to perform cleanup and shut down gracefully after receiving SIGTERM.

Exam trap

The trap here is that candidates confuse the generic concept of a 'grace period' with the exact Kubernetes field name, often picking a plausible-sounding but non-existent field like `shutdownTimeoutSeconds` or `gracefulShutdownPeriod` instead of the precise `terminationGracePeriodSeconds`.

How to eliminate wrong answers

Option A is wrong because `terminationPeriodSeconds` is not a valid Kubernetes field; the correct field name is `terminationGracePeriodSeconds`. Option C is wrong because `shutdownTimeoutSeconds` is not a Kubernetes Pod spec field; it does not exist in the API. Option D is wrong because `gracefulShutdownPeriod` is not a Kubernetes Pod spec field; it is a generic term that might be used in other orchestrators or application configurations, but not in Kubernetes.

Practice this question →

30

MCQmedium

You have a Deployment running a web application that takes 60 seconds to start up. You need to configure probes so that Kubernetes waits for the application to fully start before checking its health and directing traffic to it. Which combination of probes should you use?

A.Liveness probe with initialDelaySeconds=10 and readiness probe without delay

B.Readiness probe with initialDelaySeconds=60 only

C.Liveness probe with initialDelaySeconds=60 and readiness probe with initialDelaySeconds=60

D.Startup probe with failureThreshold=30 and periodSeconds=2, plus liveness and readiness probes

AnswerD

The startup probe gives the container up to 60 seconds to start (30×2s), after which liveness and readiness probes take over.

Why this answer

Option D is correct because a startup probe with a low failureThreshold and periodSeconds allows Kubernetes to wait up to 60 seconds (30 failures × 2 seconds) for the application to start, after which the liveness and readiness probes begin. This ensures the liveness probe does not kill the container prematurely during the slow startup, and the readiness probe only directs traffic once the app is fully ready.

Exam trap

The trap here is that candidates often rely solely on initialDelaySeconds for liveness probes, not realizing that a startup probe provides a more robust mechanism for slow-starting containers by decoupling the startup grace period from the regular health-check cycle.

How to eliminate wrong answers

Option A is wrong because a liveness probe with initialDelaySeconds=10 would start checking health after only 10 seconds, likely killing the container before the 60-second startup completes. Option B is wrong because a readiness probe with initialDelaySeconds=60 alone does not protect against the liveness probe killing the container during startup; the liveness probe would still start immediately and fail. Option C is wrong because setting both liveness and readiness probes with initialDelaySeconds=60 still allows the liveness probe to start after 60 seconds, but if the app takes exactly 60 seconds, the first liveness check might fail and restart the container; a startup probe provides a more flexible grace period.

Practice this question →

31

Multi-Selectmedium

Which THREE of the following are valid parameters for a probe?

Select 3 answers

A.maxRetries

B.initialDelaySeconds

C.timeoutSeconds

D.backoffSeconds

E.periodSeconds

AnswersB, C, E

Valid parameter.

Why this answer

initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, successThreshold are all valid probe parameters.

Practice this question →

32

Multi-Selectmedium

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

Select 2 answers

A.Readiness probe

B.HTTP probe

C.Liveness probe

D.Exec probe

E.TCP probe

AnswersA, C

Correct: readiness is a probe type.

Why this answer

A is correct because a Readiness probe determines whether a Pod is ready to serve traffic. If the probe fails, the Pod is removed from the Service's endpoints, preventing traffic from being routed to an unready container. This is essential for rolling updates and graceful shutdowns.

Exam trap

The trap here is that candidates confuse the probe types (liveness, readiness, startup) with the handler mechanisms (HTTP, TCP, exec), leading them to select handler names as if they were probe types.

Practice this question →

33

MCQhard

An application pod is logging sensitive data (e.g., passwords) to stdout. The security team requires that these logs be redacted before they are stored. Which approach should you recommend?

A.Set the log level to ERROR only to reduce verbosity and avoid logging sensitive data.

B.Add a sidecar container that reads the application's log file, redacts sensitive data, and writes to stdout.

C.Configure a LogCollector DaemonSet to filter logs at the node level.

D.Modify the application code to stop logging sensitive data before redeploying.

AnswerB

Sidecar pattern allows log processing before storage, and is a common pattern in Kubernetes.

Why this answer

Option B is correct because a sidecar container can share the application's log file via an emptyDir volume, read the raw logs, apply redaction logic (e.g., regex replacement of password patterns), and then output the sanitized logs to its own stdout. This approach satisfies the security requirement without modifying the application code or losing log verbosity, and it keeps the redaction logic decoupled from the main container.

Exam trap

CNCF often tests the sidecar pattern as the preferred method for modifying or enriching log output without altering the primary application container, and the trap here is that candidates may incorrectly choose to modify application code (Option D) or rely on node-level filtering (Option C), both of which violate the principle of separation of concerns or introduce latency and security gaps.

How to eliminate wrong answers

Option A is wrong because reducing the log level to ERROR only suppresses lower-severity messages but does not guarantee that sensitive data won't appear in ERROR-level logs; it also discards useful debug/info logs, violating observability best practices. Option C is wrong because a DaemonSet-based LogCollector operates at the node level, reading container stdout/stderr after it has already been written; it cannot intercept and redact logs before they are stored without complex post-processing and potential data leakage in transit. Option D is wrong because modifying application code requires a full development cycle, testing, and redeployment, which is slower and riskier than a sidecar-based solution; the question asks for a recommendation that avoids code changes.

Practice this question →

34

Multi-Selectmedium

Which TWO statements about readiness probes are correct? (Choose two.)

Select 2 answers

A.Readiness probes are only used during initial startup

B.Readiness probes run continuously after the container starts

C.Readiness probes can only be of type httpGet

D.Readiness probes restart the container if they fail

E.If a readiness probe fails, the pod is removed from all Service endpoints

AnswersB, E

They run periodically according to the probe configuration.

Why this answer

Option B is correct because readiness probes are designed to run continuously throughout the lifecycle of a container, not just during startup. They are periodically executed by the kubelet to determine whether the container is ready to accept traffic, and their success or failure directly controls the pod's inclusion in Service endpoints.

Exam trap

The trap here is confusing readiness probes with liveness probes, leading candidates to incorrectly think readiness probes restart containers or are only used at startup, when in fact readiness probes manage traffic routing without restarting the pod.

Practice this question →

35

MCQmedium

Which field in the container spec controls the time Kubernetes waits after sending SIGTERM before sending SIGKILL during pod shutdown?

A.timeoutSeconds

B.periodSeconds

C.terminationGracePeriodSeconds

D.activeDeadlineSeconds

AnswerC

This field sets the grace period for the container to shut down gracefully after SIGTERM.

Why this answer

terminationGracePeriodSeconds specifies the duration after SIGTERM before SIGKILL is sent.

Practice this question →

36

Multi-Selectmedium

Which TWO of the following are valid types of probes in Kubernetes?

Select 2 answers

A.Survival probe

B.Startup probe

C.Liveness probe

D.Health probe

E.Readiness probe

AnswersC, E

A liveness probe checks if a container is still running.

Why this answer

The three standard probe types are liveness, readiness, and startup. Health is not a probe type, and survival is not a Kubernetes probe.

Practice this question →

37

MCQhard

A pod has a readiness probe using tcpSocket on port 3306. The application listens on port 3306 but returns errors on database queries. What is the effect of the readiness probe?

A.The pod will be evicted from the node

B.The pod will be considered ready as long as the TCP port is open, even if the application is not fully functional

C.The pod will be marked not ready because the application returns errors

D.The container will be restarted due to readiness probe failure

AnswerB

tcpSocket probes only check if the port is accepting connections; they do not validate application-level health.

Why this answer

A readiness probe with tcpSocket only checks whether the TCP port is open and accepting connections. It does not verify application-level health, such as whether the application can process queries or return valid responses. Since port 3306 is open, the probe succeeds, and the pod is considered ready, even though the application returns errors on database queries.

Exam trap

The trap here is that candidates often assume readiness probes check application health or error responses, but a tcpSocket probe only verifies that the port is open, not that the application is working correctly.

How to eliminate wrong answers

Option A is wrong because readiness probe failures do not cause pod eviction; eviction is related to node resource pressure or taints, not probe results. Option C is wrong because a tcpSocket readiness probe does not evaluate application-level errors; it only checks if the TCP handshake succeeds on the specified port. Option D is wrong because readiness probe failures do not restart the container; only liveness probe failures trigger container restarts.

Practice this question →

38

Multi-Selecthard

Which TWO of the following are valid reasons for using a startup probe?

Select 2 answers

A.To monitor the health of a container after it has started

B.To prevent unnecessary restarts during initial startup

C.To provide additional logging for the container

D.To replace the need for a readiness probe

E.To delay the start of liveness and readiness probes for slow-starting containers

AnswersB, E

By disabling liveness probes during startup, the startup probe prevents premature restarts.

Why this answer

Startup probes are used for containers that take a long time to start and need to delay liveness and readiness probes. They are not used for containers that start quickly.

Practice this question →

39

MCQeasy

A pod is in CrashLoopBackOff state. You need to view the last few lines of its logs to understand why it is crashing. Which command is most appropriate?

A.kubectl logs -f my-pod

B.kubectl logs my-pod

C.kubectl logs my-pod --tail=20

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

AnswerC

Shows only the last 20 lines, ideal for recent errors.

Why this answer

The `--tail=20` flag limits the output to the last 20 lines of the pod's logs, which is the most efficient way to see the recent crash-related errors without scrolling through the entire log history. In a CrashLoopBackOff state, the pod is repeatedly restarting, so viewing the tail of the logs directly shows the most recent failure messages, which is the standard diagnostic approach.

Exam trap

CNCF often tests the distinction between `kubectl logs` and `kubectl logs -f`, where candidates mistakenly choose the `-f` option thinking it shows 'the last few lines' because of the 'follow' concept, but `-f` actually streams new logs and does not limit output to a specific number of lines.

How to eliminate wrong answers

Option A is wrong because `kubectl logs -f` follows (tails) the log stream continuously, which is useful for real-time monitoring but not for viewing the last few lines of a crashed pod's logs; it will hang waiting for new output that may never come if the pod is not actively logging. Option B is wrong because `kubectl logs my-pod` without `--tail` will output the entire log history, which can be excessively long and inefficient for quickly identifying the crash cause, especially in pods with many restarts. Option D is wrong because `kubectl get events` shows cluster events (e.g., scheduling, pulling images) but does not display the application's stdout/stderr logs; it provides operational context but not the specific error messages from the crashing container.

Practice this question →

40

MCQhard

You are a platform engineer managing a production Kubernetes cluster. A team deploys a stateful application called 'inventory-service' with 3 replicas using a StatefulSet. Each pod writes logs to a persistent volume via a PersistentVolumeClaim. Recently, the team reports that the application becomes unresponsive after running for a few hours. You notice that the pods are still running (READY 1/1) but the application does not respond to HTTP requests. You exec into one pod and find that the disk is 100% full. The PVC is backed by a cloud disk (e.g., AWS EBS). You check the pod's resource limits and see that memory and CPU are not exhausted. The container logs are not rotated. Which course of action should you take to resolve the immediate issue and prevent recurrence?

A.Increase the size of the PVC to provide more disk space, and configure log rotation inside the container to limit log file size

B.Add a sidecar container that compresses and archives logs to a remote storage every hour

C.Change the application to log to stdout and configure Docker log rotation on the host

D.Configure a log rotation sidecar that writes logs to an emptyDir volume with size limit

AnswerA

Immediate relief via resizing; prevention via log rotation.

Why this answer

Option A is correct because the immediate issue is a full disk caused by unrotated logs. Increasing the PVC size provides temporary relief, while configuring log rotation inside the container (e.g., using logrotate or the application's own rotation) prevents the disk from filling up again. This directly addresses the root cause without changing the application's logging behavior or introducing unnecessary sidecars.

Exam trap

CNCF often tests the distinction between logs written to stdout (handled by container runtime) versus logs written to a file inside the container (which require explicit rotation or external management).

How to eliminate wrong answers

Option B is wrong because compressing and archiving logs to remote storage does not free disk space on the local PVC; the logs remain on disk until deleted, so the disk will still fill up. Option C is wrong because changing the application to log to stdout and configuring Docker log rotation on the host does not affect logs written to a persistent volume; the application is writing logs to a file inside the container, not to stdout. Option D is wrong because using an emptyDir volume with a size limit would only cap the sidecar's own log storage, not the application's logs written to the PVC; the application's logs would still fill the PVC.

Practice this question →

41

MCQhard

A pod is running but the application inside is not serving traffic. The team runs 'kubectl exec -it <pod> -- curl localhost:8080' and gets 'Connection refused'. What is the most likely cause?

A.Container logs are full and writing to disk is slow

B.NetworkPolicy is blocking traffic

C.Application is not listening on port 8080

D.Liveness probe is failing and restarting the container

AnswerC

Connection refused indicates nothing listening on that port.

Why this answer

The 'Connection refused' error from curl indicates that the TCP connection to port 8080 was actively rejected by the kernel, meaning no process is listening on that port inside the container. This is most commonly caused by the application not starting, crashing before binding, or being configured to listen on a different port (e.g., 3000, 8443). The error is immediate and does not suggest a timeout or network-level block.

Exam trap

CNCF often tests the distinction between 'Connection refused' (no listener) and 'Connection timed out' (network block) — candidates mistakenly attribute the error to NetworkPolicy or resource issues, but the immediate RST is a definitive sign of a missing socket, not a network filter.

How to eliminate wrong answers

Option A is wrong because full container logs or slow disk writes would cause performance degradation or write errors, not a TCP 'Connection refused' — the kernel would still accept the connection if a socket is listening. Option B is wrong because NetworkPolicy operates at the network layer (iptables/eBPF) to allow or deny traffic between pods, but 'kubectl exec' runs inside the pod's network namespace, bypassing NetworkPolicy entirely; a NetworkPolicy cannot block localhost traffic. Option D is wrong because a failing liveness probe would cause the container to be restarted, but during the restart window the application might briefly be unavailable; however, 'Connection refused' is a persistent socket-level rejection, not a transient restart behavior, and a failing probe would also show events or crash loop status, not just a curl error.

Practice this question →

42

MCQmedium

You run 'kubectl get pods -o wide' and see that a pod's NODE column shows 'node-1'. You want to see more details about that node's resource usage. Which command should you use?

A.kubectl top pods --all-namespaces

B.kubectl describe node node-1

C.kubectl top pod node-1

D.kubectl top node node-1

AnswerD

This shows CPU and memory usage for the specified node.

Why this answer

Option D is correct because `kubectl top node node-1` directly displays real-time resource usage (CPU and memory) for the specified node, which is exactly what you need when you want to see more details about a node's resource consumption after identifying the node from `kubectl get pods -o wide`.

Exam trap

The trap here is that candidates confuse `kubectl top node` with `kubectl top pod` or `kubectl describe node`, mistakenly thinking that `describe` provides real-time resource usage or that `top pod` can target a node by name.

How to eliminate wrong answers

Option A is wrong because `kubectl top pods --all-namespaces` shows resource usage for pods across all namespaces, not for a specific node. Option B is wrong because `kubectl describe node node-1` shows detailed metadata, conditions, and capacity of the node, but not real-time resource usage metrics like CPU and memory consumption. Option C is wrong because `kubectl top pod node-1` attempts to get resource usage for a pod named 'node-1', not for a node; the command syntax is invalid for node-level metrics.

Practice this question →

43

Multi-Selecthard

Which THREE of the following are valid fields for configuring a probe in Kubernetes? (Select 3)

Select 3 answers

A.initialDelaySeconds

B.retrySeconds

C.intervalSeconds

D.periodSeconds

E.timeoutSeconds

AnswersA, D, E

Number of seconds after the container starts before the probe begins.

Why this answer

Option A is correct because `initialDelaySeconds` is a valid field in a Kubernetes probe configuration (e.g., livenessProbe, readinessProbe, startupProbe). It defines the number of seconds after the container has started before the probe is initiated, allowing the application time to initialize before health checks begin.

Exam trap

The trap here is that candidates confuse `intervalSeconds` with `periodSeconds` and `retrySeconds` with `failureThreshold`, as the incorrect options sound plausible but do not exist in the Kubernetes API specification.

Practice this question →

44

MCQmedium

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

A.50 seconds

B.10 seconds

C.30 seconds

D.60 seconds

AnswerA

failureThreshold * periodSeconds = 10 * 5 = 50 seconds.

Why this answer

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

Exam trap

The trap here is that candidates often forget to multiply `failureThreshold` by `periodSeconds` and instead pick a single value (like 10 or 5) or add them, missing the core formula for probe timeout calculation.

How to eliminate wrong answers

Option B (10 seconds) is wrong because it incorrectly assumes the `failureThreshold` alone (10) is the time limit, ignoring the `periodSeconds` multiplier. Option C (30 seconds) is wrong because it might result from multiplying `failureThreshold` (10) by a mistaken `periodSeconds` of 3, or from adding the two values (10+5=15) and doubling, but it does not match the correct product of 10*5=50. Option D (60 seconds) is wrong because it likely comes from misreading `periodSeconds` as 6 or adding an extra 10 seconds; the correct calculation is strictly `failureThreshold * periodSeconds`.

Practice this question →

45

Multi-Selecthard

Which THREE of the following are valid reasons to use a startup probe? (Select THREE.)

Select 3 answers

A.To handle containers that have a variable startup time

B.To check if the container is healthy after startup

C.To delay readiness and liveness probes until the application is fully initialized

D.To remove the pod from service endpoints if it fails

E.To allow a container a long time to start up without being killed by liveness probe

AnswersA, C, E

Startup probe accommodates varying startup durations.

Why this answer

Option A is correct because a startup probe is specifically designed for containers that have a variable or long initialization time. It allows the kubelet to delay the start of liveness and readiness probes until the application has finished starting up, preventing premature failures.

Exam trap

CNCF often tests the distinction between probe types, and the trap here is confusing the startup probe's role of delaying other probes with the readiness probe's role of controlling service traffic, or the liveness probe's role of restarting unhealthy containers.

Practice this question →

46

MCQmedium

You run 'kubectl get events' and see an event 'FailedScheduling' for a pod. What is the most common cause?

A.Insufficient node resources to meet the pod's requests

B.The pod's container image pull failed

C.The liveness probe failed

D.The pod was deleted by a Deployment update

AnswerA

The scheduler cannot find a node that satisfies the pod's resource requirements.

Why this answer

The 'FailedScheduling' event indicates that the Kubernetes scheduler could not find a suitable node to place the pod. The most common cause is insufficient node resources (CPU, memory, or ephemeral storage) to meet the pod's resource requests defined in the pod spec. The scheduler uses the `kube-scheduler` component to evaluate node fit based on predicates like `PodFitsResources`, and if no node satisfies the requested resources, the pod remains in a Pending state with this event.

Exam trap

The trap here is that candidates confuse 'FailedScheduling' with pod runtime failures (like image pull or probe failures), but scheduling events occur before the pod is bound to a node, so only resource-related or node affinity issues apply.

How to eliminate wrong answers

Option B is wrong because a container image pull failure generates a 'Failed' or 'ErrImagePull' event, not 'FailedScheduling', and is handled by the kubelet on an already scheduled node. Option C is wrong because a liveness probe failure causes the kubelet to restart the container, not a scheduling failure; it would produce a 'Unhealthy' or 'BackOff' event. Option D is wrong because a Deployment update that deletes a pod triggers a 'Killing' event and the pod is terminated, not left unscheduled; 'FailedScheduling' occurs before the pod is placed on any node.

Practice this question →

47

MCQmedium

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

A.kubectl debug -it pod --image=busybox --target=crashing-container

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

C.kubectl attach pod

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

AnswerA

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

Why this answer

kubectl debug with the -it flag creates an ephemeral container for interactive debugging.

Practice this question →

48

Multi-Selecthard

Which THREE commands can be used to get detailed information about a pod named 'my-pod'? (Choose three.)

Select 3 answers

A.kubectl logs my-pod

B.kubectl get pod my-pod -o json

C.kubectl describe pod my-pod

D.kubectl exec my-pod -- env

E.kubectl get pod my-pod -o yaml

AnswersB, C, E

This outputs the full JSON definition of the pod.

Why this answer

Option B is correct because `kubectl get pod my-pod -o json` retrieves the full object representation of the pod in JSON format, which includes all fields such as metadata, spec, status, and annotations. This provides detailed, machine-readable information about the pod's current state and configuration.

Exam trap

CNCF often tests the distinction between commands that retrieve object metadata/status (get/describe) versus commands that interact with the pod's runtime (logs/exec), leading candidates to mistakenly select runtime commands for 'detailed information' about the pod itself.

Practice this question →

49

MCQmedium

A company runs a Kubernetes cluster with multiple namespaces. The operations team wants to ensure that any application crash or container restart is automatically detected and the team is notified. Which built-in Kubernetes resource should they configure to achieve this?

A.Event

B.ConfigMap

C.Secret

D.CronJob

AnswerA

Events are generated for pod crashes/restarts and can be used for monitoring.

Why this answer

Kubernetes Events are the built-in resource that records state changes, including pod crashes and container restarts. By configuring a monitoring tool or custom controller to watch Events (e.g., via the Kubernetes API or `kubectl get events`), the operations team can automatically detect application failures and trigger notifications. Events provide the necessary metadata (reason, message, timestamp) to identify crash loops or restart backoffs.

Exam trap

The trap here is that candidates may confuse CronJobs (which can run scripts to check health) with the built-in event detection mechanism, but Kubernetes Events are the native, declarative way to capture and react to state changes without custom scripting.

How to eliminate wrong answers

Option B is wrong because ConfigMaps are used to store non-sensitive configuration data (e.g., environment variables, config files) and do not generate or detect runtime events like crashes. Option C is wrong because Secrets store sensitive data (e.g., passwords, tokens) and have no mechanism for monitoring application health or container restarts. Option D is wrong because CronJobs schedule recurring tasks (e.g., batch jobs) but do not inherently detect or report on pod crashes or container restarts; they are for time-based job execution, not event-driven observability.

Practice this question →

50

MCQmedium

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

A.Create an Ingress resource that exposes the /metrics endpoint externally.

B.Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.

C.Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.

D.Add a PrometheusRule resource that defines the scrape target.

AnswerC

Standard Prometheus operator configuration for scraping.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

51

MCQhard

You have a Deployment that uses an httpGet liveness probe on port 8080 with path /healthz. The probe fails after the container starts, but you can successfully curl http://localhost:8080/healthz from within the container. What is the most likely cause?

A.The liveness probe port is incorrect

B.The container is not running

C.The liveness probe path is incorrect

D.The container is listening on localhost (127.0.0.1) instead of 0.0.0.0

AnswerD

The liveness probe runs from the node and cannot reach localhost inside the container. The container must listen on all interfaces (0.0.0.0) for the probe to succeed.

Why this answer

The liveness probe is executed by the kubelet from the node's network namespace, not from within the container. If the application binds only to 127.0.0.1 (localhost), it will only accept connections from within the container itself. The kubelet's HTTP GET request to the pod's IP on port 8080 will be refused because the socket is not listening on 0.0.0.0, causing the probe to fail even though a local curl succeeds.

Exam trap

The trap here is that candidates see a successful curl from inside the container and assume the probe should work, failing to realize that the kubelet probes from outside the container's network namespace and cannot reach a service bound only to 127.0.0.1.

How to eliminate wrong answers

Option A is wrong because the probe is configured to use port 8080, and the curl test confirms the application is indeed listening on port 8080 inside the container, so the port is correct. Option B is wrong because the container is clearly running — the user can successfully execute curl inside it, which requires a running container. Option C is wrong because the curl test uses the exact same path /healthz and succeeds, proving the path is correct and the endpoint is reachable from within the container.

Practice this question →

52

MCQmedium

A pod named 'app' is stuck in 'Pending' state. You run 'kubectl describe pod app' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

A.The pod's CPU request is higher than the available CPU on any node

B.The container image is not found

C.The pod is in CrashLoopBackOff

D.The pod has been evicted due to memory pressure

AnswerA

The scheduling failure is due to insufficient CPU resources on all nodes.

Why this answer

The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the pod's CPU resource request exceeds the allocatable CPU capacity on every node in the cluster. Kubernetes schedules pods based on resource requests, not limits, so if the sum of CPU requests across all pods on a node would exceed the node's capacity, the pod remains Pending. This is the most likely cause because the error message directly points to insufficient CPU resources.

Exam trap

The trap here is that candidates confuse resource requests with resource limits, or assume that the pod is failing at runtime (like CrashLoopBackOff) when the error is purely a scheduling issue indicated by the Pending state and the specific 'Insufficient cpu' event.

How to eliminate wrong answers

Option B is wrong because a missing container image would produce an 'ImagePullBackOff' or 'ErrImagePull' event, not an 'Insufficient cpu' scheduling error. Option C is wrong because CrashLoopBackOff is a pod status that occurs after the pod has been scheduled and started, not while it is still Pending. Option D is wrong because eviction due to memory pressure results in a 'Evicted' status, not a Pending state, and the event would mention memory, not CPU.

Practice this question →

53

MCQmedium

You want to see the IP address and the node on which each pod in the 'default' namespace is running. Which command provides this information?

A.kubectl describe pods

B.kubectl get pods -o wide

C.kubectl get pods --show-labels

D.kubectl get pods -o yaml

AnswerB

The -o wide flag shows additional columns including IP and Node.

Why this answer

Option B is correct because `kubectl get pods -o wide` outputs additional columns including the pod's IP address and the node it is scheduled on, which directly answers the question. The `-o wide` flag extends the default output format to show these fields without requiring a full resource description or YAML output.

Exam trap

The trap here is that candidates may choose `kubectl describe pods` (Option A) because it shows IP and node information, but they overlook that `-o wide` provides a cleaner, tabular view for multiple pods, which is the intended use case in the question.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pods` shows detailed information about pods, including IP and node, but it is not a concise command to 'see' this data for all pods at once; it requires scrolling through verbose output per pod. Option C is wrong because `--show-labels` only adds label columns to the default pod list, not IP or node information. Option D is wrong because `-o yaml` outputs the full YAML representation of pod objects, which includes IP and node fields but is overly verbose and not the standard way to quickly view this tabular data.

Practice this question →

54

Multi-Selecthard

A pod is running but not serving traffic. You suspect the readiness probe is failing. Which THREE commands or actions would help you diagnose the readiness probe issue?

Select 3 answers

A.Examine the container logs for errors during readiness probe checks.

B.Run 'kubectl top pod <pod-name>' to check CPU/memory usage.

C.Run 'kubectl get nodes' to see node conditions.

D.Run 'kubectl describe pod <pod-name>' to check the events section for probe failures.

E.Exec into the container and manually curl the readiness endpoint to test it.

AnswersA, D, E

Logs may reveal why the probe is failing.

Why this answer

Option A is correct because container logs often contain detailed error messages from the readiness probe itself, such as HTTP 4xx/5xx responses or connection timeouts. By examining the logs, you can directly see why the probe is failing, e.g., the application's health endpoint returning a non-2xx status or the probe timing out.

Exam trap

CNCF often tests the distinction between resource monitoring commands and probe-specific diagnostics, so candidates may mistakenly choose 'kubectl top pod' or 'kubectl get nodes' thinking they reveal probe failures, when in fact only describe, logs, and direct endpoint testing are relevant.

Practice this question →

55

MCQmedium

You need to configure a container to shut down gracefully when it receives a SIGTERM signal, with a timeout of 30 seconds before force kill. Which field in the Pod spec should you set?

A.activeDeadlineSeconds

B.livenessProbe.periodSeconds

C.restartPolicy

D.terminationGracePeriodSeconds

AnswerD

Correct. This field specifies the grace period in seconds.

Why this answer

terminationGracePeriodSeconds sets the time Kubernetes waits for a pod to shut down gracefully after sending SIGTERM.

Practice this question →

56

MCQmedium

You want to view the resource usage of all pods running on a node named 'node01'. Which command should you use?

A.kubectl top nodes node01

B.kubectl get pods -o wide --all-namespaces --field-selector spec.nodeName=node01

C.kubectl top pods --all-namespaces --field-selector spec.nodeName=node01

D.kubectl describe node node01 | grep -A 10 'Non-terminated Pods'

AnswerC

This command shows pod resource usage for all pods scheduled on node01.

Why this answer

Option C is correct because `kubectl top pods` retrieves real-time CPU and memory usage metrics for pods, and the `--field-selector spec.nodeName=node01` filter restricts the output to only pods scheduled on the specified node. This directly answers the requirement to view resource usage of all pods on 'node01'.

Exam trap

The trap here is confusing `kubectl top pods` (which shows live resource usage) with `kubectl get pods` (which shows static pod metadata) or `kubectl describe node` (which shows node-level resource allocation, not per-pod usage).

How to eliminate wrong answers

Option A is wrong because `kubectl top nodes` shows resource usage at the node level (aggregate CPU/memory for the entire node), not per-pod usage. Option B is wrong because `kubectl get pods -o wide` lists pod details (like IP and node) but does not include resource usage metrics; it only shows static pod information. Option D is wrong because `kubectl describe node` shows node-level resource allocation (requests/limits) and pod counts, not real-time resource usage of individual pods.

Practice this question →

57

MCQeasy

Which command shows resource usage (CPU/memory) of pods in the default namespace?

A.kubectl get pods -o wide

B.kubectl logs pod

C.kubectl top pod

D.kubectl describe pod

AnswerC

kubectl top pod displays CPU and memory usage for pods.

Why this answer

Option C is correct because `kubectl top pod` is the Kubernetes command that displays real-time CPU and memory usage metrics for pods, leveraging the metrics server to collect resource utilization data. This command is essential for monitoring pod performance and is part of the Application Observability and Maintenance domain.

Exam trap

The trap here is that candidates often confuse `kubectl get pods -o wide` or `kubectl describe pod` with resource monitoring commands, but neither provides live CPU/memory metrics, which only `kubectl top pod` (with the Metrics Server) can deliver.

How to eliminate wrong answers

Option A is wrong because `kubectl get pods -o wide` shows pod details like node IP and pod IP, but does not include CPU or memory usage metrics. Option B is wrong because `kubectl logs pod` retrieves container logs, not resource usage statistics. Option D is wrong because `kubectl describe pod` provides detailed configuration and status information, but does not display live CPU or memory consumption data.

Practice this question →

58

Multi-Selectmedium

Which TWO of the following are valid ways to expose application metrics for scraping by Prometheus in a Kubernetes environment?

Select 2 answers

A.Add annotations 'prometheus.io/scrape: "true"' to the pod template

B.Create an Ingress with the metrics path

C.Create a ServiceMonitor custom resource in the same namespace

D.Add annotations 'prometheus.io/scrape: "true"' to the Deployment

E.Store metrics in a ConfigMap and mount it to Prometheus

AnswersA, C

Prometheus auto-discovers pods with these annotations.

Why this answer

Option A is correct because Prometheus supports automatic service discovery in Kubernetes via pod annotations. Adding 'prometheus.io/scrape: "true"' to the pod template tells Prometheus to scrape metrics from that pod, provided Prometheus is configured to use the Kubernetes service discovery mechanism. This is a standard, widely adopted pattern for exposing application metrics.

Exam trap

CNCF often tests the distinction between pod-level annotations (which Prometheus discovers) versus higher-level resource annotations (like Deployment) that are ignored by Prometheus's service discovery.

Practice this question →

59

MCQhard

A deployment 'api-deploy' has resource limits set but is frequently being OOMKilled. The team suspects the memory limit is too low. Which approach should be taken to confirm this without causing downtime?

A.Create a new pod with a higher memory limit and delete the old pods manually.

B.Set the memory limit to unlimited by removing the limit section and restart the pod.

C.Use 'kubectl set resources' to increase the limit on the running pod dynamically.

D.Increase the memory limit in the deployment spec and apply the change; the rollout will automatically restart pods.

AnswerD

Rolling update applies changes without downtime.

Why this answer

Option D is correct because updating the deployment spec triggers a rolling update, which replaces pods with new ones having the increased memory limit without downtime. This approach leverages Kubernetes' deployment controller to manage the rollout automatically, ensuring service continuity while adjusting resource limits.

Exam trap

The trap here is that candidates confuse 'kubectl set resources' with a dynamic in-place update, not realizing it modifies the deployment spec and requires a rollout to take effect, similar to editing the YAML directly.

How to eliminate wrong answers

Option A is wrong because manually creating and deleting pods bypasses the deployment's desired state management, risking configuration drift and potential downtime if not coordinated properly. Option B is wrong because removing the memory limit entirely can lead to resource starvation for other pods and violates Kubernetes best practices; it also requires restarting the pod, causing downtime. Option C is wrong because 'kubectl set resources' modifies the deployment spec, not the running pod directly; the pod must be recreated to apply the new limits, and the command triggers a rollout, not a dynamic in-place update.

Practice this question →

60

Drag & Dropmedium

Sequence the steps to troubleshoot a Pod stuck in CrashLoopBackOff state.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Start by checking status, then inspect logs and events to diagnose. Fix the issue, then restart the Pod.

Practice this question →

61

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

62

MCQeasy

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

A.kubectl top node

B.kubectl top pod -n <namespace>

C.kubectl top pods

D.kubectl get pods --show-labels

AnswerB

Correct command to view pod resource usage.

Why this answer

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

Exam trap

The trap here is that candidates often confuse `kubectl top pod` (which requires the metrics-server) with `kubectl describe pod` (which shows resource requests/limits, not actual usage), or they omit the `-n` flag and assume it works across all namespaces.

How to eliminate wrong answers

Option A is wrong because `kubectl top node` shows resource usage for nodes (the entire worker machine), not for individual pods within a namespace. Option C is wrong because `kubectl top pods` without a namespace flag defaults to the current context's namespace (often `default`), not the specified namespace, and is incomplete without `-n`. Option D is wrong because `kubectl get pods --show-labels` only lists pod metadata and labels, not CPU or memory usage metrics.

Practice this question →

63

MCQmedium

You need to view the logs of a container that previously crashed and has been restarted. Which flag do you use with 'kubectl logs'?

A.--all-containers

B.--tail

C.--previous

D.-f

AnswerC

--previous shows logs from the previous container instance.

Why this answer

The `--previous` flag is used with `kubectl logs` to view logs from the previous instance of a container that has crashed and been restarted. This allows you to inspect the logs of the terminated container before the restart, which is essential for debugging crash loops.

Exam trap

CNCF often tests the distinction between flags that affect log output formatting (`--tail`, `-f`) versus flags that change which container instance's logs are accessed (`--previous`), leading candidates to confuse `--tail` or `-f` as solutions for viewing previous crash logs.

How to eliminate wrong answers

Option A is wrong because `--all-containers` is used to stream logs from all containers in a pod, not specifically from a previously crashed container. Option B is wrong because `--tail` limits the number of lines shown from the log output, but it does not retrieve logs from a previous container instance. Option D is wrong because `-f` (follow) streams logs in real-time, which is useful for live monitoring but does not access historical logs from a crashed container.

Practice this question →

64

MCQeasy

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

A.Readiness probe

B.Resource limit

C.Startup probe

D.Liveness probe

AnswerA

Readiness probes indicate whether a pod is ready to serve traffic; if it fails, the pod is removed from Service endpoints.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

65

MCQmedium

You want to run a command inside a running container to check environment variables. Which command should you use?

A.kubectl logs pod-name

B.kubectl exec pod-name -- env

C.kubectl describe pod pod-name

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

AnswerB

This runs the 'env' command inside the container.

Why this answer

Option B is correct because `kubectl exec pod-name -- env` runs the `env` command inside the specified container, which prints all environment variables set in the container's runtime environment. This is the most direct and efficient way to inspect environment variables without entering an interactive shell.

Exam trap

The trap here is that candidates may choose Option D thinking they need an interactive shell to run `env`, but the question asks for the command to check environment variables directly, and `kubectl exec pod-name -- env` is the precise, non-interactive approach that works even in containers without a shell.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod-name` retrieves the container's stdout/stderr logs, not environment variables. Option C is wrong because `kubectl describe pod pod-name` shows the pod's specification and status, including environment variables defined in the pod spec, but it does not show runtime environment variables injected by the container runtime (e.g., from secrets, configmaps, or the platform). Option D is wrong because `kubectl exec -it pod-name -- /bin/bash` opens an interactive shell inside the container, which can then be used to run `env`, but it is not the direct command to check environment variables; it requires an extra step and assumes the container has a shell like bash.

Practice this question →

66

MCQhard

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

A.terminationGracePeriodSeconds: 60

B.lifecycle.preStop.exec.command with sleep 60

C.livenessProbe.initialDelaySeconds: 60

D.resources.limits.cpu

AnswerA

This field defines the grace period for pod termination.

Why this answer

The 'terminationGracePeriodSeconds' field sets the time between SIGTERM and SIGKILL. Setting it to 60 gives 60 seconds for graceful shutdown. Option A is correct.

Option B is for preStop hook, not the grace period. Option C is for probes. Option D is for resource limits.

Practice this question →

67

MCQmedium

Your team manages a microservices application on a Kubernetes cluster. A critical service 'order-service' is deployed with 3 replicas. Lately, customers have reported occasional timeouts when placing orders. You suspect that the service is overloaded during peak hours. You have configured a HorizontalPodAutoscaler (HPA) based on CPU utilization, but the autoscaler does not appear to be scaling up quickly enough. Upon inspection, you notice that the HPA is configured with a target CPU utilization of 80%, and the current CPU usage of the pods is around 70%. However, the pods' memory usage is high and growing. The application is also logging slow database queries. Which action is most likely to improve the responsiveness of the service during peak load?

A.Modify the HPA to also scale based on memory utilization, setting a target average value for memory.

B.Reduce the number of replicas to 2 to force the HPA to react more aggressively.

C.Increase the CPU target utilization to 90% so the HPA triggers earlier.

D.Optimize the database queries to reduce response time.

AnswerA

Memory-based scaling can detect the actual resource pressure.

Why this answer

Option A is correct because the HPA is configured only for CPU, but the symptom (high memory usage, slow DB queries) indicates memory pressure is the bottleneck. Adding a memory-based metric to the HPA allows it to scale when memory exceeds the target, addressing the root cause of overload during peak hours. The current CPU at 70% is below the 80% threshold, so the HPA won't trigger on CPU alone, but memory scaling can react to the actual resource constraint.

Exam trap

The trap here is that candidates often assume CPU is the only metric for HPA scaling, but the CKAD exam tests the ability to identify when other metrics (like memory) are more relevant based on application behavior and symptoms.

How to eliminate wrong answers

Option B is wrong because reducing replicas to 2 would decrease capacity, worsening the overload and timeouts, not improving responsiveness. Option C is wrong because increasing the CPU target to 90% would make the HPA trigger later (at higher CPU), not earlier, and CPU is already below 80%, so this change would not help. Option D is wrong because while optimizing database queries is a valid long-term fix, it does not address the immediate scaling issue; the HPA should be configured to scale based on the actual bottleneck (memory) to handle peak load now.

Practice this question →

68

MCQeasy

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

A.kubectl logs -c nginx web-pod

B.kubectl logs web-pod -c nginx

C.kubectl logs web-pod nginx

D.kubectl logs web-pod --container nginx

AnswerB

Correct. The -c flag specifies the container name.

Why this answer

When a pod has multiple containers, you must specify the container name with -c flag.

Practice this question →

69

MCQmedium

You have a pod that is in a 'Pending' state. You run 'kubectl describe pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

A.The pod's CPU request is larger than the available CPU on any node

B.The pod requires more memory than any node can provide

C.The pod's liveness probe is failing

D.All nodes are tainted and the pod does not tolerate the taints

AnswerA

The event indicates CPU insufficiency.

Why this answer

The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the Kubernetes scheduler attempted to place the pod on each of the three nodes but found that none had enough allocatable CPU capacity to satisfy the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's CPU capacity. The pod remains in 'Pending' because the scheduler cannot find a suitable node until CPU resources are freed or the request is reduced.

Exam trap

CNCF often tests the distinction between resource requests (used for scheduling) and resource limits (used for throttling), and candidates mistakenly think 'Insufficient cpu' refers to limits or actual usage rather than the guaranteed request that the scheduler evaluates.

How to eliminate wrong answers

Option B is wrong because the event explicitly mentions 'Insufficient cpu', not memory; a memory shortage would produce 'Insufficient memory'. Option C is wrong because liveness probe failures occur after the pod is running (in 'Running' state), not while it is still 'Pending' and before scheduling. Option D is wrong because taints and tolerations produce events like '0/3 nodes are available: 3 node(s) had taint {key:value} that the pod didn't tolerate', not 'Insufficient cpu'.

Practice this question →

70

Multi-Selectmedium

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

Select 2 answers

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

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

C.kubectl logs <pod> --previous

D.kubectl logs <pod> -p

E.kubectl logs <pod>

AnswersC, D

Shows logs from the previous container instance.

Why this answer

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

Exam trap

CNCF often tests the distinction between `--previous` (or `-p`) and `-c` flags, where candidates mistakenly think `-c` retrieves logs from a crashed container instead of specifying a container name in a multi-container pod.

Practice this question →

71

MCQeasy

What is the purpose of the 'kubectl describe pod' command?

A.Display detailed information about a pod, including recent events

B.Execute a command inside a pod

C.Display resource usage of a pod

D.Show the logs of a pod

AnswerA

kubectl describe provides a comprehensive overview of a pod's state and recent events.

Why this answer

The 'kubectl describe pod' command retrieves detailed metadata about a specific pod, including its current state, labels, annotations, container specifications, volumes, and a chronological list of recent events (e.g., image pull failures, container restarts, scheduling decisions). This aggregated information is essential for debugging pod lifecycle issues because it surfaces both static configuration and dynamic cluster-level events that are not shown in the pod's YAML manifest or logs.

Exam trap

CNCF often tests the distinction between 'describe' (detailed metadata + events) and 'get' (summary or YAML output), so the trap here is confusing 'kubectl describe' with 'kubectl logs' or 'kubectl exec', especially when a pod is failing and candidates instinctively reach for logs instead of first checking events for scheduling or image-related errors.

How to eliminate wrong answers

Option B is wrong because executing a command inside a pod is done with 'kubectl exec', not 'kubectl describe'. Option C is wrong because resource usage (CPU/memory) is displayed by 'kubectl top pod', which relies on the metrics-server, not by 'kubectl describe'. Option D is wrong because showing logs is the purpose of 'kubectl logs', which streams stdout/stderr from containers, whereas 'kubectl describe' provides configuration and event data, not log output.

Practice this question →

72

Multi-Selecteasy

You want to collect logs from a pod that has multiple containers. Which TWO approaches allow you to view logs from a specific container?

Select 2 answers

A.kubectl logs pod-name -c container-name

B.kubectl logs pod-name --container container-name

C.kubectl logs pod-name --all-containers

D.kubectl logs pod-name --container container-name

E.kubectl logs pod-name

AnswersA, D

Correct syntax to specify container.

Why this answer

Option A is correct because the `kubectl logs` command with the `-c` flag allows you to specify a container name within a multi-container pod. This is the standard shorthand for `--container` and is explicitly supported in the Kubernetes CLI for targeting logs from a specific container.

Exam trap

The trap here is that candidates may think `--all-containers` is a valid way to view logs from a specific container, but it actually streams logs from all containers, which is not what the question asks; also, the duplicate options A and D are both correct, but candidates might overlook that both are valid and pick only one.

Practice this question →

73

Multi-Selecteasy

Which TWO of the following are valid reasons to use a readiness probe? (Select 2)

Select 2 answers

A.To prevent traffic from being sent to a pod that is not ready due to a dependency

B.To ensure the pod is not added to a Service until the application is ready

C.To monitor resource usage and scale the pod

D.To delay the start of the application until a database is available

E.To restart the container if it becomes unresponsive

AnswersA, B

Readiness probe checks if the pod can serve traffic.

Why this answer

A readiness probe is used to determine whether a pod is ready to serve traffic. Option A is correct because it prevents traffic from being sent to a pod that is not ready due to a dependency, such as a database or cache that hasn't fully initialized. The kubelet uses the probe's success or failure to control whether the pod's IP address is added to the endpoints of a Service, ensuring only ready pods receive requests.

Exam trap

CNCF often tests the distinction between readiness, liveness, and startup probes; the trap here is confusing the purpose of a readiness probe (traffic routing) with that of a liveness probe (container restart) or a startup probe (delaying other probes).

Practice this question →

74

MCQeasy

Which command shows the CPU and memory usage of all pods in the current namespace?

A.kubectl top node

B.kubectl top --all

C.kubectl top pod pod-name

D.kubectl top pod

AnswerD

This displays CPU and memory usage for pods in the current namespace.

Why this answer

Option D is correct because `kubectl top pod` without a specific pod name retrieves CPU and memory usage metrics for all pods in the current namespace, as the command defaults to listing all pods when no pod name is provided. This relies on the metrics-server collecting resource usage data from the kubelet's cAdvisor endpoint via the Resource Metrics API.

Exam trap

CNCF often tests the misconception that `kubectl top pod` requires a pod name to show metrics, but omitting the pod name lists all pods in the current namespace, which is the correct syntax for the question's requirement.

How to eliminate wrong answers

Option A is wrong because `kubectl top node` shows resource usage for nodes, not pods, and does not filter by namespace. Option B is wrong because `kubectl top --all` is not a valid kubectl command; the `--all` flag is used with `kubectl get` to select resources across all namespaces, but `kubectl top` does not support that flag. Option C is wrong because `kubectl top pod pod-name` shows metrics for a single specific pod, not all pods in the namespace.

Practice this question →

75

MCQhard

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

A.The readiness probe is misconfigured and is shutting down the pod

B.The liveness probe is using the wrong HTTP endpoint

C.The file /tmp/healthy does not exist or is not being updated by the application

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

AnswerC

The exec probe runs 'cat /tmp/healthy'. If the file is missing, the command fails, causing the probe to fail and restart the container.

Why this answer

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

Exam trap

The trap here is that candidates confuse the liveness probe's exec command with an HTTP probe or assume the probe is failing due to timing, when the real issue is the command's exit code reflecting the absence or staleness of the file.

How to eliminate wrong answers

Option A is wrong because a readiness probe does not shut down pods; it only controls whether the pod receives traffic from Services. Option B is wrong because the liveness probe is explicitly configured as an exec command, not an HTTP endpoint, so the HTTP endpoint is irrelevant. Option D is wrong because if the command completes quickly (e.g., 'cat /tmp/healthy'), a low timeoutSeconds would not cause failure; the issue is the command's exit code, not its execution time.

Practice this question →

Page 1 of 3 · 171 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Application Observability and Maintenance questions.

Start 20-question session