CCNA Application Observability and Maintenance Questions

Matchingmedium

Match each Kubernetes object field to its description.

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

Concepts

Matches

Maximum resources a container can use

Determines when to restart containers in a pod

Checks if container is running; restarts if fails

Checks if container is ready to serve traffic

Inject a secret value as an environment variable

Why these pairings

Correct matches: livenessProbe checks container health, readinessProbe checks service readiness, startupProbe checks application startup, and imagePullPolicy controls image pulling. Common confusions involve swapping definitions with restartPolicy.

Practice this question →

Matchingmedium

Match each Kubernetes resource to its API group.

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

Concepts

Matches

apps/v1

v1 (core)

networking.k8s.io/v1

autoscaling/v2

networking.k8s.io/v1

Why these pairings

Kubernetes resources belong to specific API groups. Pods, Services, ConfigMaps, and PersistentVolumeClaims are in the core group (v1), while Deployments are in apps/v1, and Ingresses are in networking.k8s.io/v1.

Practice this question →

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

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 →

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

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

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

In Kubernetes, liveness probes determine if a container is running properly. The valid probe types are `exec` (command), `tcpSocket`, and `httpGet`. Option B (`tcpSocket`) is correct because it attempts to open a TCP connection to a specified port; if the connection succeeds, the probe is considered successful.

Exam trap

The trap here is that candidates confuse the field name 'command' (used inside an exec probe) with a probe type name, or they assume 'portCheck' is a real probe type because it sounds plausible, while the correct TCP probe is specifically named 'tcpSocket'.

Practice this question →

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 correct approach is to use 'kubectl debug' with an ephemeral container (option A). This command creates a temporary container in the same pod, sharing the same volumes and process namespace (if requested), allowing you to inspect the filesystem even when the original container has crashed and exited. Option B fails because the container exits before 'exec' can run.

Option C only retrieves logs from the previous instance, not filesystem access. Option D displays pod metadata and events, not filesystem contents.

Practice this question →

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

In Kubernetes, probe configuration parameters are defined in the container spec within a Pod. `timeoutSeconds` is a valid parameter that specifies the number of seconds after which the probe times out, defaulting to 1 second if not set. It is used in liveness, readiness, and startup probes to control how long kubelet waits for a probe response before considering it failed.

Exam trap

The CKAD exam often tests the distinction between valid probe parameters and common-sounding but non-existent fields like `retryIntervalSeconds` or `cooldownSeconds`, tricking candidates into selecting them because they seem logical for retry or cooldown behavior.

Practice this question →

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` is a valid field in a Kubernetes probe specification that defines the number of seconds to wait before initiating the first probe after the container starts. This allows the application time to initialize before health checks begin, preventing premature failures.

Exam trap

The trap here is that candidates confuse Kubernetes probe parameters with similar concepts from other systems (e.g., retry logic or backoff strategies) and assume `maxRetries` or `backoffSeconds` are valid, when in fact Kubernetes uses `failureThreshold` and fixed-interval polling instead.

Practice this question →

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 →

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

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

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

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 →

MCQmedium

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

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

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

C.kubectl attach pod

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kubectl logs -c nginx web-pod

B.kubectl logs web-pod -c nginx

C.kubectl logs web-pod nginx

D.kubectl logs web-pod --container nginx

AnswerB

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

Why this answer

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

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

Practice this question →

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

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

Multi-Selectmedium

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

Select 2 answers

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

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

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

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

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

AnswersB, E

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

Why this answer

Readiness probes support four handler types: httpGet, exec, tcpSocket, and gRPC (since Kubernetes 1.24). These are defined in the container spec under the `readinessProbe` field, allowing the kubelet to check container readiness using HTTP status codes, command exit codes, TCP port connectivity, or gRPC health checks.

Exam trap

The trap here is confusing readiness probes with liveness probes: candidates often think a failing readiness probe restarts the pod, but it only affects traffic routing, while liveness probes handle restarts.

Practice this question →

MCQmedium

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

A.Set spec.terminationGracePeriod: 35

B.Set spec.terminationGracePeriodSeconds: 35

C.Set spec.terminationGracePeriodSeconds: 300

D.Set spec.terminationGracePeriodSeconds: 20

AnswerB

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

Why this answer

terminationGracePeriodSeconds defines the time Kubernetes waits after sending SIGTERM before sending SIGKILL. Setting it to 35 seconds gives the container a 5-second buffer beyond the expected 30-second shutdown time. Option B is correct because 35 seconds provides sufficient time without being excessive.

Option A uses an invalid field name (terminationGracePeriod instead of terminationGracePeriodSeconds). Option C sets the grace period to 300 seconds, which is excessively long and could delay pod termination. Option D sets the grace period to 20 seconds, which is too short and may not allow the container to shut down gracefully within the expected 30 seconds.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.View the conditions and status of a node

B.Execute a command inside a container

C.View the logs of a container

D.View the events associated with a pod

E.View the YAML manifest of a resource

AnswersA, D

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

Why this answer

`kubectl describe node <node-name>` displays detailed information about a node, including its conditions (e.g., Ready, DiskPressure, MemoryPressure) and status (e.g., capacity, allocatable resources). This command is essential for debugging node-level issues.

Exam trap

The trap here is that candidates confuse `kubectl describe` with `kubectl get -o yaml` (option E) or `kubectl logs` (option C), but `kubectl describe` is specifically for human-readable summaries and event inspection, not raw output or log streaming.

Practice this question →

MCQhard

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

A.tcpSocket

B.grpc

C.exec

D.httpGet

AnswerA

tcpSocket probe succeeds if the TCP handshake completes.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

Which THREE are valid types of probes in Kubernetes?

Select 3 answers

A.Startup probe

B.Readiness probe

C.Liveness probe

D.Survival probe

E.Health probe

AnswersA, B, C

Used for slow-starting containers.

Why this answer

Startup probes are a valid Kubernetes probe type used to determine when a container application has started successfully. They are particularly useful for legacy applications that have slow startup times, as they delay the start of liveness and readiness probes until the startup probe succeeds, preventing premature container restarts.

Exam trap

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.intervalSeconds

B.initialDelaySeconds

C.retryCount

D.failureThreshold

E.readinessProbe

AnswersB, D

Valid parameter to delay the first probe.

Why this answer

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

Exam trap

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

Practice this question →

MCQeasy

What is the purpose of a readiness probe in Kubernetes?

A.To control whether the pod receives traffic from Services

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

C.To monitor resource usage of the container

D.To restart the container if it becomes unhealthy

AnswerA

A failing readiness probe removes the pod from Service endpoints.

Why this answer

A readiness probe determines whether a container is ready to serve traffic. If the probe fails, the pod is removed from the endpoints of Services, thus it does not receive traffic. Option B describes a startup probe (to delay liveness/readiness probes for slow-starting containers).

Option C describes resource monitoring, not a probe. Option D describes a liveness probe, which restarts the container if unhealthy.

Practice this question →

Multi-Selecthard

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

Select 3 answers

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

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

C.kubectl logs --all

D.kubectl logs <pod> --previous

E.kubectl logs <pod> -p

AnswersB, D, E

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

Why this answer

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

Exam trap

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Readiness probe

B.TCP socket probe

C.Startup probe

D.HTTP GET probe

E.Liveness probe

AnswersA, C

Controls whether a pod is included in service endpoints.

Why this answer

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

Exam trap

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

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

B.kubectl events --pod=<pod>

C.kubectl describe pod <pod>

D.kubectl logs <pod>

E.kubectl get events

AnswersA, C

Filters events by the pod name.

Why this answer

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

Exam trap

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

Practice this question →

MCQeasy

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

A.kubectl logs --since=5m web-pod

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

C.kubectl logs -f web-pod

D.kubectl logs web-pod

AnswerC

The -f flag streams logs in real-time.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.kubectl top nodes

B.kubectl logs

C.kubectl cluster-info

D.kubectl describe pod

E.kubectl top pods

AnswersA, E

Displays resource (CPU/memory) usage of nodes.

Why this answer

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

Exam trap

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

Practice this question →

MCQeasy

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

A.kubectl logs --stream pod-name

B.kubectl logs -f pod-name

C.kubectl logs --previous pod-name

D.kubectl logs pod-name

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Delete the namespace and redeploy all workloads

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

C.Increase the CPU request for the container

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

AnswerD

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

Why this answer

The 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container more memory to operate without being killed by the Out-of-Memory (OOM) killer.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →