Lesson 18 · Senior Kubernetes judgment

Senior Kubernetes interview questions

High-signal questions about control loops, rollout safety, StatefulSets, autoscaling, scheduling, and workload identity — with answer structures that sound like real operational experience.

Your win: answer senior Kubernetes questions with mechanism + trade-off + repo-grounded consequence, not just certification vocabulary or object definitions.

In plain English Plain English: strong Kubernetes answers explain what the object or controller does, what it does not fully guarantee, and why those differences matter operationally.

Why this page matters more than it first sounds

The base course taught the object model and repo usage. This page asks whether you can defend those choices honestly, especially where the repo diverges from textbook expectations or where multiple Kubernetes features must work together to create a believable safety story.

The strongest answers here usually do three things: name the mechanism, name the trade-off or limit, and connect it to a concrete repo consequence. That answer shape is what makes the explanation sound mature rather than memorized.

That last point matters a lot. Interviewers can usually hear the difference between someone reciting object definitions and someone explaining why those definitions matter in a real operating environment. This page is meant to help you sound like the second person.

The answer recipe Start with the real mechanism, name the important trade-off or limit, then finish with the repo-grounded consequence.

What stronger answers sound like

They sound narrower, calmer, and more truthful. Instead of “Kubernetes handles resilience,” a stronger answer says which controller is doing what, what the remaining failure boundary is, and how the repo config shapes the real outcome.

That is why the question bank below is written the way it is. It is not trying to make you memorize one perfect sentence. It is trying to train the rhythm of a strong answer.

Question bank

Question	Best answer shape
What does Kubernetes actually guarantee when people say it “self-heals”?	It keeps reconciling object state toward desired state, but application safety still depends on probes, rollout settings, and workload behavior.
Why isn’t a completed Deployment rollout automatically a safe rollout?	Because readiness, liveness, startup, disruption policy, and termination behavior still determine whether traffic and shutdown are handled safely.
Why are only two backend services StatefulSets in this repo?	Because most services are well-modeled as stateless Deployments; only `conversationmgmt` and `tom` need the stronger identity/lifecycle guarantees.
Why does this repo lean on KEDA instead of CPU-only HPA?	Because queue pressure and request-rate semantics often describe scaling need better than CPU, especially for consumers and event-driven paths.
What is the real value of Workload Identity here?	Pods get cloud access through ServiceAccount-to-GCP identity mapping without long-lived key files, which is central to the secret/KMS story.
Why are spot-node scheduling choices a senior topic?	Because cost savings come with eviction and placement trade-offs that have to be acknowledged honestly at the workload level.
What makes a StatefulSet choice believable instead of cargo-culted?	A clear explanation of what stable identity, ordering, or per-pod state contract would break if it became a Deployment.
Why is a PDB not the whole availability story?	Because it only bounds voluntary disruption; rollout safety and app-level drain behavior still matter separately.
What is the senior risk of over-trusting the control loop?	Believing the platform can compensate for weak health checks, wrong object choices, or poor workload semantics.
What should a senior Kubernetes review ask first?	What the design truly guarantees, where it is partial or misleading, and how recoverable the failure modes are.

Backend use case The strongest answers reference repo specifics like conversationmgmt / tom StatefulSets, notification Kafka-lag scaling, grpc_health_probe, PDB defaults, spot-node placement helpers, and Workload Identity through ServiceAccounts.

How to get the most out of this page

Cover the right-hand column and answer the question out loud first. Then look at the answer shape and ask yourself whether you included all three pieces: mechanism, trade-off or limit, and repo consequence. That small routine is what makes this page useful.

Use the playbook and repo map together

The playbook compresses the judgment layer; the repo map gives you the concrete objects and behaviors that make answers sound real.

→ Senior backend playbook
→ Repo K8s map

Check yourself (from memory)

Q1. A strong senior Kubernetes answer usually includes…

That structure is what turns object familiarity into believable operational judgment.

What are the three ingredients of a strong senior Kubernetes answer?

recall, then click to reveal

A clear mechanism, the important trade-off or limit, and a repo-grounded consequence or example.

When you’re ready, don’t just reread this page — go run the mock pack out loud. Ask me if you want me to conduct it live.

Sources. Repo K8s map; curated Kubernetes resources.