Kubernetes Interview Questions: Comprehensive Guide for DevOps, SRE, and Platform Engineers

Kubernetes has become the industry standard for container orchestration, and if you’re interviewing for a role involving cloud infrastructure, deployment pipelines, or distributed systems, you’ll almost certainly face questions about it. This guide covers the essential Kubernetes interview questions that hiring managers ask across DevOps Engineer, Site Reliability Engineer, Platform Engineer, and Backend Developer roles.

Kubernetes interviews are designed to assess your understanding of how containers are deployed, managed, and scaled in production. The questions progress from foundational concepts through architecture, networking, storage, security, and troubleshooting. By the end of this guide, you’ll have concrete, detailed answers that demonstrate both theoretical knowledge and practical experience.

Before diving into specific questions, it helps to understand what interviewers are evaluating. They want to know if you can design reliable systems, troubleshoot production issues, and make architectural decisions that balance complexity with maintainability. They’re also checking whether you’ve actually worked with Kubernetes or just read about it in theory.

Core Kubernetes Concepts Questions

1. What is a Pod, and why does Kubernetes use Pods instead of running containers directly?

Interviewers ask this to verify you understand Kubernetes’ fundamental building block and its design rationale.

A Pod is the smallest deployable unit in Kubernetes. It’s a wrapper around one or more containers, typically Docker containers. In practice, most Pods run a single container, but the model allows multiple containers to share network and storage resources.

Pods are ephemeral. They’re created and destroyed dynamically. When a Pod crashes, Kubernetes doesn’t repair it; instead, a controller creates a new one. This is critical to understand because it means you should never rely on a Pod’s IP address or assume it will stick around.

Why Pods instead of running containers directly? Kubernetes needed a way to model tightly coupled containers that share network namespace. If you have a main application container and a logging sidecar container, both should live and die together, and they should share the same IP address and localhost network. Pods provide this abstraction. The Pod wraps the containers, and all containers in a Pod share network namespace (same IP, same ports), IPC namespace (shared memory), and optionally storage volumes.

In your answer, mention that Pods are ephemeral and stateless by design. Talk about init containers for setup tasks, sidecar containers for logging or proxies, and how Pod lifecycle hooks work. If you’ve used other orchestration platforms, contrast Pods to how other systems handle container grouping.

2. What is the difference between a Deployment, a StatefulSet, and a DaemonSet?

This question tests whether you understand controller patterns and can pick the right tool for different workload types.

A Deployment is for stateless applications. It manages a set of replicated Pods using a ReplicaSet controller. When you update a Deployment spec (like changing the image), it rolls out the change gradually using a rolling update strategy by default. Deployments handle replica scaling, self-healing, and version rollback automatically. If a Pod dies, the ReplicaSet immediately creates a new one to maintain the desired replica count.

A StatefulSet is for stateful applications like databases, message brokers, or distributed caches. StatefulSets maintain stable Pod identities and persistent storage. Each Pod gets a predictable hostname (like mysql-0, mysql-1, mysql-2) that persists across restarts. StatefulSets use headless services (ClusterIP: None) so each Pod is directly reachable by its own DNS name. Storage is typically backed by persistent volumes that are tied to specific Pods, so when mysql-0 restarts, it reconnects to the same volume.

A DaemonSet ensures that every node (or a subset of nodes) runs a single instance of a Pod. You use DaemonSets for node-level agents like Fluentd logging collectors, Prometheus node exporter, or network plugins. Unlike Deployments, DaemonSets don’t have a replica count; they automatically adjust to the cluster’s node count.

In your answer, provide concrete examples. Say “You’d use Deployment for a Node.js API server, StatefulSet for a Cassandra cluster, and DaemonSet for a monitoring agent.” Show that you understand why: Deployments are flexible and can be scheduled anywhere; StatefulSets need predictable identity and stable storage; DaemonSets need to run everywhere.

3. Explain the difference between a Service and an Ingress.

This tests your understanding of networking in Kubernetes and how traffic gets routed to Pods.

A Service is a stable network endpoint for a set of Pods. Pods get dynamically assigned IP addresses and change constantly (on restarts, scaling, failures), so applications need a stable address. A Service provides that stability through an IP address and DNS name that remain constant. Services work at layer 4 (TCP/UDP) and use selectors to determine which Pods they target.

There are three main Service types. ClusterIP is the default and only accessible within the cluster. NodePort opens a port on every node and routes traffic to the Service. LoadBalancer provisions an external load balancer (in cloud environments) and routes traffic from the internet to the Service. Headless services (ClusterIP: None) don’t get a cluster IP; instead, DNS returns the individual Pod IP addresses, typically used with StatefulSets.

An Ingress sits at layer 7 (HTTP/HTTPS) and acts as a reverse proxy. It routes HTTP requests to different Services based on hostnames or URL paths. For example, an Ingress might route requests to api.example.com to the API service and requests to www.example.com to the web service. Ingresses let you consolidate multiple Services behind a single external IP. They also handle TLS termination, virtual hosts, and request routing rules.

The key distinction: a Service abstracts a set of Pods and provides network access; an Ingress abstracts multiple Services and provides HTTP routing and SSL/TLS management. You need a Service for your Pods to be reachable. You use an Ingress to expose those Services to the internet in a controlled, HTTP-aware way.

4. What is a ConfigMap and a Secret, and when would you use each?

This question checks if you understand configuration management in Kubernetes and the difference between general config and sensitive data.

ConfigMaps store non-sensitive configuration data as key-value pairs. Examples include application settings, database hostnames, log levels, or feature flags. You can mount ConfigMaps as environment variables or as files in a volume. ConfigMaps are not encrypted by default and are visible in etcd, so never store passwords or API keys in them.

Secrets store sensitive data like passwords, API keys, OAuth tokens, and TLS certificates. Secrets are base64-encoded (not encrypted by default, but the encoding keeps casual observers from reading the data in kubectl output). There are several Secret types: Opaque (generic), kubernetes.io/dockercfg (Docker registry credentials), kubernetes.io/dockerconfigjson (Docker config.json), kubernetes.io/basic-auth, kubernetes.io/ssh-auth, kubernetes.io/tls, and bootstrap.kubernetes.io/token.

When should you use each? Use ConfigMaps for anything that isn’t sensitive and might change. Use Secrets for anything security-critical. If data should be the same across environments, ConfigMap is reasonable. If it changes per environment and includes credentials, use Secrets and consider managing them with a tool like HashiCorp Vault or sealed-secrets for better security.

In your answer, mention that both can be mounted as files or environment variables, but best practice is to use volume mounts for Secrets to avoid exposing them in logs. Also note that Kubernetes doesn’t encrypt Secrets by default; for production, you should enable encryption at rest for etcd.

5. What is a Namespace, and why would you create multiple namespaces?

This tests your understanding of logical isolation and resource management in Kubernetes.

A Namespace is a logical isolation mechanism within a cluster. It partitions cluster resources, allowing multiple teams or projects to share a cluster without interfering with each other. Every resource in Kubernetes belongs to a namespace (most commonly “default”). Resources with the same name can exist in different namespaces.

You’d create multiple namespaces for several reasons. Multi-tenancy is the primary one: if you have separate teams, you can give each team its own namespace. Resource quotas and network policies can then be applied per-namespace, preventing one team from consuming all resources or accessing another team’s data. Environment separation is another: you might have a “production” and “staging” namespace to isolate prod deployments from testing. Role-based access control (RBAC) policies are also namespace-scoped, so you can grant engineers access to “staging” but not “production.”

You reference resources in other namespaces using the fully qualified DNS name: service-name.namespace-name.svc.cluster.local. This allows controlled cross-namespace communication.

Namespaces don’t isolate network traffic by default (Pod-to-Pod traffic flows freely unless you add NetworkPolicies), and they don’t isolate compute resources unless you apply resource quotas. They’re primarily administrative boundaries, though with the right policies, they can provide real isolation.

6. What is a Persistent Volume and a Persistent Volume Claim?

This question verifies you understand how Kubernetes handles stateful storage.

A Persistent Volume (PV) is a cluster-wide storage resource, like a block of disk space on an NFS server, an AWS EBS volume, or a GCP Persistent Disk. PVs are provisioned by an administrator or a dynamic provisioner and exist independently of any Pod.

A Persistent Volume Claim (PVC) is a request for storage by a Pod. When you write a Pod spec that includes a PVC, Kubernetes matches the PVC to an available PV based on size and access mode requirements. The PVC acts as a claim on the storage, and the Pod can then mount that storage as a volume.

The separation of concerns is important. Application developers write PVCs without needing to know about the underlying storage infrastructure. Storage administrators create PVs with specific sizes and types. Kubernetes handles the binding.

You can also use StorageClasses for dynamic provisioning. Instead of manually creating PVs, you define a StorageClass (e.g., “fast-ssd” or “standard-network”) and when a PVC references that class, Kubernetes automatically provisions a new PV on the appropriate storage backend.

Access modes include ReadWriteOnce (single node read-write), ReadOnlyMany (multiple nodes read-only), and ReadWriteMany (multiple nodes read-write). Reclaim policies control what happens when a PVC is deleted: Retain keeps the data, Delete removes it, Recycle clears the data.

7. What is a Job and a CronJob?

This tests your knowledge of batch and scheduled workloads in Kubernetes.

A Job creates one or more Pods and ensures that a specified number of them successfully complete. Jobs are used for one-off or batch tasks like data processing, backups, or database migrations. A Job runs Pods to completion and doesn’t restart them if they exit successfully. You can configure parallelism (how many Pods run in parallel) and completions (how many successful Pods are required).

A CronJob is a scheduler that creates Jobs on a repeating schedule, similar to cron in Unix. You define a cron expression (e.g., “0 2 * * *” for 2 AM daily), and the CronJob controller creates a Job at that time. CronJobs are useful for maintenance tasks, periodic cleanup, or scheduled reports.

In your answer, distinguish Jobs from Deployments: Deployments are meant to run indefinitely; Jobs are meant to complete. A failed Job won’t auto-restart its Pods; instead, it creates new ones to meet the completion target.

8. What is an InitContainer, and when would you use one?

This question tests your understanding of Pod lifecycle and setup patterns.

An InitContainer is a container that runs before the main application containers in a Pod. Init containers run sequentially and must complete successfully before the main containers start. If an init container fails, the Pod fails and may be restarted depending on the restart policy.

You’d use init containers for setup tasks that must run once before the application starts. Common examples include pulling configuration from a configuration server, waiting for a database to be ready, downloading dependencies, or modifying file permissions. For instance, if your application needs a schema in PostgreSQL before it can run, you could use an init container with a SQL client to set up the schema.

Init containers see the same volumes as the main containers, so they can prepare data or configuration files. They run under the same security context. Using init containers keeps your main application image small and focused; the setup logic is separate.

9. What is a Network Policy, and how does it work?

This verifies your understanding of network security at the cluster level.

A NetworkPolicy controls ingress (incoming) and egress (outgoing) traffic to and from Pods. By default, all Pods in a Kubernetes cluster can communicate with each other. NetworkPolicies allow you to create a zero-trust model where you explicitly allow only the traffic you need.

A NetworkPolicy uses selectors (like labels) to define which Pods it applies to, and it specifies which traffic is allowed to/from those Pods. For example, you might write a policy that says “only Pods with label role=web can send traffic to Pods with label role=database on port 5432.”

NetworkPolicies are namespace-scoped, so they only affect Pods within the same namespace unless you use cross-namespace selectors. Important caveat: NetworkPolicies are only enforced if a network plugin supports them (like Calico or Cilium). The default kubenet plugin doesn’t enforce NetworkPolicies, so they have no effect until you install a proper CNI plugin.

10. What is a Helm chart, and how does it differ from raw Kubernetes manifests?

This tests whether you understand templating and package management for Kubernetes.

A Helm chart is a templated package of Kubernetes manifests. Instead of writing static YAML files, you write a chart with variables (values) that can be customized at install time. Helm then renders the final YAML and applies it to the cluster.

The main advantages over raw manifests are reusability (you can install the same chart multiple times with different values), package management (you can version charts and manage dependencies), and simplicity (you avoid duplicating manifests across environments). A chart includes a values.yaml file with default values, templates for your Kubernetes resources, and metadata about the chart.

You install a chart with `helm install release-name chart-name –values custom-values.yaml`, and the chart can be parameterized so different teams or environments use different configurations without modifying the chart itself. Helm also handles upgrades with rollback capabilities.

11. What is a Resource Request and a Resource Limit?

This verifies your understanding of resource management and cluster capacity planning.

A Resource Request is what you tell Kubernetes your container needs to run. You specify CPU and memory requests for each container. The scheduler uses requests to decide which node can accommodate the Pod. If a node doesn’t have enough requested resources available, the Pod won’t be scheduled there.

A Resource Limit is the maximum amount of CPU and memory a container can use. If a container exceeds the memory limit, it’s killed (OOMKilled). If it exceeds the CPU limit, it’s throttled (prevented from using more CPU). Limits protect the cluster from any single container monopolizing resources.

Requests are used for scheduling and fairness; limits are used for isolation. Both are important. If you set requests too low, the scheduler might overcommit the node. If you set limits too low, your application might be throttled and perform poorly. You should request what your application actually needs under normal load and limit it to something slightly higher to allow for spikes without killing the container.

12. What is a Health Check (liveness and readiness probes), and why do you need them?

This tests your understanding of availability and self-healing in Kubernetes.

A Liveness Probe checks whether a Pod should be restarted. If the liveness probe fails, Kubernetes assumes the container is dead and restarts it. You use liveness probes for applications that can hang or deadlock. For example, if your Java application gets stuck, a liveness probe might fail, triggering a restart.

A Readiness Probe checks whether a Pod is ready to receive traffic. If the readiness probe fails, the Pod is removed from the Service’s load balancer, but it’s not restarted. You use readiness probes during startup (when your application is still initializing) or during rolling updates (so traffic doesn’t go to partially initialized Pods).

You can define probes as HTTP requests (GET to a /health endpoint), TCP socket checks (can we connect to port X?), or exec probes (run a command and check the exit code). Each probe has initial delay, timeout, period, and failure threshold settings.

Without probes, if a container is running but the application inside has crashed, Kubernetes has no way to detect it. With probes, Kubernetes can automatically detect unhealthy Pods and take corrective action.

Kubernetes Architecture Questions

1. Describe the Kubernetes control plane and its components.

Interviewers ask this to confirm you understand how Kubernetes itself operates and manages the cluster.

The control plane is the brain of the cluster. It runs several key components that make decisions about the cluster. The API Server (kube-apiserver) is the central hub. All communication goes through the API Server. It validates requests, stores data, and serves the API that kubectl and other clients use.

etcd is the backing data store. It’s a distributed key-value database that stores all cluster data, configuration, and state. The API Server reads from and writes to etcd. etcd must be highly available and backed up regularly because losing it means losing the cluster state.

The Scheduler (kube-scheduler) watches for newly created Pods with no assigned node and selects a node for them. The scheduler considers resource requests, node affinity rules, pod affinity rules, and taints and tolerations when making decisions.

The Controller Manager (kube-controller-manager) runs multiple controllers that reconcile the desired state with the actual state. The Deployment controller manages ReplicaSets. The Node controller monitors nodes and marks them as NotReady if they become unhealthy. The Service controller manages Services and LoadBalancers. The StatefulSet controller manages StatefulSets. And many others.

cloud-controller-manager runs cloud-specific controllers like the LoadBalancer controller that provisions load balancers in cloud environments.

The control plane is typically not accessible directly; it runs on dedicated control plane nodes. In a production cluster, you usually have multiple control plane nodes for high availability. All control plane components are typically run as static Pods on each control plane node, or they run outside the cluster entirely (like in a managed Kubernetes service).

2. What is the kubelet, and what does it do?

This tests your understanding of node-level operations.

The kubelet is an agent that runs on every node. It’s responsible for ensuring that Pods are running and healthy on that node. The kubelet watches the API Server for Pods assigned to its node and manages their lifecycle (starting, stopping, restarting containers). It also reports the node’s status and resource availability back to the API Server.

The kubelet runs the container runtime (Docker, containerd, or others) to actually create and manage containers. It mounts volumes, pulls images, and manages container lifecycle hooks.

The kubelet also runs kubelet plugins like device plugins for GPUs or other specialized hardware. It executes probes (liveness and readiness), and it handles Pod eviction when the node runs low on resources.

If a kubelet crashes or becomes unavailable, the node becomes NotReady, and the control plane (specifically the node controller) will eventually evict Pods from that node and reschedule them elsewhere (depending on the Pod’s disruption budget and termination grace period).

3. Explain kube-proxy and how it implements services.

This tests your understanding of networking at the node level.

kube-proxy is a network proxy that runs on every node. When you create a Service, the kube-proxy on each node reads that Service definition and sets up rules (typically iptables rules on Linux) to forward traffic destined for the Service’s IP to the appropriate Pod IPs.

For a ClusterIP Service, kube-proxy creates iptables rules that DNAT (destination NAT) packets destined for the Service IP to a randomly selected Pod IP. For a NodePort Service, it creates rules that forward traffic to the NodePort to the Pods. For a LoadBalancer Service, it works with the cloud provider to set up external load balancing.

The traditional mode uses iptables, which has performance limitations at very large scales (because iptables rule lookup is linear). Newer versions of Kubernetes support IPVS mode (Linux IP Virtual Server), which is more efficient.

Service discovery in Kubernetes is handled by DNS. CoreDNS (or kube-dns in older clusters) runs in the cluster and provides a DNS server. When a Pod tries to connect to a Service name, DNS resolves it to the Service’s IP, and kube-proxy handles the actual forwarding.

4. What is the difference between a control plane node and a worker node?

This tests your understanding of cluster topology and node roles.

A control plane node runs control plane components (API Server, etcd, scheduler, controllers). It makes decisions about the cluster and manages state. By default, control plane nodes don’t run application Pods (user workloads); they have a taint that prevents scheduling unless a Pod explicitly tolerates it.

A worker node runs application Pods. Worker nodes run the kubelet and kube-proxy to manage Pods and networking. They don’t run control plane components.

In a single-node cluster (like minikube), one node serves both roles. In production, you typically have multiple control plane nodes (for high availability) and many worker nodes (to handle application load). Control plane nodes should be sized for low traffic and high availability rather than high throughput, since they’re not running user workloads.

5. What is a taint and a toleration?

This tests your understanding of advanced scheduling features.

A Taint is a property of a node that repels Pods unless the Pod explicitly tolerates the taint. For example, you might taint a GPU node with key=gpu, effect=NoSchedule, so only Pods that need GPUs can run on it. There are three taint effects: NoSchedule (prevent scheduling), PreferNoSchedule (prefer not to schedule unless necessary), and NoExecute (don’t allow existing Pods, evict them).

A Toleration is a property of a Pod that allows it to run on a node with a matching taint. A Pod must explicitly declare tolerations for each taint the node has.

Common use cases include dedicated nodes for specific workloads (like GPU nodes), node maintenance (taint a node, so Pods are evicted and can be rescheduled before you reboot), and multi-tenancy (dedicated nodes for specific teams or customers).

6. What is Pod affinity and node affinity?

This tests your understanding of placement constraints.

Node affinity allows you to constrain a Pod to specific nodes based on node labels. RequiredDuringScheduling affinity is a hard constraint: the scheduler won’t place the Pod on a node unless the affinity rules match. PreferredDuringScheduling is a soft constraint: the scheduler tries to satisfy it but will place the Pod elsewhere if necessary.

Pod affinity allows you to constrain a Pod based on the presence of other Pods. For example, you might want a front-end Pod to run on the same node as a cache Pod to reduce latency. Pod anti-affinity is the opposite: it spreads Pods across nodes for redundancy. For example, you might want multiple replicas of a database to run on different nodes so a node failure doesn’t take down all replicas.

Affinity rules use topology keys to define the scope. With topology key node.kubernetes.io/hostname, affinity is at the node level. With topology key zone, affinity is at the availability zone level (across zones).

7. How does the scheduler make scheduling decisions?

This tests your understanding of the scheduling algorithm.

The scheduler filters nodes to find those that could accommodate the Pod (filtering phase), then ranks the remaining nodes and picks the best one (scoring phase).

During filtering, the scheduler checks resource requests (does the node have enough available CPU and memory?), node selectors, node affinity, taints and tolerations, and other constraints. Nodes that fail any check are eliminated.

During scoring, the scheduler applies scoring plugins to rank the remaining nodes. Plugins consider factors like resource utilization (preferring balanced clusters), image locality (preferring nodes that already have the image), and affinity preferences. Plugins return scores, and the scheduler picks the node with the highest score.

If multiple nodes have the same score, the scheduler picks one arbitrarily. If no nodes pass filtering, the Pod remains unscheduled and is retried periodically.

8. What is a Priority and Preemption in Kubernetes scheduling?

This tests your understanding of workload prioritization.

Pods can have a priority (PriorityClassName) that affects scheduling. High-priority Pods are scheduled before low-priority ones. If the cluster is full and a high-priority Pod needs resources, the scheduler can evict lower-priority Pods to make room (preemption).

This is useful for ensuring critical workloads (like payment processing) always have resources, even if it means evicting non-critical ones (like batch jobs). You define PriorityClass resources with numeric values; higher values mean higher priority. The system-cluster-critical and system-node-critical PriorityClasses are reserved for Kubernetes system components.

Networking and Service Questions

1. Explain different Service types: ClusterIP, NodePort, and LoadBalancer.

Interviewers ask this to confirm you understand how traffic gets routed to Pods.

ClusterIP is the default Service type. It creates a stable IP address within the cluster that’s only reachable from inside the cluster. The Service has a DNS name (service-name.namespace.svc.cluster.local) and an IP, and traffic to that IP is load-balanced across the backing Pods. You’d use ClusterIP for internal service-to-service communication, like a web service talking to a database service.

NodePort opens a port on every node (between 30000 and 32767 by default). Traffic to that port on any node is forwarded to the Service and then to the backing Pods. NodePort is useful for development and testing, but it’s not recommended for production because you have to manage node IPs and the high-numbered ports are awkward.

LoadBalancer automatically provisions an external load balancer (in cloud environments like AWS, GCP, or Azure) and allocates an external IP. Traffic to the external IP is routed to the Service. LoadBalancer is the standard way to expose services to the internet in cloud environments. Under the hood, a LoadBalancer Service creates a NodePort Service and then provisions a load balancer to route to that NodePort.

ExternalName is a fourth type that creates a CNAME pointing to an external hostname, useful for integrating with external services without going through a load balancer.

2. How does Kubernetes DNS work?

This tests your understanding of service discovery.

CoreDNS (or kube-dns in older clusters) runs in the cluster and provides DNS services. Every Pod gets a kubelet-provided /etc/resolv.conf that points to the cluster DNS. When a Pod tries to resolve a name, it queries CoreDNS.

CoreDNS has a plugin that watches the API Server for Services and creates DNS records for them. A Service my-service in namespace default is accessible as my-service.default.svc.cluster.local (and shorter forms like my-service.default or just my-service from within the same namespace). The DNS name resolves to the Service’s ClusterIP.

For headless Services (ClusterIP: None), DNS returns the individual Pod IPs instead of a Service IP. This is used with StatefulSets so each Pod has its own DNS name.

CoreDNS also handles SRV records for Services, allowing clients to discover which Pods back a Service and potentially their ports, useful for clients that need to connect directly to specific Pods.

3. What is a CNI (Container Network Interface) plugin, and how does it work?

This tests your understanding of network infrastructure.

A CNI plugin is software that handles pod-to-pod networking. When a Pod is created, the kubelet calls the CNI plugin to set up networking for the Pod. The CNI plugin creates a virtual Ethernet interface, assigns an IP address from a pool, and sets up routing so the Pod can communicate with other Pods.

Different CNI plugins use different approaches. Flannel uses an overlay network (a virtual network on top of the physical network). Calico uses BGP to route traffic directly without overlay encapsulation and provides NetworkPolicy enforcement. Cilium uses eBPF for advanced networking and security. WeaveNet creates a mesh network.

The choice of CNI plugin affects performance (overlay networks add overhead), security features (not all plugins enforce NetworkPolicies), and operational complexity. Most clusters use a single CNI plugin; you specify it when you initialize the cluster.

4. How would you debug a Pod that can’t reach another Pod?

This tests your troubleshooting skills with a real scenario.

First, verify that both Pods are running and in the same cluster. Check with `kubectl get pods`. If either Pod isn’t running, investigate why.

Check the logs of both Pods using `kubectl logs pod-name`. The issuing Pod might show connection errors; the receiving Pod might show nothing if traffic isn’t reaching it at all.

Try to reach the receiving Pod from inside the issuing Pod using `kubectl exec -it pod-name — /bin/sh` and then trying to curl or wget the receiving Pod’s IP. You can get the Pod IP from `kubectl describe pod receiving-pod-name`. If the direct IP works but the Service name doesn’t, DNS is the problem. Try `nslookup service-name` from inside a Pod to check DNS resolution.

If direct IP communication fails, check NetworkPolicies. Run `kubectl get networkpolicies –all-namespaces` and inspect any policies that might be blocking the traffic. Check the CNI plugin logs on the nodes to see if there are network errors.

Verify that neither Pod is behind a firewall or security group on the underlying infrastructure. In a cloud environment, check security groups and network ACLs.

5. What is an Ingress, and how would you configure one?

This tests your understanding of HTTP routing and external exposure.

An Ingress is a Kubernetes resource that defines HTTP and HTTPS routing rules to Services. Instead of exposing each Service individually, you define one Ingress that routes HTTP traffic based on hostnames and paths to different Services.

An Ingress spec includes rules that match based on hostname and path and forward to a backend Service. For example, you might specify that requests to api.example.com/v1/* go to the api-service, requests to www.example.com/* go to the web-service, and requests to admin.example.com/* go to the admin-service. All three Services are exposed through a single Ingress.

An Ingress requires an Ingress Controller to actually implement the routing. Nginx Ingress Controller is the most common; it runs as a Deployment in the cluster and watches Ingress resources. When an Ingress is created, the controller generates an Nginx configuration file and reloads Nginx. Other controllers exist for cloud providers (like the AWS ALB Ingress Controller or GCP Ingress Controller).

Ingress also handles TLS/SSL termination. You can specify a TLS section with a certificate and key stored in a Secret, and the Ingress controller will serve HTTPS to clients.

Ingresses are powerful for consolidating multiple services behind a single entry point and managing HTTP-level routing in a declarative way.

6. What is a Headless Service, and when would you use one?

This tests your understanding of DNS and StatefulSet patterns.

A Headless Service (ClusterIP: None) doesn’t allocate a ClusterIP. Instead, DNS returns the IP addresses of the backing Pods directly. This allows clients to discover individual Pod IPs and connect directly to specific Pods.

You’d use a headless service with StatefulSets so each Pod has a stable DNS name. For example, a MySQL StatefulSet might have a headless service so clients can connect to mysql-0.mysql.default.svc.cluster.local directly. This is important because each Pod in a StatefulSet has a different role; you can’t just load-balance traffic across them as you would with a regular Service.

Headless services are also used for distributed systems like Cassandra or Kafka where clients need direct access to all nodes, not load-balanced access.

Storage and Stateful Application Questions

1. Explain the relationship between PersistentVolume, PersistentVolumeClaim, and StorageClass.

Interviewers ask this to verify you understand Kubernetes storage architecture.

A PersistentVolume (PV) is an abstract representation of physical storage. It’s provisioned by an administrator (static provisioning) or automatically by a StorageClass (dynamic provisioning). A PV has a size, access modes, and a reclaim policy.

A PersistentVolumeClaim (PVC) is a request for storage by a Pod. When a Pod requests a PVC, Kubernetes finds a PV that matches the requested size and access modes and binds the PVC to the PV. The PVC then acts as a reference that the Pod can mount as a volume.

A StorageClass describes a type of storage and the provisioner that creates PVs for that class. For example, a “fast-ssd” StorageClass might use an AWS EBS provisioner with gp3 volumes and specific IOPS settings. When a PVC references a StorageClass, the provisioner automatically creates a PV with the appropriate characteristics.

The pattern is: StorageClass defines the storage type, PVC requests storage (either matching a StorageClass for dynamic provisioning or finding a manually created PV), and the Pod mounts the PVC as a volume. This separation of concerns allows developers to request storage without knowing about underlying infrastructure.

2. What are access modes for Persistent Volumes?

This tests your understanding of storage constraints.

Access modes define how a PV can be mounted. ReadWriteOnce (RWO) allows a PV to be mounted by a single node for reading and writing. ReadOnlyMany (ROMany) allows a PV to be mounted by multiple nodes in read-only mode. ReadWriteMany (RWMany) allows a PV to be mounted by multiple nodes for reading and writing.

Different storage backends support different access modes. Block storage like EBS typically supports only RWO. Network filesystems like NFS support RWX. Some cloud block storage like Azure Files support RWX as well.

When you create a PVC, you specify the access modes you need. If no PV matches the access mode, the PVC remains unbound and the Pod fails to start.

3. What is a StatefulSet, and how does it maintain stable identity for Pods?

This tests your understanding of stateful applications in Kubernetes.

A StatefulSet maintains stable Pod identities. Each Pod gets a predictable hostname that persists across restarts: mysql-0, mysql-1, mysql-2. Pods also maintain stable network identities through a headless Service, so each Pod is reachable at a stable DNS name.

Each Pod in a StatefulSet is typically associated with a specific PersistentVolume through its PVC. When a Pod is replaced, the new Pod with the same ordinal number connects to the same PV, preserving data.

StatefulSets also guarantee ordered deployment and termination. Pods are created and deleted in order, which is important for applications that have dependencies (like a database cluster where one node should be master and others should be replicas). StatefulSets also provide maxUnavailable controls to ensure a minimum number of Pods stay available during rolling updates.

You’d use StatefulSets for databases, caches, message brokers, and any application where Pod identity matters or where data must persist.

4. How would you back up and restore a StatefulSet with persistent data?

This tests your understanding of operational concerns for stateful applications.

Backup strategies depend on the application. For databases, you typically use the database’s native tools. For MySQL, you’d use mysqldump or binary log replication. For PostgreSQL, you’d use pg_dump or WAL archiving. For NoSQL databases, use their native backup mechanisms.

For generic data in PersistentVolumes, you can take snapshots of the underlying storage (e.g., EBS snapshots in AWS). You need to quiesce the application first to ensure the snapshot captures a consistent state.

To restore, you’d either restore from the database backup (if it’s a database) or recreate the PV from a snapshot. If restoring a snapshot, create a new PV from the snapshot and create a PVC that binds to it.

Tools like Velero can automate backup and restore of entire Kubernetes applications including stateful components, backing up both the manifests and the underlying storage.

5. What is a Deployment strategy for updating a StatefulSet without losing data?

This tests your understanding of safe updates for stateful applications.

StatefulSets have an updateStrategy that controls how Pods are updated. RollingUpdate (the default) updates Pods one at a time, stopping each Pod before starting its replacement. This ensures high availability but takes longer.

OnDelete never updates Pods automatically; you must manually delete each Pod to trigger an update. This gives you precise control but is more manual.

For a safe rolling update of a stateful application, ensure maxUnavailable is 0 (or leave it out, as 0 is default for StatefulSets). The Pod is fully shut down before a new one is started, which is critical for applications that need to clean up state or release locks.

Configure a preStop lifecycle hook that gives the application time to gracefully shut down and clean up. For a database replication setup, a preStop hook might step down the master before the Pod is terminated, so replica promotion can happen smoothly.

6. How would you handle a scenario where you need to migrate data from one PV to another?

This tests your ability to handle operational challenges with storage.

If you’re migrating a Pod from one storage backend to another, you need to copy data from the old PV to the new one. You can do this by creating a temporary Pod that mounts both the old and new PVs and copies data between them using rsync, cp, or a custom script.

Alternatively, if you can tolerate a brief outage, you can create a backup of the old PV (snapshot), create a new PV from a different StorageClass, and restore the data using the backup.

For databases, use the database’s replication features. For MySQL, set up replication from the old instance to a new instance on the new storage, then cut over once replication catches up.

Security Questions

1. What is RBAC (Role-Based Access Control), and how does it work in Kubernetes?

Interviewers ask this to verify you understand authorization and access control.

RBAC controls what authenticated users and service accounts can do in Kubernetes. An RBAC policy consists of a subject (user, group, or service account), a role (a set of permissions), and a binding that connects the subject to the role.

A Role defines a set of permissions (verbs like get, list, create, delete) on specific resource types (pods, services, etc.) in a specific namespace. A ClusterRole is the cluster-wide equivalent.

A RoleBinding assigns a Role to a subject within a namespace. A ClusterRoleBinding assigns a ClusterRole to a subject cluster-wide.

For example, you might create a Role called “pod-reader” that grants get and list permissions on Pods, then bind that Role to a user with a RoleBinding. Now that user can list and view Pods but can’t create or delete them.

Service accounts are Kubernetes identities for applications. Each Pod is assigned a service account, and the kubelet passes the service account’s credentials to the container. RBAC can control what each service account can do, providing fine-grained access control within applications.

2. What is a Service Account, and how should you use them?

This tests your understanding of application identity and RBAC.

A Service Account is a Kubernetes identity for applications. When you create a service account, Kubernetes creates a token that the service account can use to authenticate to the API Server. The token is stored in a Secret and automatically mounted into every Pod using that service account.

By default, every Pod runs under the “default” service account in its namespace. You can create custom service accounts for different applications and bind different RBAC roles to them, so each application only has access to what it needs.

Best practice is to create a dedicated service account for each application, even if they share a namespace. This allows granular RBAC policies and makes it easy to audit what each application can do. Never give a service account admin or cluster-admin access unless absolutely necessary; follow the principle of least privilege.

You can also use service accounts to integrate with external identity providers like AWS IAM or Azure AD using OIDC or other federation mechanisms.

3. What is Pod Security Policies (or Pod Security Standards in newer versions)?

This tests your understanding of container security controls.

Pod Security Policies (deprecated) and the newer Pod Security Standards (PSS) define security requirements that Pods must meet. These include settings like running as non-root, dropping capabilities, disabling privileged mode, and more.

Pod Security Standards defines three profiles: restricted (most restrictive, requires secure defaults), baseline (minimal restrictions for backward compatibility), and unrestricted (no restrictions). You can enforce a standard on a namespace using labels.

For example, the restricted standard requires Pods to run as non-root, prevents privileged escalation, drops dangerous capabilities, uses read-only filesystems, and requires securityContext settings. By enforcing PSS, you ensure all Pods meet minimum security requirements.

4. What is a Network Policy, and how would you use it to restrict traffic?

This tests your understanding of network-level security.

A NetworkPolicy is a firewall rule for Pods. By default, all Pods can communicate with all other Pods. A NetworkPolicy restricts which Pods can send traffic to which Pods.

A basic NetworkPolicy might look like: “Pods with label tier=frontend can send traffic to Pods with label tier=backend on port 8080.” This explicitly allows traffic matching the policy and implicitly denies all other traffic to those Pods.

You can define both ingress (incoming) and egress (outgoing) policies. For a zero-trust architecture, you’d define a default-deny policy that blocks all traffic, then explicitly allow only the traffic you need.

Important caveat: NetworkPolicies only work if your CNI plugin supports them (Calico, Cilium, etc.). The default kubenet plugin doesn’t enforce NetworkPolicies.

5. How would you secure secrets in Kubernetes?

This tests your understanding of secret management best practices.

Kubernetes Secrets are base64-encoded by default, not encrypted. For production, you should enable encryption at rest for etcd so Secrets are encrypted when stored. You can use a KMS provider (like AWS KMS or Google Cloud KMS) to manage encryption keys.

Use RBAC to restrict who can access Secrets. By default, anyone who can run `kubectl get secrets` can read all Secrets in a namespace. Create custom RBAC roles that restrict Secret access to only the users and service accounts that need it.

Never commit Secrets to version control. Use a secret management tool like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault to manage secrets outside the cluster, and have your applications fetch them at runtime.

Use sealed-secrets or similar tools to encrypt Secrets at rest in git. With sealed-secrets, you encrypt Secrets with a public key and commit the encrypted Secrets to git. The cluster has the private key and can decrypt them.

Audit Secrets access using API Server audit logs. Log all API requests including Secret access so you can detect unauthorized access.

6. What is the principle of least privilege in Kubernetes, and how do you implement it?

This tests your understanding of security best practices.

The principle of least privilege means giving each user, service account, and application only the permissions it needs to do its job, no more.

Implement this by creating granular RBAC roles that grant specific permissions on specific resource types. For example, instead of giving a service account admin access, create a Role that grants only get and list permissions on ConfigMaps and Secrets in a specific namespace.

Use PodSecurityContext and containers’ securityContext to run containers as non-root, drop unnecessary capabilities, and prevent privilege escalation.

Use NetworkPolicies to allow only necessary network traffic between Pods.

Regularly audit what access each service account actually uses and remove unnecessary permissions. Many teams start with broad permissions for development and forget to tighten them for production.

7. How would you implement role-based access control for a multi-tenant cluster?

This tests your understanding of multi-tenancy and RBAC at scale.

For a multi-tenant cluster, each tenant should have its own namespace. Create ClusterRoles that define permissions each tenant role needs (developer, admin, viewer), then bind those roles to users in each tenant’s namespace using RoleBindings.

A developer might be able to get, list, create, update, and delete Pods in their team’s namespace but have no access to other namespaces or cluster-wide resources.

An admin in a namespace can modify RBAC and resource quotas within that namespace but can’t affect other namespaces.

Use ResourceQuotas to prevent one tenant from consuming all cluster resources. Each namespace gets a quota limiting total CPU, memory, storage, and number of Pods.

Use NetworkPolicies to prevent traffic from one tenant’s Pods to another’s. Use a default-deny policy and explicitly allow only cross-tenant traffic that’s necessary.

8. What is Certificate Management in Kubernetes, and how would you secure inter-node communication?

This tests your understanding of TLS and security infrastructure.

Kubernetes uses TLS certificates for secure communication between components. The API Server, kubelet, and other components use certificates to authenticate and encrypt traffic.

When you set up a cluster, you need to provision certificates for the API Server, kubelet, etcd, and other components. Tools like kubeadm automate this. In a cloud-managed Kubernetes service, the provider handles certificate provisioning and rotation.

For inter-Pod communication, by default traffic is not encrypted. You can enable mTLS (mutual TLS) using a service mesh like Istio or Linkerd, which automatically encrypts all Pod-to-Pod traffic and handles certificate management.

For user-facing services, use TLS certificates in Ingresses or Services to encrypt traffic between clients and your applications. Store certificates in Kubernetes Secrets, and use cert-manager to automate certificate issuance and renewal from Let’s Encrypt or another CA.

Troubleshooting and Debugging Questions

1. A Pod is in a CrashLoopBackOff state. How would you troubleshoot it?

Interviewers ask this to see if you can methodically debug real problems.

First, check the Pod’s status with `kubectl describe pod pod-name`. The events section shows recent state changes and errors. Often this tells you why the Pod is crashing (e.g., ImagePullBackOff if the image can’t be pulled, CrashLoopBackOff if the container keeps exiting).

Check the logs with `kubectl logs pod-name`. If the Pod is crashing before logs are written, use `kubectl logs pod-name –previous` to see logs from the previous container instance.

If logs don’t show an obvious error, check the container’s exit code. Exit code 0 means the application exited successfully (might be correct behavior if it’s a Job). Exit code 1 usually means an error. Exit code 137 means the container was killed (likely OOMKilled due to memory limit being exceeded).

Check resource limits. If the Pod has a low memory limit and the application is memory-intensive, it might be getting killed. Use `kubectl describe pod pod-name` to see the limits and check how much memory the application actually needs.

Try running the same image locally (docker run) to see if the image itself has a problem, or check if there’s a readiness probe failing immediately that triggers a restart.

2. A Service has no endpoints (no Pods are being selected). How would you debug?

This tests your understanding of Service-to-Pod binding.

Check the Service definition with `kubectl describe service service-name`. Look at the Selector field. The Service uses selectors to find Pods that match.

Find Pods that match the selector with `kubectl get pods -l selector-key=selector-value`. If no Pods are returned, no Pods match the Service’s selector. Check if the Pods have the right labels. Add or correct labels if needed.

If Pods do match, check if they’re in the same namespace as the Service. Services only select Pods in the same namespace by default.

Check if the Pods are Ready. A Pod that’s not in Running and Ready status won’t be added to the Service’s endpoints. Check `kubectl get pods` and look at the READY column. If a Pod shows 0/1 or 0/2, it’s not ready.

Check the readiness probe. If the readiness probe is failing, the Pod is in Running status but not Ready, so it’s excluded from the Service. Check `kubectl describe pod pod-name` to see the readiness probe status.

3. A Node is in NotReady state. What do you do?

This tests your understanding of node-level troubleshooting.

First, determine why the node is NotReady. Check the node’s status with `kubectl describe node node-name`. The Conditions section shows the status of various health checks. Common issues are DiskPressure, MemoryPressure, NetworkUnavailable, or a custom condition.

SSH into the node and check basic health: is the kubelet running? `systemctl status kubelet` on systemd-based systems. Are there errors in kubelet logs? Check /var/log/kubelet.log or use `journalctl -u kubelet`.

Check disk space and memory on the node. Run `df` and `free` commands. If disk is full, clean up or expand. If memory is exhausted, investigate which processes are consuming it.

Check network connectivity. Can the node reach the API Server? Can it reach other nodes? Check firewall rules and security groups.

Check if the container runtime is working. The kubelet depends on Docker, containerd, or another runtime. Check if the runtime is running and healthy.

Restart the kubelet if possible, but first cordon the node (`kubectl cordon node-name`) so new Pods aren’t scheduled to it. Existing Pods will continue running. Once you’ve fixed the issue and the node is healthy again, uncordon it (`kubectl uncordon node-name`).

4. You need to debug a Pod but it doesn’t have bash or curl. What’s your approach?

This tests your creativity and knowledge of debugging tools.

Use `kubectl exec` with a different shell if bash isn’t available. Many Alpine Linux images have sh instead of bash. Try `kubectl exec -it pod-name — sh`.

If no shell is available, install one with apt-get or apk if it’s a Debian or Alpine image. `kubectl exec -it pod-name — apt-get update && apt-get install -y curl`.

Use `kubectl debug` (Kubernetes 1.18+) to create a debug container that shares the Pod’s network namespace but has more tools. `kubectl debug -it pod-name –image=busybox` creates a busybox container in the same Pod and lets you run commands from there. This container sees the Pod’s network interfaces and can curl localhost to reach other containers in the Pod.

Use ephemeral containers to temporarily add a container to a running Pod for debugging without restarting it.

5. You suspect network connectivity issues between two Pods. How do you debug?

This tests your understanding of Kubernetes networking.

First, verify both Pods are running and have assigned IP addresses. `kubectl get pods -o wide` shows Pod IPs.

From the source Pod, try pinging the destination Pod’s IP: `kubectl exec -it source-pod — ping destination-ip`. If ping fails, basic network connectivity is broken.

Try using wget or curl to the destination if it’s an HTTP service: `kubectl exec -it source-pod — wget http://destination-ip:port`. Check both the IP and the Service name.

Check DNS resolution: `kubectl exec -it source-pod — nslookup destination-service`. If DNS resolution fails, check if CoreDNS is running (`kubectl get pods -n kube-system -l k8s-app=kube-dns`).

Check NetworkPolicies. Run `kubectl get networkpolicies –all-namespaces` and inspect any policies that might block traffic between the Pods.

Check the CNI plugin logs on the nodes: `kubectl logs -n kube-system -l k8s-app=flannel` (for Flannel) or equivalent for your CNI.

Check if the Pods are on the same node or different nodes. If different nodes, check if the underlying network between nodes is working (can the nodes ping each other?).

6. How would you troubleshoot a high-latency issue in Kubernetes?

This tests your understanding of performance diagnostics.

First, identify where the latency is coming from. Is it network latency (Pods communicating slowly)? Is it application latency (the application is slow)? Is it scheduling latency (Pods take too long to start)?

For network latency, check if Pods are on the same node. If not, inter-node latency might be the culprit. Check node-to-node network latency using tools like mtr or iperf. Check for network saturation: `kubectl top nodes` to see node resource usage.

For application latency, use application profiling tools (like pprof for Go, JFR for Java) to identify slow code paths. Check if the application is hitting resource limits (CPU throttling, memory pressure). Check `kubectl top pods` to see resource usage.

For scheduling latency, check if the scheduler is slow or if there are resource constraints. Use events to see how long Pod startup takes: `kubectl describe pod pod-name` shows events with timestamps.

Check if network policies or service mesh policies are adding latency. Disable them temporarily to see if they’re the cause.

Monitor kube-apiserver latency. If the API Server is slow, all Kubernetes operations are affected. Check kube-apiserver logs and metrics.

Advanced and Experienced Candidate Questions

1. What is Horizontal Pod Autoscaling (HPA), and how does it work?

Interviewers ask this to see if you understand advanced scaling patterns.

HPA automatically scales the number of replicas in a Deployment based on observed metrics. You define a target metric (like CPU utilization or custom metrics), and the HPA controller adjusts the number of replicas to maintain that target.

The HPA controller periodically queries the metrics server for the current value of the metric. If the metric is above the target, it scales up. If it’s below, it scales down. You can set min and max replicas to prevent excessive scaling.

For example, you might set a target CPU utilization of 70%. If Pods are averaging 90% CPU, HPA scales up. If they drop to 50%, it scales down. The scaling happens gradually (one replica every minute by default) to avoid thrashing.

HPA requires the metrics-server to be installed in the cluster. It works with the default metrics (CPU and memory) or custom metrics from applications or monitoring systems.

2. What is Vertical Pod Autoscaling (VPA), and when would you use it?

This tests your knowledge of resource right-sizing.

VPA automatically adjusts resource requests and limits for containers. It monitors actual resource usage and recommends new values. VPA can automatically apply recommendations, or you can review them manually.

You’d use VPA when resource requests are inaccurate. For example, if you requested 512Mi of memory but the application actually uses 256Mi, VPA reduces the request. This allows better resource utilization and scheduling.

VPA and HPA can work together but with care. HPA scales based on metrics like CPU percentage, which is relative to the requested CPU. If VPA changes requests, HPA’s behavior changes. Use VPA for right-sizing and HPA for scaling to handle load spikes.

3. Explain custom metrics and external metrics for autoscaling.

This tests your understanding of advanced scaling scenarios.

Custom metrics are application-specific metrics like “requests per second” or “queue depth.” You expose these metrics from your application and register them with Kubernetes’ metrics server (using Prometheus or another monitoring system). HPA can then scale based on these metrics.

External metrics are metrics from external systems like cloud autoscaling metrics, queue depths from message brokers, or metrics from monitoring tools. HPA can use external metrics to scale based on external factors.

For example, you might scale your application based on AWS SQS queue depth. As the queue grows, you scale up Pods to process messages faster. Once the queue drains, you scale down.

4. What is a Kubernetes Operator, and how would you create one?

This tests your understanding of extending Kubernetes with custom logic.

An Operator is a method for extending Kubernetes functionality. It uses custom resources (CRDs) and a controller to automate complex operational tasks. An Operator embeds domain-specific knowledge of how to manage a particular application or service.

For example, the Prometheus Operator knows how to deploy and manage Prometheus instances. You define a Prometheus custom resource, and the operator handles creating the Deployment, StatefulSet, and configuration.

Operators typically use controllers (written in Go using the operator-sdk framework) that watch custom resources and take action when they change. If you create a custom resource, the operator might create a Deployment. If you modify the resource, the operator updates the Deployment accordingly.

Creating an Operator requires defining a CRD (Custom Resource Definition), writing controller logic, and packaging it as a Helm chart or operator package for installation. The Operator Framework and Kubebuilder simplify Operator development.

5. How would you implement a blue-green deployment in Kubernetes?

This tests your understanding of advanced deployment strategies.

In a blue-green deployment, you run two identical production environments: blue (current) and green (new). You deploy the new version to green while blue continues serving traffic. Once green is ready and tested, you switch traffic from blue to green. If something goes wrong, you quickly switch back to blue.

Implement this using two Deployments (blue and green) with different image versions. Both Deployments have the same labels. Use a Service that selects Pods based on a version label. To switch traffic, update the Service’s selector to point to the new Deployment.

Alternatively, use an Ingress that routes traffic to blue’s Service. Update the Ingress to point to green’s Service to switch traffic.

Blue-green deployments provide instant rollback capability and zero-downtime deployments. The downside is that you need to maintain two full environments, doubling resource requirements.

6. What is a Canary deployment, and how would you implement one?

This tests your knowledge of progressive delivery.

In a canary deployment, you gradually shift traffic to a new version. Start with a small percentage of traffic (5-10%) going to the new version while most traffic goes to the old version. Monitor metrics, and if the new version is healthy, gradually increase the percentage until 100% of traffic goes to the new version.

Implement this using a service mesh like Istio or Linkerd, which can split traffic between two versions based on percentages. Or use an Ingress controller that supports traffic splitting.

You can automate canary deployments using tools like Flagger, which automatically promotes a canary version if metrics are healthy and rolls back if metrics degrade.

Canary deployments reduce risk by catching issues with new versions before they affect all users. They require good observability (metrics and logs) to detect problems quickly.

Questions to Ask the Interviewer

At the end of the interview, interviewers typically ask if you have questions. This is an opportunity to demonstrate genuine interest and technical depth. Here are some questions worth asking.

Ask about the organization’s Kubernetes setup and architecture. What version of Kubernetes do they run? Do they use a managed service like EKS or AKS, or do they manage their own clusters? This shows you’re thinking about how your knowledge applies to their specific situation.

Ask about operational challenges they’ve faced. “What’s the biggest challenge you’ve had with Kubernetes in production?” This opens a conversation about real issues, not theoretical ones, and shows you care about understanding their pain points.

Ask about their release and deployment process. How do they handle new feature rollout? What’s their strategy for backward compatibility? This reveals whether they think carefully about deployments or just push changes.

Ask about their observability and monitoring practices. How do they monitor Kubernetes clusters and applications? What observability challenges have they run into? This shows you understand that operations depend heavily on visibility.

Ask about team structure and on-call rotations. Who owns Kubernetes infrastructure? Are there dedicated platform engineers? This helps you understand the role and whether it includes on-call responsibilities.

Ask about their security practices. How do they manage secrets? What’s their RBAC strategy? This demonstrates security-mindedness and gets at operational maturity.

Ask about their plans for growth or technology improvements. Are they planning to migrate more workloads to Kubernetes? Planning to improve observability? This shows forward-thinking and helps you understand whether the role is stable or in flux.

For more comprehensive interview preparation, check out the pillar resource on best answers to interview questions. You can also deepen your knowledge of related technologies by exploring Kafka interview questions, SDET interview questions, and web API interview questions.

For infrastructure as code and cloud platform expertise, see our guides on Terraform interview questions and Snowflake interview questions. If you’re interviewing for related roles, check quality engineer interview questions and data analyst interview questions.

For broader preparation, review our resources on strategic questions to ask candidates, management assistant interview questions, and executive assistant interview questions.