Kubernetes Interview Questions 2026: Top 20 Scenario-Based Q&A

Kubernetes has become the de facto standard for container orchestration, and almost every DevOps, SRE, and cloud engineering interview in 2026 includes Kubernetes questions. Through my mentoring at GetJobWithAbu, I have noticed that interviewers have moved beyond basic "What is a Pod?" questions to complex, scenario-based problems. This guide covers the 20 most commonly asked scenario-based Kubernetes questions with detailed answers.

How to Use This Guide

Each question is structured as a real-world scenario — the same way interviewers ask them. The answers include both the conceptual explanation and the practical commands or configurations you would use. I recommend reading through all 20, then practicing the ones where you feel less confident.

Architecture and Core Concepts

Q1: Your team wants to deploy a microservices application on Kubernetes. Explain how you would design the deployment architecture.

Answer: I would design the architecture using these Kubernetes objects:

Deployments for each microservice — this handles scaling, rolling updates, and self-healing. Each service gets its own Deployment with a defined replica count, resource requests and limits, and health checks (liveness and readiness probes).

Services to expose each microservice internally using ClusterIP type. For the frontend service that needs external access, I would use a LoadBalancer type or an Ingress controller.

ConfigMaps for non-sensitive configuration (database hostnames, feature flags) and Secrets for sensitive data (API keys, database passwords).

Namespaces to separate environments (dev, staging, prod) or teams within the same cluster.

Ingress with an Ingress Controller (like nginx-ingress or Traefik) for HTTP routing, SSL termination, and path-based routing to different services.

Horizontal Pod Autoscaler (HPA) on critical services to scale based on CPU or custom metrics.

Q2: A developer reports that their pod keeps restarting. How would you troubleshoot this?

Answer: I would follow a systematic approach:

1. Check pod status: kubectl get pod <pod-name> -n <namespace> — Look at the RESTARTS count and STATUS (CrashLoopBackOff, OOMKilled, Error).

1. Check pod events: kubectl describe pod <pod-name> — The Events section at the bottom shows why the pod is restarting. Common causes: image pull failures, crash loop due to application error, OOMKilled due to memory limits, failed liveness probes.

1. Check container logs: kubectl logs <pod-name> --previous — The --previous flag shows logs from the last crashed container. Look for application errors, missing environment variables, or dependency connection failures.

1. Check resource limits: If the pod shows OOMKilled, the container is exceeding its memory limit. Either optimize the application or increase the memory limit in the deployment spec.

1. Check liveness probe: A misconfigured liveness probe (checking the wrong endpoint, too-short timeout) can cause Kubernetes to kill healthy containers. Review the probe configuration in the deployment YAML.

Q3: Explain the difference between a Deployment, StatefulSet, and DaemonSet. When would you use each?

Answer:

Deployment: Use for stateless applications (web servers, API services, microservices). Pods are interchangeable — any pod can handle any request. Supports rolling updates and rollbacks. This is the most common workload type.

StatefulSet: Use for stateful applications that need stable network identities, persistent storage, and ordered deployment. Examples: databases (MySQL, PostgreSQL), message queues (Kafka, RabbitMQ), distributed caches (Redis Cluster). Each pod gets a persistent volume claim that survives pod restarts and a stable hostname (pod-0, pod-1, pod-2).

DaemonSet: Use when you need exactly one pod running on every node (or a subset of nodes). Examples: log collectors (Fluentd, Filebeat), monitoring agents (Dynatrace OneAgent, Datadog Agent), network plugins, and storage drivers. When a new node joins the cluster, the DaemonSet automatically schedules a pod on it.

Q4: A pod cannot connect to another service in a different namespace. What could be wrong?

Answer: Cross-namespace service communication requires using the fully qualified service name: <service-name>.<namespace>.svc.cluster.local.

If the pod is using just the service name without the namespace, DNS resolution will fail because it only searches the pod's own namespace by default.

Troubleshooting steps:

1. Verify the target service exists: kubectl get svc -n <target-namespace>
2. Test DNS resolution from the pod: kubectl exec -it <pod> -- nslookup <service>.<namespace>.svc.cluster.local
3. Check if there are NetworkPolicies blocking cross-namespace traffic
4. Verify the target service's selector matches the target pods' labels

Networking and Services

Q5: How does a Kubernetes Service route traffic to pods? What happens when a pod becomes unhealthy?

Answer: A Service uses label selectors to identify its target pods. The kube-proxy component (running on every node) maintains network rules that distribute traffic across all healthy pods matching the selector.

When a pod fails its readiness probe, it is removed from the Service's Endpoints list. The kube-proxy updates its rules, and new requests are no longer routed to that pod. The pod is not deleted — it remains running but does not receive traffic until it passes the readiness probe again.

This is why readiness probes are essential for production deployments — without them, traffic could be routed to pods that are still initializing or have become unhealthy.

Q6: Explain the difference between ClusterIP, NodePort, LoadBalancer, and Ingress.

Answer:

ClusterIP (default): Exposes the service on an internal cluster IP. Only accessible from within the cluster. Use for inter-service communication.

NodePort: Exposes the service on each node's IP at a static port (30000-32767). Accessible from outside the cluster via <NodeIP>:<NodePort>. Rarely used in production but useful for development.

LoadBalancer: Creates an external load balancer (cloud provider dependent — works on AWS, GCP, Azure). Gives you a single external IP to access the service. Each LoadBalancer service provisions a new cloud load balancer, which can get expensive.

Ingress: Not a service type but a separate resource that acts as an HTTP/HTTPS reverse proxy. Uses an Ingress Controller (nginx, Traefik, HAProxy) and allows path-based and host-based routing, SSL termination, and more. Most cost-effective for exposing multiple HTTP services externally.

In production, I typically use: ClusterIP for all internal services + Ingress with an nginx Ingress Controller for external HTTP access + LoadBalancer only for non-HTTP services (like databases that need external access).

Q7: A pod needs to communicate with an external database outside the cluster. How do you configure this?

Answer: There are several approaches:

1. ExternalName Service: Create a Service of type ExternalName that maps to the external database hostname. Pods can then use the Service name for DNS resolution.

1. Service without selector + Endpoints: Create a Service without a selector and manually define an Endpoints resource pointing to the external database IP and port.

1. Direct connection: Simply configure the pod with the external database hostname/IP via ConfigMap or Secret. This is the simplest approach and works well when you do not need the abstraction layer of a Service.

Best practice: Use Kubernetes Secrets for database credentials, and ConfigMaps for the connection parameters (host, port, database name).

Storage and Configuration

Q8: Your application needs persistent storage that survives pod restarts. How do you set this up?

Answer: I would use PersistentVolumes (PV) and PersistentVolumeClaims (PVC):

1. StorageClass defines the type of storage (SSD, HDD, cloud-specific like gp3 on AWS or Standard on GCP) and the provisioner.

1. PersistentVolumeClaim is created in the deployment spec, requesting a specific amount of storage and access mode (ReadWriteOnce, ReadWriteMany).

1. Dynamic provisioning (preferred): The StorageClass automatically creates the PersistentVolume when a PVC is created. No manual PV creation needed.

1. Mount the PVC as a volume in the pod spec using volumeMounts.

For stateful applications like databases, use a StatefulSet instead of a Deployment — it guarantees each pod gets its own dedicated PVC that persists across restarts.

Q9: How do you manage application secrets in Kubernetes securely?

Answer: Kubernetes Secrets are base64-encoded (not encrypted) by default. For production:

1. Enable encryption at rest: Configure the API server with an EncryptionConfiguration to encrypt Secrets in etcd using AES-256 or a KMS provider (AWS KMS, Azure Key Vault, GCP KMS).

1. External secret management: Use tools like External Secrets Operator to sync secrets from AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault into Kubernetes Secrets automatically.

1. RBAC: Restrict Secret access using Role and RoleBinding — only pods and service accounts that need secrets should have read access.

1. Avoid environment variables for sensitive data in production — mount Secrets as files instead, as environment variables can leak through process listings and crash dumps.

Scaling and Performance

Q10: Your application is experiencing high traffic. How do you set up auto-scaling in Kubernetes?

Answer: Kubernetes offers three levels of auto-scaling:

Horizontal Pod Autoscaler (HPA): Automatically adjusts the number of pod replicas based on CPU utilization, memory usage, or custom metrics. Example: scale from 3 to 10 pods when CPU exceeds 70%.

Vertical Pod Autoscaler (VPA): Adjusts the CPU and memory requests/limits for existing pods based on historical usage. Useful when you are not sure how much resource a pod needs.

Cluster Autoscaler: Automatically adds or removes nodes based on pod scheduling demand. If pods are Pending because no node has enough resources, the Cluster Autoscaler provisions new nodes.

For production, I typically use HPA + Cluster Autoscaler together. HPA handles application-level scaling, and Cluster Autoscaler handles infrastructure-level scaling.

Troubleshooting

Q11: A deployment rollout is stuck. Pods are not becoming ready. How do you diagnose and fix this?

Answer:

1. Check rollout status: kubectl rollout status deployment/<name>
2. Check new pods: kubectl get pods -l app=<name> — are they in Pending, CrashLoopBackOff, or ImagePullBackOff?
3. If ImagePullBackOff: Wrong image name, tag, or missing imagePullSecret for private registries
4. If CrashLoopBackOff: Application is crashing — check logs with kubectl logs <pod> --previous
5. If Pending: Node resources exhausted — check kubectl describe pod for scheduling failures
6. Rollback immediately if production is affected: kubectl rollout undo deployment/<name>
7. After rollback, fix the issue in the deployment YAML and redeploy

Q12: How do you perform a zero-downtime deployment in Kubernetes?

Answer: Kubernetes Deployments support rolling updates by default, but zero-downtime requires additional configuration:

1. Rolling update strategy: Set maxUnavailable to 0 and maxSurge to 25-50%. This ensures old pods are only terminated after new pods are ready.
2. Readiness probes: Must be configured correctly — new pods should only receive traffic after they are fully initialized.
3. Graceful shutdown: Configure preStop hooks and proper SIGTERM handling in your application. Set terminationGracePeriodSeconds appropriately (default 30 seconds).
4. PodDisruptionBudget (PDB): Ensure a minimum number of pods remain available during voluntary disruptions.

Q13-Q20 (Summary)

The remaining questions cover topics including RBAC and security policies, resource quotas and limit ranges, monitoring Kubernetes with Prometheus and Grafana, Helm chart management, multi-cluster strategies, backup and disaster recovery, network policies, and debugging DNS issues within Kubernetes clusters.

Interview Preparation Tips

Based on my experience coaching DevOps candidates at GetJobWithAbu:

1. Set up a practice cluster: Use Minikube, Kind, or a free-tier cloud Kubernetes service (EKS, GKE, AKS) to practice these scenarios hands-on.

1. Know kubectl fluently: Interviewers expect you to describe exact commands. Practice common kubectl operations daily.

1. Understand the why, not just the how: Interviewers will ask "Why would you use X over Y?" Be ready to justify your design decisions.

1. Practice architecture design: Many interviews include a whiteboard exercise where you design a Kubernetes-based deployment from scratch. Practice drawing architecture diagrams.

1. Prepare failure scenarios: "What happens if X fails?" is a very common interview pattern. Think through failure modes for each Kubernetes component.

For more detailed interview preparation covering DevOps, monitoring, Linux, and other topics, explore our complete Interview Preparation Hub on GetJobWithAbu.