5 exercises — choose the best-structured answer to common Kubernetes Engineer interview questions covering Deployment vs StatefulSet vs DaemonSet, scheduling, secrets, Operators, and zero-downtime deployments.
Structure for Kubernetes Engineer answers
Tip 1: Workload types: Deployment=stateless, StatefulSet=stable identity, DaemonSet=per-node
Tip 3: Secrets: base64 is NOT encryption; use etcd KMS encryption + External Secrets Operator
Tip 4: Zero downtime: readiness probes + maxUnavailable:0 + PDB + PreStop hook are all required
0 / 5 completed
1 / 5
The interviewer asks: "What is the difference between a Deployment, a StatefulSet, and a DaemonSet?" Which answer best demonstrates Kubernetes workload knowledge?
Option B is strongest because it defines each controller by its core property (stateless/stable identity/per-node) and gives concrete use cases for each. Key structure: Deployment (stateless, interchangeable, rolling updates) → StatefulSet (stable identity, ordered create/delete, persistent volumes) → DaemonSet (one pod per node, infrastructure agents). Option A is a rough heuristic but incorrect (StatefulSets are not exclusively for databases). Option C is incorrect. Option D ("always use StatefulSets") is wrong.
2 / 5
The interviewer asks: "How does Kubernetes handle pod scheduling and what can go wrong?" Which answer best demonstrates scheduling knowledge?
Option B is strongest because it explains the filter-score two-phase model, names the filtering criteria, and gives four concrete failure modes with diagnoses and fixes. Key structure: filtering (resource/labels/affinity/taint) → scoring (least-requested/spread) → failures: Pending (check resource/labels/PVC) → OOMKilled (low requests) → topology spread misconfiguration → taint/toleration errors. Option A oversimplifies (it is least-requested, not most-available). Option C is incorrect (not round-robin). Option D is incorrect (engineers configure scheduling constraints).
3 / 5
The interviewer asks: "How do you manage secrets in Kubernetes securely?" Which answer best demonstrates Kubernetes secrets best practices?
Option B is strongest because it identifies the base64-not-encryption weakness, describes etcd encryption, recommends external secrets integration, enforces RBAC, prefers volume mounts, and includes audit logging. Key structure: base64 fallacy → etcd encryption (AES-GCM/KMS) → External Secrets Operator/CSI Driver → RBAC (restrict list verb) → volume mounts > env vars → audit log → rotate/TTL. Option A describes a naive but common approach. Option C is incorrect (Kubernetes Secrets are NOT encrypted by default). Option D (ConfigMap) is worse than Secrets — ConfigMaps have no encryption intent at all.
4 / 5
The interviewer asks: "What is a Kubernetes Operator and when would you write one?" Which answer best demonstrates CRD and Operator knowledge?
Option B is strongest because it defines the control loop model, explains CRDs as API extensions, and gives concrete use cases with real examples (Postgres Operator, cert-manager, ArgoCD). Key concepts: custom controller, control loop, CRD, reconcile loop, stateful operational knowledge, examples: DB lifecycle/cert rotation/GitOps, Operator SDK/Kubebuilder. Option A misunderstands "operator" (human vs software). Option C confuses Operators with Helm. Option D over-broadly applies operators to configuration.
5 / 5
The interviewer asks: "How do you implement zero-downtime deployments in Kubernetes?" Which answer demonstrates production deployment engineering?
Option B is strongest because it describes all layers of zero-downtime: rolling strategy parameters, readiness probes, PDBs, PreStop hooks with grace periods, LB connection draining, and progressive delivery tools. Key structure: maxUnavailable:0/maxSurge:1 → readiness probes → PDB (minAvailable) → PreStop hook + terminationGracePeriodSeconds → LB connection draining → canary/blue-green (Argo Rollouts/Flagger). Option A is partially true but omits all required configuration. Option C references a deprecated command. Option D (scale to 0) causes definitive downtime.