Databricks Containers & Kubernetes interview questions

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

Almost always a finalizer, and the fast fix is the one that loses data. The safe answer explains what the finalizer is protecting against before removing it.

The scheduler is behaving correctly, which is the part that confuses people. It optimises placement at admission time and never revisits, so a cluster drifts out of balance by design.

A specific configuration trap with a clean explanation. Both controllers act on the same signal from opposite directions, which can produce unstable feedback depending on their policies and workload.

Default-deny egress breaks name resolution before it breaks anything else, and every connection times out confusingly. The practitioners are the ones who test with positive AND negative probes and know their CNI's fine print.

The two ideas that decide whether an operator is safe are level-triggered reconciliation and finalizer semantics. The partition question separates people who have written a controller from people who have installed one.

Namespaces partition resources, not trust. This question finds the people who know which sysctls are namespaced, which ones change every tenant at once, and when only a second kernel will do.

Multiple schedulers are supported, rarely understood, and dangerous in a specific way. The strong answer names the deadlock that gang scheduling fixes and the capacity race it can open.

Repeated full-resource polling can make an operator an expensive API client. This question separates people who run controllers at ten-thousand-object scale from those who copied a tutorial: watch semantics, cache behaviour, and which LISTs touch etcd.

SSH plus yum is how outages start. The senior answer replaces nodes from versioned images on a cadence, orchestrates with surge capacity and PDBs, and can explain the kernel-skew problem that makes fleet homogeneity a feature.

Two artifacts hide under 'Kubernetes backup' and they recover different things. The misses are what decides whether a restore works: volume bytes, encryption keys, and everything that never lived in etcd at all.

Tenancy is a dial from policy-based soft isolation to hard cluster boundaries with a virtual-control-plane middle ground. The scored answer picks by blast radius requirements and names what each model still leaves shared.

Driver, container toolkit, device plugin, DCGM and discovery must version-match on every node. The operator reconciles that ladder from one ClusterPolicy CR; MIG, upgrades and host kernels are where it bites.

Changing pod resources historically required recreation, which made vertical autoscaling disruptive for workloads with expensive recovery. In-place resize changes that, with limits worth knowing.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

Everyone can recite the three. Explain what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.