All jobs / DevOps / SRE / cloud
Kubernetes interview questions
Kubernetes questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A service’s health URL always returns 200 from the process start. What did you miss?
The strongest answer: Readiness: it should fail until it can take traffic (migrations, dependencies) — liveness is “should we restart,” not “should we send users”
Why it works: Exactly. Ready versus alive. A 200 from a booting process is how you 500 the users.
- Liveness ≠ readiness.
- Fail ready until you can serve.
- Do not 200 from a boot.
- Keep the check.
A candidate says “Kubernetes is Docker for production.” What is the cleaner sentence?
The strongest answer: Kubernetes schedules containers across machines (pods, services, desired state); Docker is one way to build and run a container — they are not synonyms
Why it works: Exactly. Scheduler versus container runtime / builder. Precision is the junior bar.
- K8s = schedule desired state.
- Images still exist.
- Docker is one ecosystem, not the cluster.
- Do not synonym them.
Which Kubernetes object do you reach for: a stateless API, a database, a log agent on every node, and a nightly clean-up?
The strongest answer: Deployment for the API, StatefulSet for the database (stable identity and per-pod storage), DaemonSet for the agent, and a CronJob that creates Jobs for the clean-up
Why it works: Exactly — each controller encodes a different lifecycle: replaceable replicas, ordered stateful identity, one-per-node, run-to-completion.
- Pick the controller by lifecycle.
- Deployment: stateless replicas.
- StatefulSet: identity and storage.
- DaemonSet per node; CronJob for schedules.
ConfigMap or Secret for a database password — and is a Secret encrypted?
The strongest answer: Secret, but by default it is only base64-encoded in etcd, not encrypted; I enable encryption at rest, restrict who can read secrets with RBAC, or source them from an external secret manager
Why it works: Right — base64 is encoding, not encryption. A Secret is a slightly better-guarded ConfigMap until you configure the rest.
- Secret, then harden it.
- base64 is not encryption.
- Encrypt etcd at rest; scope RBAC.
- Or use an external secret store.
A pod is killed in a loop while it is still migrating. Which probe was wrong?
The strongest answer: Liveness fired too early — I want a startup probe or a longer grace, and readiness to keep traffic off until migrate is done
Why it works: Exactly. Startup / grace for boot work; readiness for traffic; liveness for deadlock. One URL for all three is how you flap.
- Startup or grace for migrate.
- Readiness gates traffic.
- Liveness is for deadlock.
- Do not use one URL for all three blindly.
Pods are Pending while nodes look empty in the console. What did you forget?
The strongest answer: Requests: the scheduler needs a number, and a huge request will not fit even if RSS is small right now
Why it works: Exactly. Requests are the reservation. Empty-looking nodes can still be fully reserved.
- Requests = reservation.
- Look at allocatable, not a casual CPU graph.
- Do not zero requests to pack.
- Limits ≥ requests.
You have five HTTP services. One Service of type LoadBalancer each, or an Ingress?
The strongest answer: An Ingress (or Gateway API) behind one controller: one cloud load balancer, routing by host and path, TLS terminated in one place — a LoadBalancer Service each is five bills and five certificates
Why it works: Exactly — Ingress is the layer-7 front door; the controller does the routing, and you pay for one L4 load balancer.
- Ingress for HTTP routing.
- One LB, many hosts and paths.
- Terminate TLS in one place.
- LoadBalancer Service only where L4 is needed.
What does Helm give you over applying raw YAML, and what does `helm rollback` not do?
The strongest answer: Templated charts with per-environment values and release tracking — history, upgrade, rollback of the whole set; rollback restores the manifests, not a database migration or data the new version wrote
Why it works: Right — Helm manages releases, not state. Pair every schema change with a backward-compatible plan regardless of the tool.
- Charts plus values plus releases.
- One command rolls back the set.
- Manifests, not data.
- Plan the schema separately.
The pods are Running, but calls to the Service get connection refused.
Walk me through the diagnosis.
The strongest answer: `kubectl get endpoints` for the Service — empty means the selector does not match the pod labels or the pods are not Ready; populated means check targetPort against the container port and the readiness probe
Why it works: Exactly — a Service routes to endpoints, and endpoints are pods matching the selector and passing readiness. Empty list, wrong labels or not ready.
- Service routes to endpoints.
- Check kubectl get endpoints.
- Selector, readiness, targetPort.
- Running is not Ready.
The cluster is two versions behind. How do you catch up?
The strongest answer: A train: one minor at a time, control plane then nodes, with a backup of etcd / state and a tested workload — I do not leap two minors on a Friday
Why it works: Exactly. Stepwise, control plane first, a restore story. Pin-forever is a security hole.
- One minor at a time.
- Control plane, then nodes.
- Know restore.
- Do not pin forever.
Pods cannot reach an external API that works from your laptop. What do you check in the cluster?
The strongest answer: DNS inside the cluster, NetworkPolicies / egress firewall, and NAT — I do not start by rewriting the client
Why it works: Exactly. Cluster DNS, policy, NAT. Laptop-works is a clue, not a client bug by default.
- Cluster DNS first.
- Then egress policy / NAT.
- Do not hostNetwork the fleet.
- Do not open the world.
HPA keeps adding pods; memory still climbs per pod. What is going on?
The strongest answer: A leak or an unbounded cache — scale-out is buying time, not a fix — I will cap replicas and find the growth
Why it works: Exactly. HPA × leak = a bill and a slower crash. Cap and fix.
- Treat rising RSS as a leak.
- Cap the HPA.
- Fix the growth.
- Do not scale your way out of a leak.
A cluster has no NetworkPolicies. What do you install without boiling the ocean?
The strongest answer: A default-deny in namespaces that want it, then allow the paved paths (app → db, ingress → app) — I do not flip deny on the whole fleet on a Friday
Why it works: Exactly. Opt-in deny, pave the allows. Theatre allow-all and Friday-fleet-deny are two ways to fail.
- Default-deny where you can support it.
- Pave the allows.
- Do not Friday the fleet.
- Do not ship allow-all theatre.
You run one precious cluster that cannot be rebuilt. What is the programme?
The strongest answer: Treat it as debt: etcd backup you have restored, a second control plane or a rebuild path, and a rule that new state must be reconstructible — a pet cluster is a career-limiting object
Why it works: Exactly. Reconstructible or it is a pet. Size and a name are not a restore.
- Restore etcd for real.
- Have a rebuild path.
- New state must be IaC.
- Do not keep a holy cluster.
Thirty teams share a few clusters. Requests for cluster-admin “just to deploy” arrive weekly.
How do you hand out access?
The strongest answer: A namespace per team and environment, Roles and RoleBindings scoped to it and bound to SSO groups, quotas and admission policies — cluster-admin stays a logged break-glass, never a daily role
Why it works: Right — least privilege in Kubernetes is namespace scope plus group binding; the platform enforces the boundary instead of asking for care.
- Namespace per team and environment.
- Role plus RoleBinding, not ClusterRole.
- Bind groups, not people.
- Cluster-admin is break-glass.