Kubernetes Interview Questions: What Cloud Engineers Get Asked

Kubernetes has gone from a specialist skill to a baseline expectation at mid-level and senior cloud engineering roles. Most cloud job descriptions now list it as required or strongly preferred, even when the role is not explicitly a “Kubernetes engineer” role. This means interviews probe K8s knowledge routinely — and candidates who treat it as a side topic often fail screens they could otherwise pass.

This page covers what interviewers actually ask, what they are testing for behind each question, and where candidates consistently go wrong.

What Level of Kubernetes Knowledge Is Expected#

Junior roles — Interviewers typically expect familiarity with core concepts: what a pod is, what a deployment does, how services work. You are not expected to have managed a production cluster. But you should be able to read a YAML manifest and reason about what it does.

Mid-level roles — You are expected to have worked with Kubernetes in a real environment. Interviewers will probe troubleshooting ability, resource configuration, and practical experience with deployments, rollouts, and basic networking. Knowing how to debug a failing pod is table stakes.

Senior roles — Interviewers expect deeper knowledge: cluster architecture, RBAC design, network policies, storage considerations, and meaningful opinions about cluster operations. They also expect you to know when Kubernetes is the wrong answer for a problem.

Why Kubernetes Appears So Often in Cloud Interviews#

Three things pushed K8s into mainstream hiring:

First, most cloud-native application patterns now assume containers, and most container orchestration at scale happens on Kubernetes. Engineers who cannot work with K8s struggle to contribute to modern infrastructure.

Second, all three major cloud providers have managed Kubernetes services (GKE, EKS, AKS) that are widely used in production. Cloud engineers are routinely asked to manage these services even when their job title makes no mention of containers.

Third, Kubernetes knowledge is difficult to fake in interviews. Questions about how the scheduler works, or how a CrashLoopBackOff differs from an OOMKill, quickly separate engineers who have used K8s from those who have only read about it.

Core Concepts Questions#

“What is the difference between a Pod and a Deployment?” Testing: whether you understand the abstraction layers. A Pod is the smallest deployable unit — a container or group of containers that share a network and storage. A Deployment manages replicas of a Pod and handles rolling updates and rollback. Running bare Pods in production is almost always wrong; the interviewer wants to hear that.

“What does a ReplicaSet do, and when would you interact with it directly?” Testing: whether you understand how Deployments work under the hood. A ReplicaSet ensures a specified number of Pod replicas are running. Deployments create and manage ReplicaSets. In normal operations you rarely touch ReplicaSets directly, but knowing they exist matters for troubleshooting rollout issues.

“What is a Namespace and why would you use multiple namespaces in a cluster?” Testing: operational understanding of multi-tenancy and resource isolation. Strong answers cover environment separation (dev/staging/prod in one cluster), team-based isolation, resource quotas per namespace, and RBAC scoping to namespaces.

“What is the difference between a ConfigMap and a Secret?” Testing: basic configuration management. ConfigMaps store non-sensitive configuration data. Secrets store sensitive data — but the key insight interviewers want is that Secrets are only base64-encoded by default, not encrypted. Mentioning Sealed Secrets, external secrets operators, or Vault integration shows production experience.

“When would you use a StatefulSet instead of a Deployment?” Testing: understanding of stateful workloads. StatefulSets give pods stable network identities and persistent storage tied to a specific pod. They are used for databases, message queues, and anything where pod identity matters across restarts.

Networking Questions#

“How does a Service work in Kubernetes? What are the types?” Testing: networking fundamentals. ClusterIP (internal only), NodePort (exposes on a static port on each node), LoadBalancer (provisions a cloud load balancer), ExternalName (maps to an external DNS name). Interviewers want to know when you’d use each and their limitations.

“What is an Ingress and how does it differ from a Service?” Testing: HTTP routing knowledge. An Ingress is an API object that manages external HTTP/HTTPS access to services. It requires an Ingress controller (nginx, Traefik, etc.) to function. The difference from a LoadBalancer Service: Ingress does layer-7 routing (path-based, host-based), while LoadBalancer works at layer 4.

“What is a CNI plugin and why does it matter which one you use?” Testing: cluster networking depth. The Container Network Interface defines how containers connect to networks. Different CNI plugins (Calico, Cilium, Flannel, Weave) have different capabilities — network policies are only enforceable if the CNI supports them. Cilium has become popular for its eBPF-based observability. A senior candidate should know this.

“What is a NetworkPolicy and how do you use one?” Testing: security thinking. NetworkPolicies control traffic flow between pods. They are namespace-scoped. By default, all pods can communicate with each other — NetworkPolicies allow you to restrict this. Many candidates have used Kubernetes without ever writing a NetworkPolicy, which is a gap worth addressing before interviews.

“How does DNS work inside a Kubernetes cluster?” Testing: troubleshooting readiness. Kubernetes runs CoreDNS (formerly kube-dns) to provide service discovery. Services get DNS names in the format service-name.namespace.svc.cluster.local. Understanding this is essential for debugging connectivity issues.

Storage Questions#

“What is a PersistentVolume and a PersistentVolumeClaim?” Testing: stateful storage understanding. A PersistentVolume (PV) is a piece of storage provisioned in the cluster. A PersistentVolumeClaim (PVC) is a request for storage by a pod. The separation of concerns allows administrators to provision storage independently of how applications consume it.

“What is a StorageClass and when would you create a custom one?” Testing: dynamic provisioning knowledge. StorageClasses enable dynamic volume provisioning — when a PVC is created, the appropriate storage is automatically provisioned. You’d create a custom StorageClass to control the disk type (SSD vs HDD), replication, or region in a cloud environment.

“What access modes does a PVC support and why does it matter?” Testing: understanding of volume behaviour. ReadWriteOnce (one node), ReadOnlyMany (multiple nodes, read-only), ReadWriteMany (multiple nodes, read-write). Many storage backends only support ReadWriteOnce, which breaks assumptions when you scale a stateful deployment to multiple nodes.

Security Questions#

“What is RBAC in Kubernetes and how does it work?” Testing: security fundamentals. Role-Based Access Control controls what users and service accounts can do in a cluster. Roles define permissions within a namespace; ClusterRoles apply cluster-wide. RoleBindings attach roles to subjects. The interviewer wants you to know the difference between a Role and a ClusterRole, and be able to reason about least-privilege design.

“What is a ServiceAccount and when would a Pod need one?” Testing: pod identity and access patterns. Every pod runs with a ServiceAccount (default if not specified). Service accounts authenticate pods to the Kubernetes API and, via tools like IAM Roles for Service Accounts (IRSA on EKS) or Workload Identity (GKE), to cloud provider APIs. Strong candidates explain that pods should not use the default service account with excessive permissions.

“How would you prevent a pod from running as root?” Testing: pod security knowledge. SecurityContext settings on a pod or container can enforce runAsNonRoot: true, set a specific runAsUser, and drop Linux capabilities. At the cluster level, PodSecurity admission (the replacement for PodSecurityPolicies) can enforce these standards across namespaces.

Troubleshooting Questions#

“A pod is in CrashLoopBackOff. What does that mean and how do you investigate it?” Testing: fundamental debugging skill. CrashLoopBackOff means the container keeps crashing and Kubernetes is applying an exponential backoff between restart attempts. Investigation steps: kubectl describe pod to see recent events, kubectl logs --previous to see logs from the last crash, check the exit code. Common causes: application error at startup, bad environment variable, missing ConfigMap or Secret, incorrect command in the container spec.

“What is ImagePullBackOff and how do you fix it?” Testing: image management knowledge. The kubelet cannot pull the container image. Causes: image name typo, image does not exist, wrong tag, private registry without credentials. Fix: verify the image exists, check that an imagePullSecret is configured, ensure the service account has access to the pull secret.

“A pod is in Pending state. Why and how do you find out?” Testing: scheduler and resource knowledge. Pending means the scheduler has not placed the pod on a node. Causes: insufficient CPU or memory on available nodes, node selector or affinity rules that cannot be satisfied, taints on all nodes with no matching tolerations, persistent volume claim that cannot be bound. kubectl describe pod shows the scheduler’s reason.

“What does OOMKilled mean and how do you address it?” Testing: resource limits knowledge. OOMKilled means the container’s process exceeded its memory limit and the kernel killed it. Address it by either increasing the memory limit or investigating the memory leak in the application. Interviewers want to hear about the distinction between resource requests (scheduling hints) and limits (enforced caps).

Production Operations Questions#

“How do you perform a rolling update in Kubernetes and how do you roll back if something goes wrong?” Testing: deployment operations. Updating the image tag in a Deployment triggers a rolling update by default. kubectl rollout status monitors progress. kubectl rollout undo rolls back to the previous ReplicaSet. Mentioning maxSurge and maxUnavailable strategy settings shows depth.

“What are resource requests and limits and why do they matter for scheduling?” Testing: resource management understanding. Requests tell the scheduler how much CPU/memory the container needs (used for placement decisions). Limits cap what the container can use. Setting requests without limits risks noisy-neighbour problems. Not setting requests means the scheduler schedules blindly, which causes node pressure.

“How do liveness and readiness probes work and why would you use both?” Testing: health check design. A liveness probe tells Kubernetes whether the container should be restarted. A readiness probe tells Kubernetes whether the pod should receive traffic. They serve different purposes: a pod might be alive but not yet ready (still warming up), or alive but temporarily unable to serve requests (circuit breaker open). Both should be configured for production workloads.

“How does the Horizontal Pod Autoscaler work?” Testing: scaling knowledge. HPA scales pod replicas based on metrics, most commonly CPU utilisation. It queries the metrics API at regular intervals. Advanced HPA can scale on custom metrics or external metrics. Worth mentioning that HPA and resource requests interact — HPA uses the request as the denominator for utilisation calculations.

Scenario Question: Debugging a CrashLoopBackOff Deployment#

An interviewer might frame it like this: “A deployment you pushed 20 minutes ago is failing. Pods are in CrashLoopBackOff. Walk me through what you do.”

A strong answer follows this sequence:

Step 1 — Get the state. Run kubectl get pods -n <namespace> to confirm the issue. Check how many restarts have occurred and how recently.

Step 2 — Describe the pod. kubectl describe pod <pod-name> shows events, including why the container exited. Look at the exit code — code 1 is a general error, code 137 is OOMKilled, code 143 is SIGTERM.

Step 3 — Check logs from the crashed container. kubectl logs <pod-name> --previous retrieves logs from the last failed container instance. This often reveals the application error directly.

Step 4 — Check the deployment config. Was an environment variable, Secret, or ConfigMap changed? Does the image actually exist? Does the command in the container spec match what the image expects?

Step 5 — Check events. kubectl get events --sort-by=.metadata.creationTimestamp shows cluster-level events that might explain the problem.

Step 6 — Rollback if needed. If the cause is clear and it was caused by the recent deployment: kubectl rollout undo deployment/<name>. Then fix forward.

The interviewer is watching for structured thinking, not just command knowledge.

What Candidates Get Wrong#

Confusing Docker and Kubernetes. Kubernetes orchestrates containers — it does not build them. Explaining that you “deploy Docker” in Kubernetes misses how the components relate. The container runtime (containerd, CRI-O) runs the containers. Docker is one way to build images, not a thing Kubernetes manages.

Not knowing how the scheduler works. Many engineers use Kubernetes without understanding that pods are scheduled based on resource requests, not limits. This leads to misunderstanding why pods land on specific nodes or why a pod cannot be scheduled.

Vague answers about networking. “Services expose pods” is not enough at mid-level. Be specific about ClusterIP, DNS resolution, how kube-proxy handles routing.

Treating RBAC as an afterthought. Security questions about Kubernetes often focus on RBAC. Candidates who have only used cluster-admin permissions in dev environments struggle to reason about least-privilege design.

Do You Need a CKA to Pass Kubernetes Interviews?#

No. The CKA (Certified Kubernetes Administrator) is respected and signals hands-on skill, but it is not a hiring requirement at most companies.

What matters more is being able to answer questions like those above clearly, and demonstrating that you have debugged real problems in a real environment. A candidate who can walk through a CrashLoopBackOff investigation confidently — even without a certification — is a stronger interview candidate than someone who passed the CKA by memorising commands.

That said, if you are actively preparing for Kubernetes interviews, studying for the CKA is an effective way to fill gaps because the exam is practical, not multiple-choice.