Kubernetes Interview Questions

A curated set of Kubernetes interview questions, ordered roughly from fundamentals to more practical, day-to-day scenarios — the kind you'll actually be asked in real screens and on-sites.

Core objects#

Q: What's the difference between a Pod, a Deployment, and a Service? A Pod is the smallest deployable unit — one or more tightly-coupled containers sharing network and storage — but has no self-healing behavior on its own. A Deployment manages a set of identical Pods declaratively: it recreates failed Pods automatically and handles rolling out new versions gradually. A Service gives a stable, load-balanced network identity to a set of Pods selected by label, since individual Pod IPs change every time a Pod is recreated.

Q: What's the difference between a ConfigMap and a Secret? Both store key-value configuration data injectable into Pods as environment variables, and structurally they're nearly the same. ConfigMaps are meant for non-sensitive settings, while Secrets are meant for sensitive values like passwords and API keys — Secrets are base64-encoded (not encrypted by default, so encoding alone shouldn't be treated as security) and typically get tighter default access controls than ConfigMaps.

Deployments and rollouts#

Q: How does a Kubernetes rolling update avoid downtime? Instead of stopping every old Pod and starting every new one at once, a rolling update replaces Pods incrementally: maxUnavailable limits how many Pods can be down at any moment, and maxSurge allows temporarily running extra Pods above the desired replica count so capacity doesn't dip while old Pods are being phased out. Readiness probes ensure traffic only reaches new Pods once they're actually ready to serve it.

Q: If a bad deployment is rolled out to production, how do you recover quickly? kubectl rollout undo deployment/<name> reverts the Deployment to its previous revision, triggering another rolling update back to the last known-good version — Kubernetes keeps a revision history specifically to make this fast. This is why declarative rollouts through a Deployment (rather than manually replacing containers) matter operationally: recovery is a single, well-understood command instead of a manual scramble.

Services and networking#

Q: What are the three common Kubernetes Service types, and when would you use each? ClusterIP (the default) is only reachable from inside the cluster, used for internal service-to-service traffic. NodePort exposes the service on a fixed port on every node's IP, often used for simple or temporary external access. LoadBalancer provisions an actual external load balancer/IP from the cloud provider and is the standard choice for production traffic coming from the public internet.

Q: Why does a Service keep working even as the Pods behind it are replaced during a rollout or failure? A Service doesn't target specific Pod IPs directly — it continuously selects whichever currently-running Pods match its label selector, and load-balances traffic across only the healthy, ready ones. As old Pods are terminated and new ones created during a rollout, the Service's set of targets updates automatically without any client needing to know a single Pod's address changed.

Q: What problem does an Ingress solve that a LoadBalancer Service doesn't? A LoadBalancer Service provisions one real external load balancer per Service and has no concept of host- or path-based HTTP routing or TLS. An Ingress describes routing rules for multiple hostnames and paths across several different Services behind one shared entry point, so a single external address can route /api/ to one Service and everything else to another, and terminate TLS centrally — avoiding a separate, costly cloud load balancer per Service. An Ingress resource requires an Ingress Controller actually running in the cluster to do anything; the resource alone is just a declaration.

Helm and packaging#

Q: What problem does Helm actually solve, and what's the difference between a chart and a release? Helm solves the problem of deploying the same set of related Kubernetes manifests (a Deployment, Service, ConfigMap, and more) consistently across multiple environments without copy-pasting near-identical YAML and letting it drift out of sync. A chart is the reusable, templated package of manifests plus its default values; a release is a specific named, tracked instance of that chart actually installed into a cluster — the same chart can be installed multiple times under different release names (e.g., my-app-staging and my-app-prod) with different value overrides for each.

Production readiness#

Q: What does a PodDisruptionBudget protect against, and what doesn't it protect against? It caps how many Pods from a set can be voluntarily taken down at once by cluster-initiated actions like a node drain during an upgrade or the cluster autoscaler consolidating nodes — minAvailable/maxUnavailable ensures enough replicas stay up throughout that process. It does not protect against involuntary disruption, like a node crashing unexpectedly — nothing can force a hardware failure to respect a budget; a PDB only governs disruptions the cluster is choosing to schedule.

Q: What's the difference between a liveness probe and a readiness probe, and why might a container want different endpoints for each? A failing readiness probe pulls a Pod out of a Service's traffic rotation without restarting it — appropriate for a temporary condition like a downstream dependency being briefly unavailable. A failing liveness probe gets the container killed and restarted — appropriate only when the container itself is genuinely broken and won't recover on its own, like a deadlock. Using the same strict check for both means a transient, recoverable issue (readiness should catch this) ends up triggering an unnecessary restart (which only liveness should cause) that doesn't actually fix anything, since the real problem is external to the container.