5 exercises — Practice describing kubectl output, pod states, and diagnostic sequences in professional English.
0 / 12 completed
1 / 12
Your team is triaging a deployment issue. In kubectl get pods output, a pod shows READY: 0/1 and STATUS: Running. A junior engineer asks what "0/1" means. Which response most accurately explains the READY column?
The READY column shows how many containers in the pod have passed their readiness probe — "0/1" means none of the pod's one container is ready to serve traffic.
A pod can be in STATUS Running (the container process has started) while still showing READY 0/1 if its readiness probe has not yet returned a successful response. Until the readiness probe passes, Kubernetes removes the pod from the Service's Endpoints, so no traffic is routed to it. This distinction is important when explaining why a deployment looks healthy but requests are failing.
Key vocabulary:
• READY column — format is <passing containers>/<total containers>; reflects readiness probe results
• readiness probe — a periodic check that determines whether a pod should receive traffic
• Endpoints — the list of pod IPs a Service forwards traffic to; pods excluded when not ready
2 / 12
A pod shows STATUS: CrashLoopBackOff and RESTARTS: 6. A product manager asks you to explain what's happening and what your immediate next step is. Which response is the most professional and technically accurate?
CrashLoopBackOff means the container starts, immediately exits with a non-zero code, and Kubernetes keeps restarting it with increasing delays — the "backoff" interval grows exponentially to reduce cluster load.
The first investigation step is always kubectl logs --previous, which retrieves stdout/stderr from the last terminated container instance. Follow that with kubectl describe pod to check the Last Exit Code in the container state section. Avoid saying "the cluster is broken" to non-technical stakeholders — be precise about what component is failing and what you're doing about it.
Key vocabulary:
• CrashLoopBackOff — container exits non-zero; Kubernetes restarts it with exponential backoff
• exponential backoff — restart delay doubles with each attempt (10s → 20s → 40s → …) up to 5 min
• kubectl logs --previous — fetches logs from the most recently terminated container instance
3 / 12
During a live incident call you're narrating the output of kubectl describe pod api-server-xyz. A colleague asks you to explain what the Events section contains. Which description is most accurate?
The Events section in kubectl describe pod is a time-ordered log of actions and warnings generated by Kubernetes components — the scheduler, kubelet, and image puller — for that specific pod.
When narrating during an incident, walk through events from oldest to newest. Key signals to call out: "Scheduled" (which node the pod landed on), "Pulling" and "Pulled" (image pull times), "Started" (container launch), and any Warning events like "BackOff", "Failed to pull image", or "Liveness probe failed" — these pinpoint where in the pod lifecycle the failure occurred.
Key vocabulary:
• Events section — chronological log of scheduler, kubelet, and controller actions on the pod
• Warning event — signals a non-fatal problem (probe failure, image backoff, mount error)
• kubectl describe — aggregates pod spec, status, conditions, and events in one view
4 / 12
A team member says: "I need to see what the container printed right before it crashed." Which kubectl logs flag and narration correctly addresses this need?
The --previous flag is the correct tool for reading crash output — it targets the terminated container's log stream, not the new one Kubernetes started in its place.
When a container crashes and Kubernetes restarts it, the new container has a fresh log stream. Without --previous, kubectl logs shows the new (empty or minimal) container output. Other flags serve different purposes: --follow tails live output in real time; --since filters by time window on the current container; --tail limits the number of lines returned from the current container's end.
Key vocabulary:
• --previous — reads logs from the last terminated (crashed) container instance
• --follow — streams live log output; analogous to tail -f
• --since / --tail — time-window and line-count filters applied to the current container
5 / 12
A pod named api-server-xyz is failing. You need to describe your kubectl investigation sequence to a senior engineer. Which order follows the most logical diagnostic flow?
The standard kubectl diagnostic sequence moves from broad state overview to specific evidence: get → describe → logs — each step narrows the scope of the investigation.
kubectl get pods gives you the high-level signal (status, restarts, age). kubectl describe pod adds scheduling history, conditions, resource data, and the all-important Events section. kubectl logs (plus --previous if it's crashed) gives you the container's own perspective on what went wrong. kubectl get events at the namespace level can surface related problems on sibling resources. Only after gathering this evidence should you take corrective action — not before.
Key vocabulary:
• kubectl get pods — top-level status: READY, STATUS, RESTARTS, AGE
• kubectl describe pod — full detail: spec, conditions, events, probes, resource requests
• kubectl get events --sort-by=.lastTimestamp — namespace-wide event timeline for context
6 / 12
kubectl get pods api-server-xyz -o wide outputs:
| NAME | READY | STATUS | RESTARTS | AGE |
|---------------|-------|-------------|----------|-----------------|
The 'READY' column in `kubectl get pods` specifically indicates the number of containers within a pod that are ready to serve traffic. A value of 0/1 means there is one container defined in the pod but it hasn't yet reached the 'Running' state, often due to resource constraints or initialization delays.
7 / 12
Sarah (a Product Manager) says: 'Our new feature deployment is showing errors in production. Can you explain what the kubectl logs api-server-xyz command might reveal and why it's important to run it now?' Which response best addresses her concern?
Running kubectl logs api-server-xyz is crucial in troubleshooting production deployments. This command retrieves recent application log messages from the container, which often contains valuable information about errors or unexpected behavior that triggered the deployment issue. While other commands have their place, examining logs provides immediate insight into the root cause.
8 / 12
Mark says: 'I need to see the last 10 lines of the application's log output.' Which kubectl command and narration best achieves this?
The kubectl logs api-server-xyz -n myapp --tail=10 command retrieves the most recent 10 lines of log output from the container. The `-n myapp` flag specifies the namespace where the pod is running (important for multi-namespace deployments), and `--tail=10` limits the output to the last 10 lines, directly addressing Mark's request.
9 / 12
During a code review of a deployment script, Liam (a developer) asks: 'What does the `kubectl rollout status` command tell me?' Which explanation is most accurate for conveying this information to Liam?
kubectl rollout status focuses on the *state* of a deployment. It doesn't show version numbers or directly control scaling. Instead, it reports whether the rollout was successful and provides information about the progress – this is crucial for understanding if changes have been applied correctly to your application's pods. This command is designed to monitor deployments in real-time.
10 / 12
Maria (a DevOps Engineer) reports a spike in error rates following a recent Kubernetes update. She asks you to investigate using kubectl logs. Which of the following commands best addresses her request for information about the application's log output?
The kubectl logs api-server-xyz -f command is the correct choice because the `-f` flag streams the logs in real-time, which is exactly what Maria needs to investigate a spike in error rates. The other options are not designed for retrieving live log data; describe pod provides resource details and configuration, while get pods shows basic status information, and the last option attempts to execute a command *within* the container (which isn't the primary use case).
11 / 12
David (a Developer) is troubleshooting an issue with a failing deployment. He asks you to explain what the 'Events' section of kubectl describe pod my-app-pod reveals. Which statement best describes this information?
The 'Events' section in kubectl describe pod is critical for debugging. It records *every* action performed on the pod – this includes deployments, scaling events, and any errors that occur. This chronological log of actions allows you to trace the sequence of events leading up to a problem, providing invaluable context for troubleshooting.
12 / 12
You are assisting a new team member, Emily, in diagnosing an issue with a Kubernetes deployment. She asks you about the best way to investigate the pod's status and identify potential problems. Which sequence of steps would you recommend?
This sequence is the most logical and comprehensive approach to troubleshooting a failing pod. First, kubectl rollout status deployment my-app checks the overall deployment state. Then, kubectl describe pod api-server-xyz provides detailed information about the pod's configuration and any issues it's experiencing. Finally, kubectl logs api-server-xyz allows you to examine the application's log output for errors or clues.
What will I practise in "kubectl Narration — Kubernetes Operations | CoderLingo"?
5 advanced exercises practising how to narrate kubectl output, explain pod states, and communicate Kubernetes diagnostics in professional English.
How many exercises are in this module?
This module has 12 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.