Use this Kubernetes interview cheat sheet for 30-second answers on Pods, Deployments, Services, kubectl, and troubleshooting follow-up traps.
The night before a Kubernetes interview, the problem isn't that you don't know what a Pod is. The problem is that when someone asks you to explain it, you either give a three-minute lecture or a one-word answer, and neither lands. This kubernetes interview cheat sheet is built for that exact moment — the reader who has seen the objects, run the commands, and still isn't sure they can explain the difference between a Deployment and a ReplicaSet in a single clean breath under pressure.
The goal here isn't exhaustive coverage. It's compression. Every section gives you a 30-second spoken answer, the one-line version for when you need to be faster, and the follow-up trap that usually exposes candidates who memorized a definition but haven't operated the system.
Stop Trying to Memorize Kubernetes Like a Glossary
Why the usual definition-first prep falls apart
Most Kubernetes prep looks the same: read the docs, copy definitions into flashcards, review the night before. The definitions are usually correct. The problem is that a correct definition and a usable interview answer are different things. Interviewers aren't grading your ability to recite the official Kubernetes documentation — they're grading whether your explanation holds together when they push on it.
The pattern that fails candidates most often isn't "I didn't know the answer." It's "my answer sounded fine until the follow-up." A candidate explains that a Pod is the smallest deployable unit in Kubernetes. The interviewer nods and asks: "So why would you ever create a Pod directly instead of through a Deployment?" Silence. The definition was memorized; the reasoning wasn't.
Kubernetes concepts are best understood as a system of relationships, not a vocabulary list. When you understand why objects exist and how they interact, follow-up questions become obvious rather than threatening.
What this looks like in practice
The answer template this cheat sheet uses throughout has three layers:
The 30-second version — what you say when the interviewer asks the question cold. One clean explanation that includes what the object is, what job it does, and one sentence on why it exists instead of something simpler.
The one-liner — the compressed version for when you're asked to define something quickly inside a longer answer. Crisp enough to not interrupt your train of thought.
The follow-up trap — the one question that exposes candidates who memorized the surface but skipped the reasoning. Know it before the interviewer asks it.
In a real screening session, a candidate once explained Services perfectly — until the interviewer asked why a ClusterIP Service wouldn't work for their scenario. The candidate had the definition cold. The tradeoff reasoning wasn't there. That's the gap this cheat sheet closes.
Explain Pods, Deployments, Services, and Namespaces Without Rambling
Pods are the unit, Deployments are the manager
These are the Kubernetes interview questions that come up in virtually every mid-level screen, and the most common failure is blurring what each object actually owns.
30-second version: A Pod is the smallest deployable unit in Kubernetes — it wraps one or more containers that share a network namespace and storage. You don't usually create Pods directly because they're ephemeral; if a Pod dies, it stays dead. A Deployment manages Pods declaratively: you tell it what you want (three replicas of this container), and it creates the ReplicaSet that keeps that state true. The Deployment is the thing you actually operate; the Pod is the thing that runs your code.
One-liner: A Pod runs your container. A Deployment makes sure the right number of Pods are always running.
Follow-up trap: "Can you update a running Pod in place?" No — Pods are immutable once created. You update the Deployment spec, and it replaces Pods by rolling out new ones. Candidates who blur Pods and Deployments get caught here.
Services and namespaces are where interviews quietly test whether you actually use Kubernetes
A Service gives Pods a stable network identity. Pods get new IP addresses every time they restart, which means you can't hardcode a Pod IP anywhere. A Service sits in front of a set of Pods (selected by label) and gives you a consistent endpoint. In a real cluster running a backend API, the frontend doesn't talk to a Pod IP — it talks to the Service, and the Service handles routing regardless of which Pod instances are alive at any given moment.
Namespaces are how you carve a single cluster into logical environments. In practice, isolating `dev` and `prod` workloads into separate namespaces means you can apply different resource quotas, RBAC policies, and network policies per environment without spinning up separate clusters. The Kubernetes Namespaces documentation describes this as "virtual clusters" within a physical cluster — that framing is exactly right for an interview answer.
Follow-up trap for Services: "What happens if you delete a Service?" The Pods keep running. The Service is just a routing layer. Candidates who think deleting a Service kills the Pods reveal they don't understand the object separation.
Know the kubectl Commands Interviewers Expect You to Reach For
The commands you should know cold
kubectl command fluency is the fastest signal that you can operate a cluster, not just describe one. The kubectl reference documentation covers the full surface area, but for interviews, these are the ones you should be able to reach for without hesitation:
- `kubectl get pods -n <namespace>` — list Pods in a namespace; add `-o wide` for node placement
- `kubectl describe pod <name>` — full event log, conditions, and resource state for a Pod
- `kubectl logs <pod-name> -c <container>` — read container stdout/stderr; add `--previous` for the last crashed instance
- `kubectl exec -it <pod-name> -- /bin/sh` — shell into a running container for live inspection
- `kubectl apply -f <manifest.yaml>` — apply a declarative manifest
- `kubectl rollout status deployment/<name>` — check whether a rollout completed
- `kubectl port-forward pod/<name> 8080:80` — forward a local port to a Pod for local testing
What this looks like in practice
The command you reach for should change based on what you're trying to learn. If a Pod isn't starting, `kubectl describe pod` gives you the event log — that's where you see scheduling failures, image pull errors, and probe failures. If the Pod is running but behaving wrong, `kubectl logs` shows you what the application is actually saying. If you need to inspect the filesystem or test network connectivity from inside the container, `kubectl exec` gets you there.
In a real on-call situation, the difference between a 5-minute resolution and a 45-minute one often comes down to whether the responder reached for `describe` before firing off `logs`. `describe` gives you the Kubernetes-level story; `logs` gives you the application-level story. You usually need both, in that order.
Use create, apply, expose, rollout, logs, describe, exec, and port-forward for the Right Job
Why create vs apply is the question behind the question
When an interviewer asks about `create` versus `apply`, they're not testing whether you know the flags. They're testing whether you understand declarative versus imperative change management — and that distinction matters for how you operate a production cluster safely.
`kubectl create` is imperative: it creates a resource from scratch and fails if that resource already exists. `kubectl apply` is declarative: it creates the resource if it doesn't exist, and updates it if it does, using a three-way merge against the last-applied configuration. In a manifest-driven workflow, `apply` is almost always safer because it's idempotent. Running `apply` twice on the same manifest produces the same result. Running `create` twice throws an error. The Kubernetes task documentation on declarative management makes this distinction explicit.
What this looks like in practice
Here's the command-to-scenario mapping you should be able to say aloud:
create — use when bootstrapping a resource for the first time imperatively, or when you want to guarantee you're not overwriting something. `kubectl create deployment nginx --image=nginx`
apply — use for everything in a manifest-driven workflow. `kubectl apply -f deployment.yaml` is the standard day-to-day operation.
expose — creates a Service for an existing Deployment without writing a YAML manifest. `kubectl expose deployment nginx --port=80 --type=ClusterIP`. Useful in interviews for quick demos.
rollout — manages Deployment updates. `kubectl rollout status deployment/nginx` checks progress; `kubectl rollout undo deployment/nginx` rolls back to the previous ReplicaSet.
logs — reads container output. Add `--follow` to stream live; add `--previous` to read the last crashed container's output.
describe — the first command in any triage sequence. Shows events, conditions, resource requests, and scheduling decisions for any object.
exec — shells into a running container. Essential for network debugging, checking environment variables, or testing connectivity between services.
port-forward — maps a local port to a Pod or Service port. The fastest way to test an application without exposing it externally. `kubectl port-forward svc/my-service 8080:80`
The before-and-after on `create` vs `apply` is stark in real operations: a team that uses `create` in a CI/CD pipeline will hit errors the second time a pipeline runs on an existing cluster. Switching to `apply` eliminates that class of failure entirely.
Answer ClusterIP, NodePort, and LoadBalancer Like Someone Who Has Shipped Traffic
The service-type distinction interviewers actually care about
Kubernetes concepts around Service types trip up candidates who learned the definitions without thinking about the network path. The question isn't "what is a ClusterIP" — it's "who can reach the app, and how does traffic get there?"
ClusterIP is the default. It creates a virtual IP reachable only inside the cluster. Nothing outside the cluster can hit it directly. Use this for internal services — a database, a cache, an internal API that only other Pods need to reach.
NodePort opens a port (30000–32767) on every node in the cluster and forwards traffic to the Service. External clients can reach the app by hitting `<NodeIP>:<NodePort>`. It works, but it's awkward for production: you're exposing a high port number, and you're relying on knowing a node's IP. Most teams use it for dev/test access when they don't want to provision a load balancer.
LoadBalancer provisions an external load balancer from the cloud provider and routes traffic to the Service. This is the production-grade path for public-facing applications. In a real GKE or EKS cluster, creating a LoadBalancer Service provisions a cloud load balancer automatically and gives you a stable external IP.
What this looks like in practice
Map the three types to three scenarios and you'll never sound memorized:
- Internal microservice (e.g., a PostgreSQL database that only your API Pods should reach): ClusterIP. Nothing external should touch it.
- Dev environment quick access (e.g., testing a new service without provisioning cloud infrastructure): NodePort. Fast to create, acceptable for non-production traffic.
- Public-facing API or frontend: LoadBalancer. Cloud provider handles the external IP and routing.
Follow-up trap: "Can you reach a ClusterIP Service from outside the cluster?" No — not without a proxy or port-forward. Candidates who say "yes, if you know the IP" reveal they haven't actually shipped traffic through a cluster.
Make Deployment vs ReplicaSet Sound Obvious Instead of Vague
Why this comparison keeps showing up
This is one of the Kubernetes interview questions that sounds like a gotcha but isn't — it's checking whether you understand the control relationship between the two objects. A Deployment declares desired state: "I want three replicas of this container image, with this update strategy." A ReplicaSet does the actual pod replication work: it watches the current Pod count and creates or deletes Pods to match the desired count.
You almost never create a ReplicaSet directly. The Deployment creates and manages ReplicaSets on your behalf. When you update a Deployment (new image tag, new environment variable), Kubernetes creates a new ReplicaSet for the updated spec and scales it up while scaling the old one down — that's a rolling update.
What this looks like in practice
The rollback scenario makes this concrete. When you run `kubectl rollout undo deployment/my-app`, Kubernetes doesn't create anything new — it scales the previous ReplicaSet back up and scales the current one down. That previous ReplicaSet was preserved exactly for this purpose. If you had been managing ReplicaSets directly, you'd have no rollback mechanism.
One-liner: A Deployment manages ReplicaSets the same way a ReplicaSet manages Pods — one layer up in the control hierarchy.
Follow-up trap: "Why does `kubectl get replicasets` sometimes show multiple entries for the same Deployment?" Because Kubernetes keeps old ReplicaSets around for rollback history. The number kept is controlled by `revisionHistoryLimit` in the Deployment spec.
Treat Taints, Tolerations, and Scheduling as a Matching Problem
Why scheduling feels slippery until you explain the rules
Kubernetes concepts around scheduling feel abstract until you frame them as a matching problem: the scheduler is trying to place each Pod on a node where all the constraints are satisfied. Taints and tolerations are one part of that constraint system.
A taint is a property on a node that says "don't schedule Pods here unless they explicitly tolerate this." A toleration is a property on a Pod that says "I'm okay being placed on a node with this taint." The scheduler only places a toleration-bearing Pod on a tainted node if the toleration matches the taint's key, value, and effect.
What this looks like in practice
The practical scenario that makes this easy to explain: you have a node with a GPU. You taint it with `gpu=true:NoSchedule`. Now only Pods with a matching toleration will land on that node — your GPU-hungry ML workload gets the hardware it needs, and your standard web Pods don't accidentally consume GPU resources.
The reverse scenario also comes up: you want to keep noisy batch jobs off your latency-sensitive nodes. Taint the latency-sensitive nodes, and only Pods that explicitly tolerate that taint will be scheduled there.
Follow-up trap: "What's the difference between a taint effect of `NoSchedule` and `NoExecute`?" `NoSchedule` prevents new Pods from being placed on the node but doesn't evict existing ones. `NoExecute` evicts existing Pods that don't have a matching toleration. Candidates who only know `NoSchedule` get caught here.
The official scheduling documentation covers all three effects — `NoSchedule`, `PreferNoSchedule`, and `NoExecute` — and is worth a five-minute read before your interview.
Debug Pending, CrashLoopBackOff, and ImagePullBackOff Without Guessing
Start with the failure state, not random commands
Kubernetes debugging starts with the Pod state, not a random sequence of commands. Each state maps to a category of causes, and knowing the category tells you which command to run first.
Pending means the Pod hasn't been scheduled to a node yet. The cause is almost always one of three things: insufficient cluster resources (no node has enough CPU or memory), a node selector or affinity rule that no node satisfies, or a taint on all nodes that the Pod doesn't tolerate. Start with `kubectl describe pod <name>` and read the Events section — the scheduler will tell you exactly why it couldn't place the Pod.
CrashLoopBackOff means the container started, crashed, and Kubernetes keeps restarting it with exponential backoff. The container is running, at least briefly. The cause is in the application: a misconfigured environment variable, a missing dependency, a failed readiness check, or an application bug. Start with `kubectl logs <pod-name> --previous` to read the output from the last crashed instance.
ImagePullBackOff means Kubernetes can't pull the container image. The cause is one of: the image name or tag is wrong, the image doesn't exist in the registry, or the cluster doesn't have credentials to access a private registry. Start with `kubectl describe pod <name>` — the Events section will show the exact pull error message, including the registry response.
What this looks like in practice
The triage sequence for any broken Pod is always the same:
- `kubectl get pod <name> -o wide` — confirm the state and which node it's on
- `kubectl describe pod <name>` — read the Events section first, then Conditions
- `kubectl logs <name> --previous` (for CrashLoopBackOff) — read the last crash output
- `kubectl exec -it <name> -- /bin/sh` (if the container is running) — inspect the environment live
A real debugging story: a CrashLoopBackOff that looked like an application error turned out to be a missing environment variable that the app expected at startup. `kubectl logs --previous` showed the exact error in two seconds. Without `--previous`, you'd only see the output of the current (still-starting) container — which is often empty. That flag is the difference between a fast diagnosis and a long guessing session.
Follow-up trap: "How would you debug a Pod that's Running but not serving traffic?" That's a different problem — the Pod is healthy from Kubernetes' perspective, but the Service selector might not match the Pod's labels, or a readiness probe is failing. `kubectl describe service` and `kubectl get endpoints` are the right tools there.
Rehearse the Answers Until They Come Out Under Pressure
Why flashcards work only if they sound like speech
Reading an answer and saying an answer are different cognitive tasks. You can recognize a correct definition on a flashcard and still blank when someone asks the question live, because recognition and recall under social pressure use different retrieval pathways. The prep that actually transfers to interview performance is verbal rehearsal — saying the answer out loud, at interview pace, until the structure is automatic.
This isn't about sounding rehearsed. It's about not burning working memory on word choice when you should be burning it on reasoning. When the 30-second structure is automatic, you have cognitive headroom to handle the follow-up.
What this looks like in practice
Run this rapid-fire loop with the core questions from this cheat sheet:
- What's the difference between a Pod and a Deployment? (30 seconds)
- What Service type would you use for an internal-only microservice? (15 seconds)
- Walk me through debugging a CrashLoopBackOff. (45 seconds)
- What's the difference between `kubectl create` and `kubectl apply`? (30 seconds)
- What's a taint, and when would you use one? (30 seconds)
Time yourself. If you go over, cut the answer — not the content, but the filler words. The goal is precision, not brevity for its own sake. A colleague who prepped for a senior Kubernetes role ran this loop every morning for a week before the interview. The questions that had felt slippery in week one came out clean and confident by the end. That's the only prep that actually shows up in the room.
How Verve AI Can Help You Prepare for Your Interview With Kubernetes
The structural problem this cheat sheet addresses — knowing the material but not being able to compress it under pressure — doesn't fully resolve until you've practiced saying the answers live, with someone pushing back. Reading a cheat sheet builds recognition. Getting asked a follow-up question you didn't anticipate builds the actual skill.
Verve AI Interview Copilot is built for exactly that gap. It listens in real-time to your spoken answers and responds to what you actually said — not a canned prompt. If your Deployment explanation drifts into vague territory, Verve AI Interview Copilot surfaces the follow-up before your interviewer does. If your CrashLoopBackOff triage skips a step, it catches the gap. The practice loop isn't "read, memorize, hope" — it's a live conversation that mirrors what a real technical screen actually feels like. Verve AI Interview Copilot runs mock interviews at the pace and pressure of the real thing, stays invisible while it does, and gives you feedback grounded in what you said, not what you meant to say. For Kubernetes prep specifically, that means you can drill the pod-vs-deployment distinction, the service-type tradeoffs, and the debugging sequence until the 30-second answer is genuinely automatic — not just readable on a page.
FAQ
Q: What Kubernetes concepts are most likely to be asked in a mid-level interview?
Pods, Deployments, Services (all three types), Namespaces, ReplicaSets, and scheduling concepts like taints and tolerations cover the vast majority of mid-level screens. Debugging states — Pending, CrashLoopBackOff, ImagePullBackOff — come up in nearly every practical round. Labels and selectors are also high-frequency because they underpin how Services find Pods and how scheduling constraints get applied.
Q: How should I explain pods, deployments, services, namespaces, and labels in one or two lines each?
Pod: the smallest deployable unit; wraps one or more containers sharing a network and storage context. Deployment: manages a desired number of Pod replicas and handles rolling updates and rollbacks. Service: gives a stable network endpoint to a dynamic set of Pods selected by label. Namespace: a virtual partition within a cluster for isolating resources, quotas, and access controls. Label: a key-value tag on any Kubernetes object used for selection, grouping, and scheduling decisions.
Q: What kubectl commands do interviewers expect me to know cold?
`kubectl get`, `kubectl describe`, `kubectl logs`, `kubectl exec`, `kubectl apply`, `kubectl rollout`, and `kubectl port-forward` are the core set. Know what each one is trying to reveal, not just its syntax. `describe` gives you Kubernetes-level state and events; `logs` gives you application-level output; `exec` gets you inside the running container.
Q: When should I use create, apply, expose, rollout, logs, describe, exec, and port-forward?
`create` for one-time imperative resource creation; `apply` for all manifest-driven, repeatable workflows; `expose` to quickly create a Service for an existing Deployment without writing YAML; `rollout` to check update progress or trigger a rollback; `logs` to read container stdout/stderr; `describe` as the first step in any triage; `exec` to inspect a running container live; `port-forward` to test a service locally without external exposure.
Q: How do I troubleshoot a pod that is Pending, CrashLoopBackOff, or ImagePullBackOff?
Pending: run `kubectl describe pod` and read the Events section — the scheduler will state the exact reason it couldn't place the Pod (resource shortage, unsatisfied affinity, taint mismatch). CrashLoopBackOff: run `kubectl logs <name> --previous` to read the output from the last crashed container — the application error is almost always there. ImagePullBackOff: run `kubectl describe pod` and read the pull error in Events — it will show whether the issue is a bad image name, missing tag, or missing registry credentials.
Q: How do I explain ClusterIP, NodePort, and LoadBalancer without sounding memorized?
Map each type to an access scenario: ClusterIP for internal-only traffic between Pods, NodePort for dev/test access from outside the cluster without cloud infrastructure, LoadBalancer for production public-facing services that need a stable external IP from a cloud provider. Explaining who can reach the app — and why — sounds operational rather than recited.
Q: What is the difference between a Deployment and a ReplicaSet in interview terms?
A Deployment declares desired state and manages ReplicaSets. A ReplicaSet does the actual work of maintaining the correct Pod count. You interact with Deployments; Kubernetes manages ReplicaSets on your behalf. The practical proof: when you roll back a Deployment, Kubernetes scales the previous ReplicaSet back up — it was preserved specifically for that purpose.
Q: How do taints, tolerations, and node scheduling actually work?
A taint on a node repels Pods that don't have a matching toleration. A toleration on a Pod says it can be scheduled onto a node with that specific taint. The scheduler places a Pod on a tainted node only when the toleration matches on key, value, and effect. The three taint effects are `NoSchedule` (block new Pods), `PreferNoSchedule` (prefer to avoid but allow), and `NoExecute` (evict existing Pods that don't tolerate the taint).
Conclusion
The night before the interview, the pile of notes doesn't help as much as one clear system does. You now have that system: a 30-second answer for every object that comes up, the follow-up traps mapped out before the interviewer springs them, and a debugging sequence that starts with the failure state instead of random commands.
One thing left: say these answers out loud before you walk in. Not to sound rehearsed — to make the structure automatic enough that you can handle the follow-up without burning all your working memory on finding the right words. The confidence that shows up in the room isn't the confidence of someone who read the right article. It's the confidence of someone whose mouth already knows the answer.
Reese Nakamura
Interview Guidance
