10 Kubernetes Interview Questions (Pune, 2026)

The list

1. 1

   Explain the difference between a Pod, Deployment, and Service.

   Pod: the smallest deployable unit — wraps one or more containers sharing network + storage. Deployment: declarative manager for replicated, self-healing Pods (defines replicas, image, rollout strategy). Service: stable network endpoint that load-balances across the Pods of a Deployment (since Pod IPs change).

   Why it matters: Asked at ~90% of Pune K8s fresher rounds. Walking through a Deployment → ReplicaSet → Pod chain demonstrates ownership semantics.

   Best for: Foundation question; expected to know cold.

2. 2

   What are the different Service types and when do you use each?

   ClusterIP (default): internal-only IP, accessible only within cluster — for service-to-service. NodePort: exposes on a fixed port on every node — for dev/test access. LoadBalancer: provisions a cloud LB (ELB/ALB/NLB on AWS, etc.) — for external prod traffic. ExternalName: DNS alias to external service. Use Ingress on top of ClusterIP for production HTTP routing.

   Why it matters: Asked at ~70% of Pune rounds. Mention Ingress controllers (nginx-ingress, Traefik) as the modern production pattern.

   Best for: Networking depth; senior-fresher signal.

3. 3

   What's the difference between a Deployment and a StatefulSet?

   Deployment: stateless workloads — Pods are interchangeable, can be recreated with new identity. StatefulSet: stateful workloads (databases, queues) — Pods have stable identities (pod-0, pod-1), stable storage (PersistentVolumeClaims per Pod), ordered deployment + scaling. Use StatefulSet only when you need pod identity/order; Deployment for everything else.

   Why it matters: Asked at ~50% of Pune product company rounds. Common follow-up: 'when is StatefulSet the wrong choice?' (any stateless app — overhead without benefit).

   Best for: Workload-pattern matching; product company signal.

4. 4

   Explain liveness vs readiness probes.

   Liveness probe: 'is this Pod healthy?' If it fails, kubelet kills + restarts the Pod. Readiness probe: 'is this Pod ready to serve traffic?' If it fails, Service stops routing traffic to it (Pod stays running). Practical impact: liveness catches deadlocked apps; readiness handles slow-startup or temporarily-unavailable Pods (DB reconnect). Common mistake: same endpoint for both — readiness should be cheaper than liveness.

   Why it matters: Asked at ~65% of Pune rounds. Production-readiness signal — most reliable indicator of fresher-level deployment maturity.

   Best for: Reliability + ops depth differentiator.

5. 5

   What's the difference between a ConfigMap and a Secret?

   ConfigMap: non-sensitive configuration data (env vars, config files, command-line args). Plain text. Secret: sensitive data (passwords, API keys, TLS certs). Base64-encoded by default (NOT encryption — needs additional encryption at rest). Both mount as env vars or files. Modern best practice: Secrets Manager (AWS) or HashiCorp Vault + sealed-secrets controller for true encryption.

   Why it matters: Asked at ~60% of Pune rounds. Common gotcha: candidates think base64 is encryption — it's just encoding.

   Best for: Security + config-management foundation.

6. 6

   Explain rolling update vs recreate vs blue-green vs canary deployment strategies.

   Rolling update (Deployment default): gradually replace Pods, no downtime, no separate environment. Recreate: kill all old Pods, then create new — downtime but simpler. Blue-green: full second environment, switch traffic atomically — zero downtime but 2x resources. Canary: route small percentage of traffic to new version first, gradually increase — best for risk management. Kubernetes-native: rolling update + canary via Argo Rollouts/Flagger.

   Why it matters: Asked at ~50% of Pune rounds, especially product company + SRE-leaning interviews. Mention zero-downtime requirements + traffic-shifting tooling.

   Best for: Deployment strategy depth; SRE signal.

7. 7

   How do you debug a failing Pod?

   Standard troubleshooting flow: (1) `kubectl get pods` — check status (CrashLoopBackOff, Pending, Error). (2) `kubectl describe pod <name>` — check events at the bottom (image pull errors, scheduling failures, resource issues). (3) `kubectl logs <pod>` (or `--previous` for crashed containers). (4) `kubectl exec -it <pod> -- /bin/sh` for live inspection. (5) For networking: `kubectl exec` + ping/curl from inside cluster. Memorise the flow — interviewers ask 'walk me through debugging X'.

   Why it matters: Asked at ~75% of Pune rounds. Hands-on debugging mastery is the strongest fresher differentiator.

   Best for: Operational competence; expected fluency at every tier.

8. 8

   What is RBAC in Kubernetes and why does it matter?

   Role-Based Access Control: controls what a user / ServiceAccount can do in the cluster. Roles (namespace-scoped) + ClusterRoles (cluster-scoped) define permissions. RoleBindings + ClusterRoleBindings attach roles to users/groups/ServiceAccounts. Why it matters: prevents a compromised Pod from doing damage; mandatory for any production K8s cluster + most Pune BFSI / enterprise deployments.

   Why it matters: Asked at ~40% of Pune rounds; ~70% at BFSI tech (Allianz, BNP Paribas IT) where security depth matters.

   Best for: Security depth; differentiates beyond services-major tier.

9. 9

   Explain the Horizontal Pod Autoscaler (HPA).

   HPA scales the number of Pods in a Deployment/ReplicaSet based on observed metrics (CPU + memory by default; custom metrics via Prometheus Adapter). Define min + max replicas + target metric (e.g. CPU 70%). Kubernetes adjusts replica count every 15s. For traffic-based scaling, use Prometheus + custom metrics (requests per second).

   Why it matters: Asked at ~45% of Pune rounds. Mention Vertical Pod Autoscaler + Cluster Autoscaler as the complete scaling story.

   Best for: Scaling + capacity thinking; production-engineering signal.

10. 10

    What are Persistent Volumes + Persistent Volume Claims?

    PersistentVolume (PV): cluster-level storage resource provisioned by admin (or dynamically via StorageClass). PersistentVolumeClaim (PVC): user request for storage (size, access modes — ReadWriteOnce, ReadOnlyMany, ReadWriteMany). Pods reference PVCs, not PVs directly. Modern flow: define StorageClass once; PVCs dynamically provision PVs from it (no admin involvement for new PVCs).

    Why it matters: Asked at ~35% of Pune rounds, mostly product company + stateful-workload contexts. Services majors may skip this for pure-stateless fresher work.

    Best for: Storage architecture depth; stateful-workload roles.