Kubernetes interview questions

The debugging scenario

"A pod is in CrashLoopBackOff. Walk me through it." A method, in order:

• `kubectl describe pod` first - events at the bottom tell you whether it is scheduling, image pull, or the container exiting.
• `kubectl logs` for the current attempt, and `--previous` for the one that crashed. Forgetting `--previous` is a common gap.
• Distinguish the categories: image pull failure, a failing liveness probe, an OOMKill, a missing config map or secret, or the app exiting on a bad configuration.
• `kubectl get events --sort-by` for the cluster view.
• For OOMKills, check the limit against actual usage rather than simply raising the limit.

Probes, routinely confused

• Liveness - if it fails, the container is restarted. Set it wrong and you restart a healthy but slow app.
• Readiness - if it fails, the pod is removed from service endpoints but keeps running. This is the one you want during startup or temporary dependency loss.
• Startup - suspends the other two until the app has booted, which is the right tool for slow starters.
• The classic incident: a liveness probe pointed at an endpoint that depends on a database, so a database blip restarts every pod simultaneously.

Workloads and networking

• Deployment versus StatefulSet versus DaemonSet - and what StatefulSet actually guarantees.
• How does a Service find its pods, and what happens to in-flight requests during a rolling update?
• ClusterIP, NodePort, LoadBalancer and Ingress - what each is for.
• Requests versus limits, and what happens when requests are unset (poor scheduling) or limits are too low (throttling and OOMKills).
• How does a rolling update work, and how do you roll one back?

Config, storage and security

ConfigMaps and Secrets - and the honest note that Secrets are base64-encoded rather than encrypted by default. Then persistent volumes and claims, and why storage makes StatefulSets harder than Deployments. Security questions - RBAC, pod security, what should not run as root - overlap with security engineer interview questions. The broader operational ground is in DevOps interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and honesty about what you have not done reads better than bluffing.
• Mid-level: the same ground, plus a cluster you have operated. Expect follow-ups asking why you made a particular choice rather than whether you know the syntax.
• Senior: an incident you debugged under time pressure, and what you automated afterwards. At this level the language questions get shorter and the judgement questions get longer.

Whatever the level, the reliable way to prepare is to say your answers out loud rather than reading them. Most of what candidates lose in a Kubernetes interview is lost in the gap between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common Kubernetes interview questions?

Debugging a pod in CrashLoopBackOff, the difference between liveness, readiness and startup probes, requests versus limits, Deployment versus StatefulSet, and how Services route traffic during a rolling update.

How do you debug a pod in CrashLoopBackOff?

Start with `kubectl describe pod` and read the events, then `kubectl logs --previous` to see the crashed attempt rather than the current one. From there separate image pull failures, failing liveness probes, OOMKills and missing config from an application exiting on bad configuration.

What is the difference between liveness and readiness probes?

A failing liveness probe restarts the container; a failing readiness probe only removes the pod from service endpoints while leaving it running. Using liveness where readiness belongs causes restart storms, particularly when the probe depends on an external dependency.

Are Kubernetes Secrets encrypted?

Not by default - they are base64-encoded in etcd, which is encoding rather than encryption. Encryption at rest must be enabled explicitly, and many teams use an external secret manager instead. Knowing this distinction is a frequent interview check.