25 Kubernetes interview questions

Listen for: A strong answer starts with scope and recent changes, then uses kubectl get/describe, events, previous logs, readiness/liveness failures, ConfigMap or Secret changes, image tags, command/args, and resource limits. They should distinguish crash from scheduling issues and avoid deleting random resources before capturing evidence.

Red flag: They jump straight to restarting nodes or deleting pods without checking logs, events, or rollout history.

Listen for: Look for practical workload reasoning: stateless replicated services use Deployments, ordered identity and stable storage use StatefulSets, finite tasks use Jobs, scheduled tasks use CronJobs. Good candidates mention restart behavior, idempotency, storage, DNS identity, scaling, and operational expectations rather than just repeating definitions.

Red flag: They choose resources based only on whether the app has a database, with no discussion of identity, storage, or lifecycle.

Listen for: They should verify Service selectors and endpoints, pod labels, container ports versus targetPort, DNS name, NetworkPolicies, kube-proxy or CNI health, and whether the destination is actually ready. Good answers use temporary debug pods carefully and test DNS and TCP separately instead of assuming one cause.

Red flag: They assume Kubernetes networking is flat and ignore NetworkPolicy, selectors, and endpoints.

Listen for: Listen for operational consequences: readiness controls traffic, liveness restarts containers, startup probes protect slow boot. Strong answers mention dependency checks, timeouts, failure thresholds, graceful startup, avoiding expensive checks, and how aggressive liveness probes can create restart loops under load or during dependency incidents.

Red flag: They say both probes are health checks and Kubernetes will figure out the difference automatically.

Listen for: They should know mounted ConfigMaps can update eventually, environment variables do not, and many apps need reload or restart. Good answers mention versioned ConfigMaps or checksum annotations, controlled rollout, validation in a lower environment, and confirming pods consumed the new config before proceeding.

Red flag: They assume every ConfigMap change instantly and safely changes all running application behavior.

Listen for: A good answer uses describe pod and events first, then checks resource requests, node selectors, taints and tolerations, affinity, quota, PVC binding, image pull secrets only if scheduling occurred, and cluster autoscaler behavior. They should separate scheduling failures from container startup failures.

Red flag: They treat Pending as a container problem and focus only on application logs.

Listen for: Strong answers compare traffic volume, HPA behavior, resource requests and limits, node pools, topology spread, PDBs, NetworkPolicies, ingress or Gateway configuration, external dependencies, secrets, and feature flags. They should ask how staging mirrors production and use metrics, events, and rollout history to isolate environmental differences.

Red flag: They conclude staging is useless without identifying concrete differences to measure or fix.

Listen for: Look for an iterative approach: start from observed CPU and memory profiles, set requests for scheduling and baseline SLOs, be careful with CPU limits, set memory limits to contain leaks, use VPA recommendations where appropriate, and review throttling, OOMKills, latency, and HPA behavior after deployment.

Red flag: They use the same requests and limits for every service or always set CPU limits without considering throttling.

Listen for: Good candidates separate packaging from environment overlays and reconciliation. They discuss Helm values discipline, Kustomize patches, Argo CD or Flux sync waves, drift detection, secrets handling, promotion, rollback, and ownership boundaries. They should warn against giant values files, unreviewed manual kubectl changes, and templating business logic.

Red flag: They describe GitOps as simply running helm upgrade from a CI job.

Listen for: They should inspect HPA status, metrics-server or custom metrics, target utilization, pod requests, stabilization windows, max replicas, readiness delays, and whether latency correlates with CPU, memory, queue depth, or external bottlenecks. Strong answers mention using KEDA or custom metrics when CPU is the wrong signal.

Red flag: They increase maxReplicas immediately without checking whether the scaling metric is valid.

Listen for: A strong answer covers version skew, API deprecations, add-on compatibility, CRDs and controllers, node image upgrades, PDBs, surge capacity, canary node pools, backups for etcd-managed data where applicable, and rollback plans. They should mention testing manifests with tools such as kubent, Pluto, or server-side dry run.

Red flag: They rely entirely on the cloud provider upgrade button and do not check workloads or APIs.

Listen for: Listen for methodical checks: distinguish DNS lookup failures from connection failures, inspect CoreDNS pods, logs, metrics, ConfigMap, node-local DNS cache if used, search paths, ndots behavior, NetworkPolicies, upstream resolver health, and noisy workloads. Good answers use dig/nslookup from a debug pod and compare service FQDNs.

Red flag: They blame CoreDNS for every service connectivity issue without testing name resolution separately.

Listen for: Strong answers treat Kubernetes Secrets as base64-encoded API objects, not a full secret manager. They discuss encryption at rest, RBAC, External Secrets Operator or Secrets Store CSI Driver, cloud KMS, rotation, least privilege, audit logs, avoiding secrets in Helm values, and clear break-glass procedures.

Red flag: They commit Secret manifests with plain values to Git because the field is called data.

Listen for: Look for a staged plan: inventory current access, map personas, define RBAC roles, use groups and short-lived access, create namespace ownership, add audit logging, communicate migration windows, and provide safe self-service paths. Strong answers avoid breaking teams abruptly and include exception handling.

Red flag: They either remove all access immediately or accept cluster-admin as the only practical option.

Listen for: A senior answer considers immediate containment and root cause: API server metrics, audit logs, client identity, watch/list patterns, QPS settings, leader election, controller logs, CRD scale, and rate limiting. They coordinate with the vendor, test configuration changes, and avoid killing reconciliation blindly if it protects production workloads.

Red flag: They uninstall the controller immediately without understanding what resources it owns.

Listen for: Strong answers cover namespace ownership, RBAC, ResourceQuota, LimitRange, NetworkPolicy, Pod Security Standards, admission policies, naming conventions, observability labels, cost allocation, and escalation paths. They should identify when separate clusters are warranted for isolation, compliance, noisy neighbors, or blast radius.

Red flag: They say namespaces are a security boundary by themselves.

Listen for: Look for Gateway API v1 knowledge and migration judgment: inventory ingress features, choose controller support, model Gateway, HTTPRoute, TLS, redirects, auth integrations, canary routes, DNS cutover, rollback, and ownership separation between platform and app teams. They should validate behavior with real traffic before deprecating Ingress objects.

Red flag: They assume Gateway API is a drop-in YAML rename for every Ingress controller feature.

Listen for: A strong answer distinguishes memory, disk, PID, and ephemeral storage pressure; inspects kubelet events, cadvisor metrics, container logs, image GC, emptyDir usage, requests, QoS classes, and daemon overhead. They discuss workload fixes, node sizing, eviction thresholds, alerts, and prevention rather than only adding nodes.

Red flag: They respond to all node pressure by increasing cluster size without finding the pressure source.

Listen for: Listen for balanced policy design using ValidatingAdmissionPolicy, Kyverno, OPA Gatekeeper, or cloud-native admission controls. Strong candidates enforce high-risk invariants such as privileged pods, hostPath, required labels, image provenance, and resource requests, while keeping complex style checks or team-specific preferences in CI to avoid blocking emergencies.

Red flag: They want admission control to enforce every preference, regardless of developer workflow or outage response.

Listen for: Good answers separate signals: API server, scheduler, controller manager, kubelet, CoreDNS, CNI, ingress/Gateway, storage, node pressure, and controller reconciliation for platform; RED or USE metrics, traces, logs, and SLOs for apps. They mention Prometheus, OpenTelemetry, Alertmanager, Grafana, and actionable alerts with runbooks.

Red flag: They only discuss pod logs and do not monitor control plane, networking, or storage components.

Listen for: Strong answers define cluster boundaries, namespace model, RBAC, GitOps repositories, environment promotion, quotas, network policies, admission policies, observability, cost labels, and upgrade ownership. They should justify shared versus isolated clusters by blast radius and operational overhead, not default to one cluster per team or one cluster for everything.

Red flag: They propose a single flat cluster with no tenancy model because Kubernetes already supports namespaces.

Listen for: Look for progressive delivery with Argo Rollouts or Flagger, Gateway API or service mesh routing, health metrics, automated analysis, database compatibility, feature flags, PDBs, HPA interactions, and rollback triggers. Strong answers separate traffic shifting from deployment creation and discuss observability needed to make promotion decisions.

Red flag: They equate canary with setting maxUnavailable to zero in a Deployment.

Listen for: A strong answer covers CNI choice such as Cilium or Calico, NetworkPolicy defaults, DNS, egress gateways or NAT, allow-listing external dependencies, Gateway API or ingress controllers, TLS termination, service discovery, observability with flow logs, and operational impact of policy rollouts.

Red flag: They say all pods can communicate by default and plan to rely only on application authentication.

Listen for: Listen for cloud workload identity patterns, Kubernetes service accounts, External Secrets Operator or Secrets Store CSI Driver, cloud KMS, rotation, auditability, RBAC, separation by namespace and environment, and avoiding long-lived cloud keys. Strong answers also discuss portability trade-offs and how teams request access.

Red flag: They put cloud access keys into Kubernetes Secrets and call it portable.

Listen for: Strong answers include a supported version policy, release calendar, conformance or smoke tests, API deprecation scanning, add-on compatibility matrix, node pool rotation, CRD/controller testing, GitOps drift checks, maintenance windows, rollback limits, and communication. They should handle exceptions without letting clusters become permanently unique.

Red flag: They treat upgrades as ad hoc tickets handled only when a cluster is already unsupported.