These 28 Kubernetes interview questions test whether an engineer can run workloads on Kubernetes 1.3x clusters in production, not just write a Deployment manifest. They cover scheduling, resource management, probes, RBAC, networking and CNI choices, Gateway API, autoscaling, operators and debugging pods that won't start or won't stay up. Ryz vets Kubernetes engineers the same way: recruiters source candidates who have operated real clusters, structured NTRVSTA AI interviews walk them through scenarios like these, and recruiters review the results. The AI scores are advisory, and people make the call.
Separate cluster operators from application engineers who deploy to Kubernetes. Operators should get the debugging, networking and senior sections; application engineers need fundamentals, probes, scheduling and graceful shutdown. Five or six questions plus a live debugging task fill an hour.
Whenever a candidate names a feature, ask what it costs or how it fails. Anyone can say "use an HPA"; a strong engineer explains why it didn't scale a queue worker.
The API server authenticates, authorizes and runs admission on the request, then stores the object in etcd. The Deployment controller creates a ReplicaSet, which creates Pods. The scheduler binds each Pod to a node, the kubelet on that node pulls images through the container runtime (CRI), the CNI plugin wires up networking, and probes start once containers run.
What a strong answer shows: everything is a controller reconciling desired state, which is how they reason about where a stuck rollout is stuck.
Requests drive scheduling and the share of CPU a container gets under contention. Limits cap usage: exceeding the CPU limit causes throttling, exceeding the memory limit gets the container OOM-killed. Pods with requests equal to limits for every container are Guaranteed, pods with some requests are Burstable, and pods with none are BestEffort and get evicted first under node pressure.
What a strong answer shows: they explain why many teams set memory limits but leave CPU limits off for latency-sensitive services.
Readiness removes a pod from Service endpoints while it can't serve. Liveness restarts a container that is stuck. Startup holds off the other probes while a slow app boots.
startupProbe:
httpGet: { path: /healthz, port: 8080 }
periodSeconds: 2
failureThreshold: 30
readinessProbe:
httpGet: { path: /ready, port: 8080 }
periodSeconds: 5
livenessProbe:
httpGet: { path: /healthz, port: 8080 }
periodSeconds: 10
failureThreshold: 3
What a strong answer shows: liveness checks only the process itself; a liveness probe that calls the database restarts every pod during a database blip.
The Service gets a virtual IP. Controllers track ready pods matching its selector in EndpointSlices, and kube-proxy (iptables, IPVS or nftables mode) or an eBPF replacement such as Cilium programs each node to translate the virtual IP to a pod IP. DNS gives the Service a stable name.
What a strong answer shows: they connect readiness to EndpointSlices, which explains most "Service has no endpoints" issues.
By default they are base64-encoded, not encrypted, in API responses, and are only encrypted in etcd if encryption at rest is configured. Anyone who can read Secrets in a namespace, or create pods there, can get them. Restrict access with RBAC, enable encryption with a KMS provider, and sync from an external store with something like External Secrets Operator.
What a strong answer shows: they know "create pod" permission is effectively "read every Secret the pod could mount".
Deployments run interchangeable stateless replicas. StatefulSets give stable names, ordered rollout and per-replica volumes for databases and clustered systems. DaemonSets run one pod per node for agents like log shippers and CNI. Jobs and CronJobs run work to completion.
What a strong answer shows: they know a StatefulSet doesn't make an application replicated or safe; it only gives it identity and storage.
Namespaces scope names, RBAC, resource quotas and many policies. They don't isolate the network (pods can talk across namespaces without NetworkPolicy), nodes, the kernel or cluster-scoped resources like CRDs and storage classes.
What a strong answer shows: they treat namespaces as an organizational boundary, not a security boundary on their own.
When a pod is terminated, endpoint removal and SIGTERM happen in parallel, so the load balancer can still route to a pod that is shutting down. Add a short preStop pause so endpoints update first, make the app stop accepting new connections and drain on SIGTERM, set a grace period long enough to finish requests, and keep maxUnavailable at zero for small replica counts.
spec:
terminationGracePeriodSeconds: 45
containers:
- name: app
lifecycle:
preStop:
sleep:
seconds: 10
What a strong answer shows: they understand the race between the control plane and the data plane instead of only raising timeouts.
Use topology spread constraints on zone and hostname, or pod anti-affinity for strict separation. Combine with a PodDisruptionBudget so drains don't remove too many replicas at once.
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: checkout
What a strong answer shows: they weigh DoNotSchedule against ScheduleAnyway, since strict spreading can leave pods Pending when a zone is short on capacity.
Queue workers are often I/O bound, so CPU stays flat while the backlog grows. Scale on the metric that matters: queue depth or lag, through external metrics or KEDA. Tune HPA behavior to scale up fast and down slowly, and don't run VPA on the same CPU or memory metric.
What a strong answer shows: they choose the scaling signal from what the workload is waiting on.
Cluster Autoscaler scales predefined node groups up when pods are unschedulable and down when nodes are underused. Karpenter provisions nodes directly from pod requirements, picks instance types per batch of pending pods and actively consolidates. Karpenter usually packs better and reacts faster but makes node churn a normal event.
What a strong answer shows: they pair consolidation with PDBs and graceful shutdown so cost savings don't become outages.
Usually a PodDisruptionBudget that can't be satisfied: minAvailable equal to the replica count, or a single-replica service. Also check pods with long grace periods, finalizers blocking deletion, and bare pods without a controller. Fix the PDB or scale up rather than forcing the drain.
What a strong answer shows: they know a PDB of maxUnavailable: 0 blocks voluntary disruption forever.
A ServiceAccount, a namespaced Role with only the verbs and resources the deploy needs, and a RoleBinding. Then verify from the outside.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployer
namespace: shop
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "create", "update", "patch"]
---
# kubectl auth can-i delete secrets -n shop \
# --as=system:serviceaccount:ci:deployer -> no
What a strong answer shows: they avoid ClusterRoleBindings for namespaced work and test denials, not just allows.
A sidecar is declared as an init container with restartPolicy: Always. It starts before the main containers, keeps running alongside them, and is stopped after them. That fixes two old problems: Jobs that never completed because a proxy sidecar kept running, and apps that started before their proxy was ready.
What a strong answer shows: they connect the feature to concrete failures with service meshes and log shippers.
Read the exit code and reason, the previous container's logs, and recent events. Exit code 137 suggests an OOM kill or SIGKILL, 1 an application error, and a missing log usually means bad config or a missing file.
kubectl describe pod checkout-7d9f -n shop
kubectl logs checkout-7d9f -n shop --previous
kubectl get events -n shop --sort-by=.lastTimestamp
kubectl debug -it checkout-7d9f -n shop --image=busybox:1.36 --target=app
What a strong answer shows: they reach for --previous and ephemeral debug containers, since distroless images have no shell.
The container limit covers the whole process: heap, metaspace, thread stacks, direct buffers, and native memory from libraries. Size the heap as a percentage of the limit with -XX:MaxRAMPercentage, leave headroom, and check native memory tracking. The same idea applies to Node.js heap flags and to Go's GOMEMLIMIT.
What a strong answer shows: they distinguish the runtime's view of memory from the cgroup's.
Check whether the Service has endpoints and whether the selector matches the right pods, then test from a debug pod by DNS name, by Service IP and by pod IP to split DNS, kube-proxy and pod problems. Look at NetworkPolicies on both sides and at readiness flapping that removes endpoints.
What a strong answer shows: a methodical layer-by-layer split instead of restarting things.
The default ndots:5 makes names with fewer than five dots try each search domain first, so one external lookup becomes several queries. Use fully qualified names with a trailing dot, lower ndots in dnsConfig for affected workloads, scale CoreDNS, and consider NodeLocal DNSCache.
What a strong answer shows: they confirm with packet capture or CoreDNS metrics before changing cluster-wide settings.
The scheduler explains it in the pod's events: insufficient CPU or memory for the requests, taints without tolerations, node selectors or affinity that match nothing, or a PersistentVolume bound to a different zone than the available nodes. Use WaitForFirstConsumer volume binding so storage follows the scheduling decision.
What a strong answer shows: they read the scheduler's message first and know the zonal storage trap.
Read the changelog for removed APIs and check manifests and Helm charts with a tool such as kubent or pluto. Upgrade the control plane first, respect the kubelet version skew policy, then roll node pools with surge capacity, PDBs in place and add-ons (CNI, CSI, ingress) upgraded to compatible versions. Rehearse in a staging cluster.
What a strong answer shows: they treat add-ons as the most likely breakage, not the control plane.
Gateway API is the standard successor: typed routes (HTTPRoute, GRPCRoute), traffic splitting, header matching and a split between platform-owned Gateways and team-owned routes. With the community ingress-nginx controller now retired, new clusters should start on Gateway API.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: checkout
namespace: shop
spec:
parentRefs:
- name: public-gateway
namespace: infra
rules:
- matches:
- path: { type: PathPrefix, value: /checkout }
backendRefs:
- { name: checkout-v1, port: 8080, weight: 90 }
- { name: checkout-v2, port: 8080, weight: 10 }
What a strong answer shows: they know the Gateway must allow routes from the shop namespace, which is the point of the role split.
Pick a CNI that enforces NetworkPolicy and fits your cloud's IP model; eBPF-based options like Cilium add L7 visibility and can replace kube-proxy. Roll out policy by observing flows first, then default-deny per namespace with explicit allows, including DNS egress.
What a strong answer shows: they remember that default-deny breaks DNS unless egress to CoreDNS is allowed.
When an application needs ongoing, domain-specific operations (failover, backups, scaling with ordering) that you would otherwise do by hand. A reliable operator has an idempotent reconcile loop, writes status conditions, uses owner references and finalizers correctly, and handles requeues and partial failure. Most teams should use an existing operator first.
What a strong answer shows: they reconcile from observed state every time instead of reacting to individual events.
Namespace per team or service, RBAC through groups, ResourceQuotas and LimitRanges, default-deny NetworkPolicy, Pod Security Admission at restricted, and admission policies for registries and labels. Hard isolation between untrusted tenants calls for separate clusters or sandboxed runtimes.
What a strong answer shows: they match the isolation level to the trust level between tenants.
Admission policy. ValidatingAdmissionPolicy with CEL expressions is built in and needs no webhook; Kyverno or OPA Gatekeeper add mutation, generation and richer reporting. Roll out new rules in audit or warn mode, then enforce.
What a strong answer shows: they consider webhook availability, since a failing webhook with failurePolicy: Fail can block every deploy.
It is viable with a mature operator such as CloudNativePG, good storage classes, tested backups and people who understand both Postgres and Kubernetes. A managed database is usually simpler when the team is small or the data is critical. Decide on operational skill and recovery requirements, not ideology.
What a strong answer shows: they ask who restores the database at 3 a.m. and how that was tested.
For blast radius, regional failover, compliance boundaries, or scale limits of a single control plane. Manage the fleet declaratively with GitOps, standardize add-ons, and decide how traffic fails over between clusters before you need it.
What a strong answer shows: they weigh the operational cost of every extra cluster against the isolation it buys.
Compare requests with actual usage, since overstated requests waste whole nodes. Rightsize with VPA recommendations, use spot capacity for tolerant workloads, improve bin packing, and scale idle environments to zero. In-place pod resize in recent releases lets you adjust resources without restarting pods.
What a strong answer shows: they attribute cost per namespace or team so owners can act on it.
cluster-admin to CI or to application service accounts.Run a 60 to 90 minute live session on a local kind or k3d cluster with a pre-broken application: a Deployment whose liveness probe hits a dependency, a Service selector with a typo, a memory limit below the app's real usage, and a NetworkPolicy that blocks DNS. Ask the candidate to get it healthy, then make it survive a rolling deploy and a node drain without errors.
Ryz introduces senior Kubernetes engineers who have run production clusters through upgrades, incidents and cost reviews. They are the top 1% of the candidates we interview, they embed in your platform team and repos, and they work within ±1h of US time zones. Learn about our vetting process or use our Kubernetes engineer job description as a starting point.
No. CKA and CKAD prove someone can perform tasks under time pressure, which is useful, but they don't test judgment about architecture, cost or incidents. Use them as a baseline and spend the interview on scenarios.
Give the candidate a kind or k3d cluster they can start on their own machine from a repository, or a short-lived cloud cluster you control. Share the screen, prepare the broken state in advance, and keep the setup under five minutes.
No. Application engineers need probes, resources, graceful shutdown and how to read pod events. Deep knowledge of networking, upgrades, operators and multi-tenancy belongs with the platform engineers who run the clusters.
Questions we didn't answer? Email info@ryzlabs.com.