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 / 14 completed
1 / 14
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 / 14
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 / 14
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 / 14
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 / 14
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.
6 / 14
Reviewer: David left this comment on a pull request introducing a new service: 'This deployment seems overly complex. Consider using a HorizontalPodAutoscaler (HPA) to scale the number of pods based on CPU utilization. Also, ensure your metrics server is correctly configured.
David's comment highlights key aspects of Kubernetes scaling and monitoring. An HPA (HorizontalPodAutoscaler) dynamically adjusts pod count based on resource metrics, which is a standard practice for handling variable workloads. Furthermore, the Metrics Server provides crucial CPU utilization data that an HPA relies upon – ignoring this would prevent effective autoscaling.
7 / 14
You're deploying a new application to Kubernetes and need to ensure sensitive information like database passwords are not stored directly in your container images. Which of the following approaches is BEST for managing these secrets securely?
Directly embedding secrets into images (option A) is a major security risk. Storing secrets in plaintext within the application code (option B) also exposes them to potential compromise. Kubernetes Secrets (option C) provide an encrypted storage mechanism for sensitive data, and referencing them in your pod definitions allows you to securely access the information without exposing it directly.
8 / 14
Mark (Team Lead) asks during a standup: 'How are we handling rollbacks if a new deployment fails?'. Which strategy would be MOST appropriate for implementing a robust rollback mechanism in your Kubernetes deployments?
While simply deleting and redeploying (option A) can sometimes work, it doesn't guarantee a clean rollback or minimize downtime. Blue-green deployments (option B) provide an isolated environment for testing new versions before switching traffic, enabling quick rollbacks. `revisionHistoryLimit` allows you to retain previous revisions but doesn't automate the rollback process – it's a manual intervention.
9 / 14
You're preparing a pull request to update your application's Kubernetes deployment. To ensure zero downtime during the update, what is the MOST critical step you should implement?
Rolling updates (option A) are designed for zero-downtime deployments. They gradually replace old pods with new ones, ensuring that at least some pods are always serving traffic while the update is in progress. The other options introduce downtime or require complex manual intervention.
10 / 14
Sarah (Senior Engineer) flags a comment on your PR describing the following: 'The current deployment lacks any health checks. Without these, Kubernetes won't automatically detect unhealthy pods and replace them, leading to potential service disruptions. We need to explicitly define readiness and liveness probes.' Which of the following best describes how you should address Sarah's feedback? kubectl describe deployment my-app
The key here is understanding Kubernetes' automatic remediation. While a basic liveness probe can help, it doesn't guarantee service availability if pods are genuinely unhealthy. Readiness probes are crucial for determining when a pod is *ready* to receive traffic. Implementing both ensures robust health monitoring and proactive replacement of failing pods – Sarah's feedback directly addresses this critical aspect of deployment stability.
11 / 14
As a member of the DevOps team, you're investigating why new deployments to your Kubernetes cluster are taking significantly longer than expected. After reviewing logs, you notice frequent `ImagePullBackOff` errors. Which of the following is the MOST likely cause? kubectl describe pod my-app-pod
'ImagePullBackOff' errors almost always indicate an issue with pulling container images. This commonly happens when the image isn't present in the registry or if there's a problem during the download process (e.g., network issues, incorrect image tag). While congestion and scheduler overload *could* contribute, they wouldn't directly cause this specific error message; code bugs are less likely to manifest as immediate failures during image pulls.
12 / 14
During a Slack conversation with the team, Alex asks: 'How do we ensure our sensitive configuration data (like database passwords) isn't hardcoded in our Docker images?' Which of the following is the BEST approach? kubectl get secrets my-app-secrets
Hardcoding secrets into Docker images is a major security risk. Using environment variables is better but still exposes secrets in image layers. Secret management systems like Vault or Kubernetes Secrets provide centralized storage, encryption at rest, and controlled access to sensitive information – this is the industry-standard best practice for securing your applications.
13 / 14
You're designing a new feature that requires complex state management. The team suggests using Kubernetes Operators to automate the creation and management of resources related to this feature. Which statement BEST describes the core purpose of a Kubernetes Operator? kubectl create -f operator.yaml
Kubernetes Operators are designed to mimic how a human operator would manage complex applications. They go beyond simple deployments by automating tasks like scaling, backups, and upgrades, all based on custom resources defined through CRDs (Custom Resource Definitions). They essentially *operate* on your Kubernetes cluster in a more intelligent way.
14 / 14
During a standup meeting with the development team, you are asked: 'What's our plan for rolling back to the previous version if this new deployment causes issues?' Which of the following rollback strategies would be MOST appropriate? kubectl rollout undo deployment my-app
Kubernetes provides a robust and automated mechanism for rollbacks through its 'rolling update' feature. This allows you to safely revert to a previous version of your deployment while minimizing downtime and ensuring service continuity. Manual deletion or restoring from backups are far less efficient and introduce significant risk.
What does "Kubernetes Engineer — Technical Interview Questions in English" cover?
Practice answering Kubernetes Engineer interview questions in professional English. 5 exercises covering workload controllers, scheduling, secrets management, Operators, and zero-downtime deployments.
How many questions are in this interview set?
This set has 14 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.