5 exercises — Understand and describe CrashLoopBackOff, OOMKilled, Pending diagnosis, node eviction, and probe failures in professional English.
0 / 10 completed
1 / 10
A pod has been in CrashLoopBackOff for 10 minutes and shows RESTARTS: 8. Your team lead asks you to describe what's happening and what diagnostics you have already run. Which response demonstrates the correct technical understanding?
CrashLoopBackOff is a container lifecycle state, not a scheduling or network issue — the container is running but immediately crashing, triggering Kubernetes' exponential restart backoff.
The backoff timer starts at 10 seconds and doubles on each restart, capping at 5 minutes. This prevents a crashing container from overwhelming the node with rapid restarts. The correct diagnostic sequence: (1) kubectl logs --previous to read what the process printed before dying, (2) kubectl describe pod to check the Last Exit Code and Last State Terminated reason, (3) look for patterns — exit code 1 is often an application error; exit code 137 is OOMKilled; exit code 139 is a segfault.
Key vocabulary:
• CrashLoopBackOff — container exits non-zero repeatedly; Kubernetes applies exponential backoff between restarts
• exit code — numeric value returned by the container process; non-zero indicates failure
• kubectl logs --previous — retrieves stdout/stderr from the last terminated container instance
2 / 10
A pod shows STATE: Terminated with REASON: OOMKilled. A non-technical product manager asks you to explain what happened in plain language. Which explanation is most accurate?
OOMKilled (Out Of Memory Killed) means the container's process consumed more memory than the limit set in the pod spec, and the Linux kernel's OOM killer terminated it to protect the node.
The kernel's OOM killer is a last-resort mechanism that kills processes when the system's memory is exhausted. In Kubernetes, it triggers when a container's RSS (resident set size) exceeds its memory limit. For a non-technical stakeholder, translate this to: "our application tried to use more memory than we allocated, so the system shut it down." The fix options are: profile the application's memory usage and optimize it, or raise the memory limit while monitoring for resource waste. Always check if the OOMKill is consistent or sporadic — sporadic OOMKills often indicate a memory leak.
Key vocabulary:
• OOMKilled — container terminated by the kernel OOM killer for exceeding its memory limit
• memory limit — the maximum memory a container is allowed to use; set in resources.limits.memory
• RSS (Resident Set Size) — actual physical memory currently used by a process
3 / 10
A pod has been in Pending status for 5 minutes. kubectl describe pod shows the event: "0/3 nodes are available: 3 Insufficient cpu." What is the most accurate explanation of why the pod is pending?
Kubernetes schedules pods based on resource requests, not limits — a pod with a CPU request that no single node can satisfy will remain Pending indefinitely.
The key distinction: CPU limit is the maximum a container can use; CPU request is how much the scheduler reserves on the node. A node may have unused CPU capacity but its "reserved" CPU (sum of all running pods' requests) may equal 100%, making it appear "full" to the scheduler even if actual utilization is low. Solutions: reduce the pod's CPU request if it's over-provisioned, add new nodes to the cluster, or remove underutilized pods to free up reserved capacity. Run kubectl top nodes to see actual utilization vs. allocated.
Key vocabulary:
• Pending — pod accepted by API server but not yet bound to a node by the scheduler
• resource request — the CPU/memory the scheduler reserves on a node for the pod
• resource limit — the maximum CPU/memory the container is allowed to consume at runtime
4 / 10
A node shows condition MemoryPressure: True and several pods have been automatically evicted. How do you explain this sequence of events to your engineering team?
Node-level eviction is the kubelet's self-preservation mechanism — when memory pressure breaches a threshold, it evicts pods in reverse QoS priority order to reclaim memory before the entire node becomes unresponsive.
QoS tiers determine eviction order: BestEffort pods (no requests or limits set) are evicted first, then Burstable pods (requests set but not equal to limits), and Guaranteed pods (requests = limits) are evicted last and only under extreme pressure. The kubelet has two eviction thresholds: soft (notified, grace period given) and hard (immediate eviction). To investigate: check kubectl describe node for the memory capacity, allocatable, and pressure condition; then review kubectl get events for eviction notices.
Key vocabulary:
• MemoryPressure — node condition indicating available memory is below the eviction threshold
• QoS (Quality of Service) tier — BestEffort / Burstable / Guaranteed; determines eviction priority
• eviction threshold — configurable kubelet setting (e.g., memory.available<100Mi) that triggers eviction
5 / 10
A pod's liveness probe is failing consecutively, but its readiness probe is passing. What is the impact on traffic routing and pod lifecycle?
Liveness and readiness probes are independent controls with different responsibilities: liveness governs container restart; readiness governs traffic routing — they can and do have conflicting states simultaneously.
When the liveness probe fails beyond failureThreshold (default: 3 consecutive failures), kubelet kills the container and the restart policy applies (usually Always). Until that moment, the readiness probe continues to control Service endpoint membership — a passing readiness probe means the pod still receives traffic right up until it is killed and restarted. The startup probe is a third, separate mechanism: it disables both liveness and readiness checks until the application has had time to initialize, preventing premature restarts during slow startup.
Key vocabulary:
• liveness probe — determines if the container process is alive; failure triggers a container restart
• readiness probe — determines if the pod should receive traffic; failure removes it from Service Endpoints
• startup probe — delays liveness/readiness checks until the application signals it has initialized
6 / 10
Sarah from DevOps is asking you to investigate a pod named my-app-pod that's repeatedly restarting. The logs show frequent SIGTERM signals being sent. Which of the following best describes your initial assessment and what further action you'd recommend?
Sarah's question highlights a common Kubernetes issue. Frequent SIGTERM signals without an appropriate handler indicate the application isn't gracefully shutting down when terminated. While transient network issues are possible, repeatedly failing termination handlers are far more indicative of a problem needing immediate attention. Monitoring for spikes in SIGTERM is a good initial step to confirm this.
7 / 10
Mark, the team's SRE, sends you a Slack message: 'Pod backend-service is stuck in `CrashLoopBackOff`. Any ideas?' You respond with: 'The pod isn't restarting successfully. Let's check the logs for errors.' Which of the following best describes *why* this response is sufficient and what additional information you should ideally be providing?
Mark's message indicates a problem that requires investigation. Your initial response correctly identifies the symptom – the pod isn't restarting. However, it lacks context for effective troubleshooting. While further information is *desirable*, simply stating the restart cycle doesn't provide enough data to diagnose the underlying issue and coordinate a targeted fix.
8 / 10
You're reviewing a PR description for an update to a deployment. The description states: 'We've scaled up the number of replicas to improve performance.' A Kubernetes administrator points out that this doesn't address the potential impact on resource constraints within the cluster. What is the *most* relevant technical term to add to the description to accurately reflect the change and its implications?
Horizontal Pod Autoscaling (HPA) is the correct term. Scaling replicas without a mechanism to automatically adjust resource limits (CPU/Memory) can lead to resource contention and performance degradation – precisely what the administrator is concerned about. HPA dynamically adjusts resources based on observed metrics, preventing over-utilization.
9 / 10
During a standup meeting, your team lead asks you to explain the state of the payment-processor pod. You observe that it's in `Pending` status with events showing '3 Insufficient cpu.' What is the *primary* reason this pod remains pending?
The event '3 Insufficient cpu' directly indicates that the node where the pod was scheduled lacks sufficient CPU resources. Kubernetes will not schedule a pod onto a node that doesn't meet its resource requirements. Network issues or application errors are secondary considerations in this scenario.
10 / 10
A developer reports that a pod named web-server-789 is failing its liveness probe. The liveness probe checks the application's health endpoint every 5 seconds. However, the readiness probe – which checks if the application can handle traffic – is passing. What is the *most* likely consequence of this situation for incoming traffic to the pod?
When a liveness probe fails, Kubernetes immediately restarts the pod. However, because the readiness probe is passing, the application *appears* healthy from the cluster's perspective. This means traffic will continue to be directed to the pod even though it's internally unhealthy, potentially leading to degraded performance or incorrect responses.
What will I practise in "Pod Lifecycle Vocabulary — Kubernetes Operations | CoderLingo"?
5 advanced exercises practising pod lifecycle vocabulary — CrashLoopBackOff, OOMKilled, Pending diagnosis, eviction, and probe failure language.
How many exercises are in this module?
This module has 10 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Kubernetes Operations exercises?
Browse the full Kubernetes Operations hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.