USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. Explain the core Kubernetes architecture.
Short answer: A control plane (API server, scheduler, controller-manager, etcd) manages worker nodes running kubelet and pods.
Strong answer: The control plane exposes the API server (the single source of truth backed by etcd), the scheduler assigns pods to nodes, and controllers reconcile desired vs actual state. Worker nodes run the kubelet (which manages pods), a container runtime, and kube-proxy for networking. Everything is declarative and reconciled continuously — current to Kubernetes 1.36.
Likely follow-up: What happens when etcd is unavailable?
What the interviewer is checking: Whether you understand the declarative, reconciliation-based model.
Common mistake: Describing it as an imperative system that runs commands once.
Q2. What is the difference between a Deployment, StatefulSet and DaemonSet?
Short answer: Deployment for stateless replicas, StatefulSet for stable identity/storage, DaemonSet for one pod per node.
Strong answer: Deployments manage interchangeable stateless pods with rolling updates. StatefulSets give stable network identities and persistent volumes for ordered, stateful apps (databases, queues). DaemonSets run exactly one pod per node for agents like logging or monitoring. Choose by whether pods need identity, ordering or per-node placement.
Likely follow-up: Why can’t you use a Deployment for a clustered database?
What the interviewer is checking: Workload-selection judgment.
Common mistake: Using a Deployment for stateful workloads that need stable identity.
Q3. How does a Service expose pods, and what are the Service types?
Short answer: A Service load-balances to pods via selectors; types are ClusterIP, NodePort, LoadBalancer and ExternalName.
Strong answer: A Service provides a stable virtual IP and DNS name and routes to matching pods by label selector, decoupling clients from pod churn. ClusterIP is internal-only, NodePort exposes a port on every node, LoadBalancer provisions a cloud LB, and ExternalName maps to an external DNS name. Ingress sits above Services for HTTP routing.
Likely follow-up: How does traffic actually reach a pod behind a ClusterIP?
What the interviewer is checking: Understanding of Kubernetes networking.
Common mistake: Confusing Ingress with a Service type.
Q4. How do you debug a pod stuck in CrashLoopBackOff?
Short answer: Check logs, describe the pod, inspect events, resources and probes, then fix the root cause.
Strong answer: Run kubectl describe pod for events, kubectl logs (and --previous) for the crash reason, and check resource limits, failing liveness probes, missing config/secrets, or a bad image/command. CrashLoopBackOff means the container keeps exiting; the fix depends on the actual exit cause, so read the logs and events first.
Likely follow-up: How would a too-aggressive liveness probe cause this?
What the interviewer is checking: Practical troubleshooting method.
Common mistake: Guessing at fixes without reading logs and events.
Q5. Explain requests and limits, and how they affect scheduling and QoS.
Short answer: Requests reserve resources for scheduling; limits cap usage; together they set the pod’s QoS class.
Strong answer: Requests are what the scheduler uses to place pods and are guaranteed; limits cap CPU (throttled) and memory (OOM-killed if exceeded). Pods with requests==limits get Guaranteed QoS, partial get Burstable, none get BestEffort — which affects eviction order under pressure. Set both thoughtfully to balance density and reliability.
Likely follow-up: What happens when a container exceeds its memory limit?
What the interviewer is checking: Resource-management understanding.
Common mistake: Setting no requests/limits, causing noisy-neighbor and eviction issues.
Q6. How do rolling updates and rollbacks work in a Deployment?
Short answer: The Deployment gradually replaces old ReplicaSet pods with new ones and can roll back to a prior revision.
Strong answer: A Deployment creates a new ReplicaSet and scales it up while scaling the old one down, honoring maxSurge/maxUnavailable and readiness probes so traffic only hits ready pods. If something breaks, kubectl rollout undo returns to a previous revision. Health probes are what make this safe.
Likely follow-up: Why are readiness probes essential during a rollout?
What the interviewer is checking: Safe-deployment knowledge.
Common mistake: Rolling out without readiness probes, sending traffic to unready pods.
Q7. How do you manage configuration and secrets in Kubernetes?
Short answer: ConfigMaps for non-sensitive config, Secrets for sensitive data, injected as env vars or mounted files.
Strong answer: ConfigMaps hold non-sensitive configuration; Secrets hold sensitive values (base64-encoded, ideally encrypted at rest and backed by an external secrets manager). Both mount as env vars or files. Keep them out of images, scope access with RBAC, and rotate secrets. For real security, integrate a KMS or external secrets operator.
Likely follow-up: Are Kubernetes Secrets encrypted by default?
What the interviewer is checking: Config/security awareness.
Common mistake: Assuming Secrets are strongly encrypted out of the box.
Q8. What is an Ingress and how does it differ from a LoadBalancer Service?
Short answer: Ingress does host/path-based HTTP routing via a controller; a LoadBalancer Service exposes one service at L4.
Strong answer: An Ingress resource defines HTTP(S) routing rules (hosts, paths, TLS) and needs an Ingress controller (NGINX, cloud) to implement them — letting many services share one entry point. A LoadBalancer Service provisions a dedicated L4 load balancer per service. Ingress is more cost-efficient and flexible for HTTP; gateways/Gateway API are the emerging evolution.
Likely follow-up: When would you still use a LoadBalancer Service directly?
What the interviewer is checking: Traffic-routing design.
Common mistake: Provisioning a cloud LB per service instead of using Ingress.