These Kubernetes interview questions cover what DevOps, cloud, SRE and platform interviews in 2026 actually test: how the control plane reconciles state, how workloads, networking, storage and scheduling fit together, and how you debug a cluster when something breaks. Interviewers rarely stop at "what is a Pod"; they ask why a Pod is Pending, what OOMKilled really means, and how you would roll back a bad release without making the outage worse. The 65 questions below run from fundamentals through Gateway API, autoscaling, RBAC, GitOps and upgrades to thirteen troubleshooting scenarios.
How to use this guide:
- Freshers and juniors are usually tested on architecture, Pods, Deployments, Services, ConfigMaps and kubectl.
- Mid-level DevOps engineers get storage, scheduling, probes, requests and limits, Helm and troubleshooting scenarios. Most CKA interview questions sit here.
- Senior and platform roles are pushed on RBAC, admission policy, multi-tenancy, upgrades and autoscaling design.
- Answer each question with the one-line answer, the mechanism, then a trade-off or the command you would run.
Contents
- Architecture and fundamentals (Q1–Q7)
- Kubernetes in 2026: versions and new features (Q8–Q9)
- Workloads: Deployments, StatefulSets, DaemonSets and Jobs (Q10–Q18)
- Services, Ingress, Gateway API and networking (Q19–Q26)
- Configuration, Secrets and storage (Q27–Q31)
- Scheduling, resources and QoS (Q32–Q37)
- Autoscaling and probes (Q38–Q41)
- Security, RBAC and multi-tenancy (Q42–Q46)
- Helm, GitOps, upgrades and observability (Q47–Q51)
- AI workloads on Kubernetes (Q52)
- Real-world troubleshooting scenarios (Q53–Q65)
- Key takeaways
- Interview preparation checklist
- FAQ
Architecture and fundamentals
1. What is Kubernetes, and what problem does it actually solve?
Answer: Kubernetes is an open-source container orchestration platform that runs containerised workloads across a cluster and keeps them in the state you declared. You describe desired state (three replicas of this image, on this port, with this much memory) as API objects, and controllers continuously compare it with actual state and act to close the gap. If a node dies, a controller sees fewer replicas than desired and creates replacements elsewhere.
That one mechanism gives you scheduling, self-healing, service discovery, rolling updates and rollbacks, config and secret injection, storage attachment and scaling behind one consistent API.
Interview tip: Say "declarative desired state plus control loops" early. It explains almost every later answer, from Deployments to GitOps.
2. Explain the Kubernetes architecture and its main components.
Answer: A cluster has a control plane and worker nodes.
kubectl / CI / GitOps
|
kube-apiserver <---> etcd
/ | \
scheduler controller- cloud-controller-
manager manager
|
-------------- nodes ---------------
kubelet -> container runtime (CRI) -> Pods
kube-proxy / CNI plugin (Service + Pod network)
- kube-apiserver: the front door for every read and write; handles authentication, authorisation, admission and validation, and is the only component that talks to etcd.
- etcd: the consistent key-value store holding all cluster state.
- kube-scheduler: assigns unscheduled Pods to nodes.
- kube-controller-manager: runs the built-in controllers (Deployment, ReplicaSet, Job, Node, EndpointSlice and others).
- cloud-controller-manager: load balancers, routes and node lifecycle on a cloud.
- kubelet: the node agent that runs assigned Pods through the container runtime, runs probes and reports status.
- kube-proxy (or a CNI that replaces it) programs Service routing; the CNI plugin provides Pod networking.
Interview tip: Components never call each other directly; they watch and update objects through the API server, which is why individual restarts are tolerated.
3. What is the role of etcd, and how do you make the control plane highly available?
Answer: etcd stores every object in the cluster. It uses Raft consensus, so writes need a majority (quorum) of members. Run an odd number: three members tolerate one failure, five tolerate two. Losing quorum makes the API unavailable, though running Pods keep running because kubelets do not need etcd to keep containers alive.
For high availability, run at least three control plane nodes across zones, put API servers behind a load balancer, and rely on leader election for the scheduler and controller manager. Back up etcd with etcdctl snapshot save, store snapshots off-cluster and encrypted (they contain Secrets), and test restores. On EKS, AKS and GKE the provider runs etcd, so disaster recovery shifts to backing up resources and volumes (for example with Velero) and keeping everything reproducible from git.
4. Walk through what happens when you run kubectl apply on a Deployment.
Answer:
- The API server authenticates you, checks RBAC, runs mutating and validating admission (including Pod Security Admission), validates the schema and stores the Deployment in etcd.
- The Deployment controller creates a ReplicaSet; the ReplicaSet controller creates Pod objects with no node yet.
- The scheduler filters and scores nodes and writes a binding for each Pod.
- The kubelet on the chosen node pulls the image, sets up networking through the CNI plugin, mounts volumes and starts containers.
- Once readiness passes, the EndpointSlice controller adds the Pod to matching Services.
Interview tip: Mentioning admission and EndpointSlices sets you apart; most candidates stop at "the scheduler places the Pod".
5. What is a Pod, and how does it differ from a container?
Answer: A Pod is the smallest deployable unit: one or more containers scheduled together on one node, sharing a network namespace (one IP, localhost between them) and optionally volumes. A container is a single isolated process tree built from an image. Kubernetes schedules, restarts and scales Pods, not containers. Most Pods have one app container; multi-container Pods are for tightly coupled helpers such as a log shipper or proxy. Pods are disposable and get a new IP when recreated, which is why you run them through a controller rather than as bare Pods.
6. What are namespaces, labels, selectors and annotations used for?
Answer: Namespaces scope names, RBAC, quotas and network policies; on their own they are not a hard security boundary. Labels are key-value pairs for grouping (app=payments, env=prod). Selectors query labels and are how objects find each other: Services select Pods, Deployments manage Pods matching their selector, NetworkPolicies target Pods. Annotations hold non-identifying metadata for tools, such as a change-cause or a controller setting.
Real-world example: Two Deployments with overlapping selectors can make a Service send traffic to the wrong application. Using the recommended app.kubernetes.io/ label set consistently prevents it.
7. What is the container runtime interface, and what happened to Docker in Kubernetes?
Answer: The Container Runtime Interface (CRI) is the gRPC API the kubelet uses to run containers, so any compliant runtime works; containerd and CRI-O are the common ones. Kubernetes used to reach Docker Engine through a built-in shim, dockershim, which was removed in 1.24. Docker-built images still run unchanged because they are standard OCI images, and Docker remains common for builds and local development; the Docker interview questions guide covers images, layers and BuildKit. On a node, use crictl rather than docker.
Kubernetes in 2026: versions and new features
8. How does the Kubernetes release cycle and version support work?
Answer: Kubernetes ships roughly three minor releases a year and maintains the three most recent minor lines, each with about a year of patch support. As of October 2026 the newest release is 1.37 (late August 2026), and 1.37, 1.36 and 1.35 are supported. Managed services publish their own support calendars.
Version skew rules: upgrade the control plane one minor version at a time; kubelets may be up to three minor versions older than the API server but never newer; kubectl is supported within one minor version. Features move from alpha (off by default) to beta and stable (GA), and production clusters normally rely on beta-by-default and GA features only.
9. Which recent GA features should a Kubernetes engineer know about?
Answer: A short list that comes up in 2026 interviews, with the release where each became stable per the Kubernetes documentation:
| Feature | Status | Why it matters |
|---|---|---|
| ValidatingAdmissionPolicy | Stable since 1.30 | In-process CEL policies without a webhook |
| Native sidecar containers | Stable since 1.33 | Correct start and shutdown ordering for helpers |
| Dynamic Resource Allocation | GA in 1.34 | Attribute-based requests for GPUs and other devices |
| In-place Pod resize | Stable since 1.35 | Change CPU and memory of a running Pod |
| Image volumes | Stable since 1.36 | Mount an OCI image or artifact read-only |
| MutatingAdmissionPolicy | Stable since 1.36 | CEL-based mutation |
| HPA configurable tolerance | Stable since 1.37 | Per-HPA scale-up and scale-down tolerance |
Also know that the Ingress API is frozen in favour of Gateway API, the community Ingress NGINX controller was retired after March 2026 (Q22), and HPA scale to zero on object and external metrics is beta and on by default in 1.37.
Workloads: Deployments, StatefulSets, DaemonSets and Jobs
10. How do Deployments, ReplicaSets and Pods relate, and how do you scale an application?
Answer: A Deployment manages ReplicaSets, and each ReplicaSet keeps a number of identical Pods running. Changing the Pod template creates a new ReplicaSet and shifts Pods to it; old ReplicaSets are kept at zero replicas as rollback history (ten by default, revisionHistoryLimit). Scale with kubectl scale, by changing replicas in git, or with an HPA (Q38). If an HPA manages the Deployment, remove replicas from the manifest your GitOps tool applies, or the two will fight.
11. How do rolling updates work, and what do maxSurge and maxUnavailable control?
Answer: The default RollingUpdate strategy replaces Pods gradually. maxSurge is how many Pods above the desired count may exist; maxUnavailable is how many below it are allowed; both default to 25 percent. New Pods count only once Ready, so readiness probes make rolling updates safe. Recreate kills all old Pods first, causing downtime, and is used when two versions cannot run together.
For a small critical service, use maxUnavailable: 0 with maxSurge: 1, add minReadySeconds, and rely on progressDeadlineSeconds (600 seconds by default) to mark a stuck rollout as failed.
12. How do you roll back a Deployment, and what are the limits of rollback?
Answer: kubectl rollout history lists revisions and kubectl rollout undo (optionally --to-revision=N) copies an old ReplicaSet's template back. Under GitOps, revert the commit instead, or the controller reapplies the bad version. Rollback restores the Pod template only, not ConfigMaps, Secrets or database schemas. If a release ran a destructive migration, old code may not work against the new schema, which is why teams use backward-compatible (expand, migrate, contract) migrations. helm rollback restores all of a release's manifests but still cannot undo data changes.
13. What is a StatefulSet, and when do you use it instead of a Deployment?
Answer: A StatefulSet gives each Pod a stable identity: an ordinal name (kafka-0), a stable DNS name through a headless Service, and its own PVC from volumeClaimTemplates that follows it across reschedules. Pods are created and updated in order by default, and claims are kept when Pods are deleted unless a retention policy says otherwise. Use it for clustered stateful systems such as databases, Kafka or Elasticsearch; use a Deployment for stateless services, even ones that talk to a database. Production databases on Kubernetes usually run through an operator (Q51) that adds failover, backups and upgrades.
14. What is a DaemonSet, and how do you run it on only some nodes?
Answer: A DaemonSet runs one Pod on every eligible node and adds one when a node joins: log collectors, metrics exporters, CNI and CSI node plugins, security agents. Limit it with a nodeSelector or node affinity (for example gpu=true), and add tolerations to run on tainted nodes such as GPU pools. DaemonSets support rolling updates with maxUnavailable, which matters for agents the node depends on, such as the CNI.
15. How do Jobs and CronJobs work, and what settings matter in production?
Answer: A Job runs Pods until a set number succeed; a CronJob creates Jobs on a schedule. Settings that matter:
backoffLimit(6 by default),activeDeadlineSeconds, andpodFailurePolicyto fail fast on non-retryable exit codes or ignore node drains.completions,parallelismandcompletionMode: Indexedfor sharded work.ttlSecondsAfterFinishedfor clean-up.- CronJob
concurrencyPolicy(Allow, Forbid, Replace),startingDeadlineSecondsandtimeZone.
Interview tip: Job Pods must be idempotent, because a Pod can be retried or even run twice after a node failure.
16. What are init containers and native sidecar containers?
Answer: Init containers run to completion, in order, before app containers start: waiting for a dependency, fetching config. A native sidecar is an init container with restartPolicy: Always: it starts before the app, keeps running beside it, restarts if it exits and stops after the app on shutdown. It has been stable since 1.33. It fixes two old bugs of sidecars-as-ordinary-containers: Jobs that never completed because a proxy kept running, and apps starting before their proxy was ready.
17. How do you implement blue-green and canary deployments on Kubernetes?
Answer: Kubernetes itself only does rolling updates, so progressive delivery comes from routing. Blue-green: run two Deployments and switch the Service selector or route from blue to green in one step; rollback is switching back. Canary: send a small share of traffic to the new version, watch metrics, then increase. Replica-ratio canaries are crude; weighted routing through Gateway API HTTPRoutes or a service mesh is precise. Argo Rollouts and Flagger automate the steps and abort automatically when Prometheus analysis shows higher errors or latency. The hard part is choosing the metrics that define "worse".
18. How does graceful termination work, and what is a PodDisruptionBudget?
Answer: On deletion, a Pod is removed from Service endpoints while, in parallel, the kubelet runs any preStop hook and sends SIGTERM, then SIGKILL after terminationGracePeriodSeconds (30 by default). Endpoint removal propagates asynchronously, so a Pod can receive requests for a few seconds after SIGTERM. The standard fix is a short preStop sleep plus an app that drains in-flight requests before exiting.
A PodDisruptionBudget limits voluntary disruptions such as node drains by setting minAvailable or maxUnavailable. It does not protect against node crashes, and a PDB that allows zero disruptions blocks drains forever, a common cause of stuck upgrades.
Services, Ingress, Gateway API and networking
19. What is the Kubernetes networking model, and what does a CNI plugin do?
Answer: Every Pod gets its own IP, Pods reach each other without NAT, and node agents reach all Pods on their node. Kubernetes defines these rules; a CNI plugin implements them, creating each Pod's interface, assigning its IP and setting routes. Examples are Calico, Cilium, Flannel and the cloud CNIs (Amazon VPC CNI, Azure CNI, GKE's dataplane). The CNI choice also decides whether NetworkPolicies are enforced and whether Pods use VPC-routable IPs, which affects IP planning in large clusters.
20. What are the Service types, and when do you use each?
Answer: A Service gives a stable virtual IP and DNS name to a changing set of Pods selected by labels.
| Type | What it does | Typical use |
|---|---|---|
| ClusterIP (default) | Internal virtual IP | Service-to-service traffic |
| NodePort | Opens a port on every node | Behind an external load balancer, labs, on-premises |
| LoadBalancer | Provisions a cloud load balancer | Exposing a gateway or ingress controller |
| ExternalName | DNS CNAME, no proxying | Pointing at a managed database endpoint |
Headless (clusterIP: None) | DNS returns Pod IPs | StatefulSets, client-side load balancing |
Interview tip: One LoadBalancer per microservice gets expensive; the usual pattern is one load balancer in front of a Gateway or ingress controller that routes to many ClusterIP Services.
21. How does a Service actually route traffic to Pods?
Answer: The EndpointSlice controller records the IPs of Ready Pods matching each Service's selector. kube-proxy on every node watches Services and EndpointSlices and programs packet rules (iptables, IPVS or the newer nftables mode) that translate the Service's virtual IP to a Pod IP. Some CNIs, such as Cilium, replace kube-proxy with eBPF. The virtual IP is not bound to an interface, which is why you cannot ping a ClusterIP but can connect to its port. Also know sessionAffinity: ClientIP and externalTrafficPolicy: Local, which preserves client source IPs but only uses nodes with a local Pod.
22. What is Ingress, and what is its status in 2026?
Answer: Ingress defines HTTP and HTTPS routing (hosts, paths, TLS) from outside the cluster to Services, implemented by an ingress controller. It is GA and not being removed, but the Kubernetes documentation states the API is frozen and recommends Gateway API instead. Much real behaviour lived in controller-specific annotations, which made configurations non-portable.
Separately, the community Ingress NGINX controller was retired: its limited maintenance ended in March 2026, with no further releases or security fixes. Existing installations keep working, but teams still on it should migrate to a Gateway API implementation or another maintained controller. Expect to be asked how you would plan that migration.
23. How is Gateway API different from Ingress?
Answer: Gateway API is the successor to Ingress, installed as CRDs and implemented by many controllers. Its stable core kinds are GatewayClass, Gateway, HTTPRoute and GRPCRoute. Differences:
- Role-oriented: platform teams own GatewayClass and Gateway (listeners, TLS, addresses); app teams own Routes in their namespaces and attach them to a shared Gateway, with cross-namespace references controlled explicitly.
- Expressive routing in the spec: header matching, weighted backends, redirects, rewrites and mirroring without vendor annotations.
- More protocols: gRPC as stable, with TCP, UDP and TLS routes in the experimental channel.
- Portability backed by conformance tests.
Interview tip: For migration, run a Gateway alongside the existing ingress, convert routes namespace by namespace (ingress2gateway helps), and move DNS gradually.
24. How does DNS and service discovery work inside a cluster?
Answer: CoreDNS runs in kube-system behind a Service whose IP the kubelet writes into each Pod's /etc/resolv.conf. Service payments in namespace prod resolves as payments.prod.svc.cluster.local, or just payments from the same namespace thanks to search domains. The detail that causes latency is ndots:5: names with fewer than five dots are tried against each search domain first, so one external lookup can produce several failed queries. Fully qualified names with a trailing dot, tuned dnsConfig or NodeLocal DNSCache reduce the load.
25. What is a NetworkPolicy, and how do you use it to secure Pod traffic?
Answer: By default every Pod can reach every other Pod. A NetworkPolicy selects Pods by label and allows ingress and egress by Pod selector, namespace selector, IP block and port. Policies are additive allow-lists: once a policy selects a Pod for a direction, everything else in that direction is denied. They are enforced only if the CNI supports them.
A practical pattern: default-deny ingress and egress per application namespace, explicit allows (frontend to API on 8080, API to database on 5432), and an egress allow to CoreDNS on port 53, which people most often forget.
26. What does a service mesh add, and when is it worth it?
Answer: A mesh such as Istio or Linkerd adds a data plane, either sidecar proxies or sidecarless "ambient" modes, for service-to-service traffic: mutual TLS with automatic certificate rotation, identity-based authorisation, retries, timeouts, traffic splitting and uniform metrics and traces without code changes. It is worth it with many services, a zero-trust or compliance need for authenticated internal traffic, or fine-grained traffic control. The costs are complexity, extra latency and resources, and another component to upgrade. For a handful of services, NetworkPolicies and Gateway API are often enough.
Configuration, Secrets and storage
27. How do ConfigMaps work, and how do you inject configuration into Pods?
Answer: A ConfigMap holds non-sensitive key-value or file data, consumed as environment variables (configMapKeyRef, envFrom) or as files in a volume. Environment variables are read once at container start and never update; mounted files update after a short delay, except with subPath, which never updates, and the app must still re-read them. Many teams therefore treat config as immutable: put a hash of the ConfigMap in a Pod template annotation so a change triggers a rolling update, or create a new immutable: true ConfigMap per version.
28. Are Kubernetes Secrets secure? How should you handle sensitive data?
Answer: Not by default. Values are base64-encoded, not encrypted, and stored in etcd; anyone who can read Secrets in a namespace, or create a Pod there that mounts them, can read them. Harden by enabling encryption at rest with a KMS provider, restricting get, list and watch on Secrets (list returns values too), mounting Secrets as files rather than environment variables, keeping the source of truth in a secrets manager (Q29), never committing plain Secret manifests, and preferring short-lived workload identity over static keys.
29. How do you integrate Kubernetes with an external secrets manager and cloud identity?
Answer: The External Secrets Operator syncs values from AWS Secrets Manager, Azure Key Vault, Google Secret Manager or Vault into Kubernetes Secrets. The Secrets Store CSI Driver mounts them directly as a volume. Sealed Secrets or SOPS store encrypted secrets in git for GitOps. For cloud access, use workload identity instead of access keys: a service account maps to a cloud identity (EKS Pod Identity or IAM roles for service accounts, Microsoft Entra Workload ID on AKS, Workload Identity Federation on GKE) and Pods get short-lived tokens. The secrets operator itself can authenticate the same way.
30. Explain PersistentVolumes, PersistentVolumeClaims and StorageClasses.
Answer: A PersistentVolume represents real storage (a cloud disk, an NFS export). A PersistentVolumeClaim is a request for a size and access mode, bound to a matching volume and mounted by the Pod. A StorageClass describes a storage type (provisioner, disk type, encryption, reclaim policy) for dynamic provisioning.
- Static provisioning: admins pre-create PVs. Dynamic: the CSI driver creates disks on demand, the norm on cloud.
- Access modes: ReadWriteOnce (one node), ReadWriteOncePod (one Pod), ReadOnlyMany, ReadWriteMany (needs shared storage).
- Reclaim policy: Delete removes the disk with the claim; Retain keeps it. Use Retain for data you cannot lose.
Use volumeBindingMode: WaitForFirstConsumer for zonal disks so the disk is created where the Pod is scheduled.
31. What is CSI, and what challenges come with persistent storage on Kubernetes?
Answer: The Container Storage Interface lets vendors ship storage drivers outside Kubernetes: a controller part creates, attaches, snapshots and expands volumes, and a node DaemonSet mounts them. Challenges to name from experience: zonal disks pin Pods to one zone; a disk stuck attached to a failed node blocks the replacement Pod (Q63); IOPS depends on disk type or size; backups need application consistency, not just snapshots; and ReadWriteMany is slower and costlier. Many enterprises keep core databases on a managed service and run caches, queues and middleware in the cluster.
If you want to practise these topics on real clusters rather than read about them, Cloudsoft's Kubernetes training in Hyderabad works through workloads, storage, networking and troubleshooting labs, in our Ameerpet classroom or live online.
Scheduling, resources and QoS
32. How does the kube-scheduler decide where a Pod runs?
Answer: Two phases. Filtering removes nodes that cannot run the Pod: insufficient allocatable CPU or memory for its requests, non-matching selectors or required affinity, untolerated taints, a volume in another zone. Scoring ranks the rest using plugins such as resource balance, preferred affinity, topology spread and image locality, and the top node gets the binding. If nothing passes, the Pod stays Pending with a FailedScheduling event listing reasons, and preemption may be tried (Q36). The scheduler looks only at requests, never actual usage, so an idle node can still be "full".
33. Compare nodeSelector, node affinity and Pod affinity or anti-affinity.
Answer: nodeSelector requires exact node labels. Node affinity adds operators (In, NotIn, Exists) and two flavours: required (hard) and preferred (weighted). Pod affinity and anti-affinity place Pods relative to other Pods within a topology such as node or zone: co-locate a cache with its app, or keep replicas apart. "IgnoredDuringExecution" means later label changes do not evict running Pods. A classic trap is required node-level anti-affinity with five replicas and four nodes: the fifth stays Pending. Preferred anti-affinity or topology spread is usually safer.
34. How do taints and tolerations work?
Answer: A taint on a node repels Pods; a matching toleration lets a Pod ignore it. Effects are NoSchedule, PreferNoSchedule and NoExecute, which also evicts running Pods without a toleration, optionally after tolerationSeconds. Uses include dedicated GPU or high-memory pools and keeping apps off control plane nodes. The node lifecycle controller adds not-ready and unreachable NoExecute taints, which Pods tolerate for 300 seconds by default before eviction.
Interview tip: A toleration allows a Pod onto a tainted node but does not attract it. Dedicating nodes needs a taint plus node affinity.
35. What are topology spread constraints, and why use them?
Answer: They spread matching Pods evenly across domains such as zones (topology.kubernetes.io/zone) or nodes. maxSkew sets the allowed imbalance and whenUnsatisfiable is DoNotSchedule (hard) or ScheduleAnyway (soft). They are more flexible than anti-affinity because several Pods may share a domain while staying balanced.
Real-world example: Consider a retailer whose six checkout replicas all landed in one zone after a scale-up; a zone outage during a sale took checkout down. A zone spread constraint with maxSkew: 1 would have kept two per zone. Spreading applies only at placement time; the descheduler project rebalances running Pods.
36. What are PriorityClasses and preemption?
Answer: A PriorityClass gives Pods an integer priority. When a high-priority Pod cannot be scheduled, the scheduler can evict lower-priority Pods to make room, and priority also affects eviction order under node pressure. Typical tiers: system-critical (the built-in system-cluster-critical and system-node-critical), production, batch and low-priority experiments. preemptionPolicy: Never lets a class queue ahead without evicting. Restrict who can use high classes, for example with ResourceQuota scoped by PriorityClass, or every team will mark itself critical. Preemption tries to respect PodDisruptionBudgets but can still violate them if there is no other option.
37. Explain resource requests, limits and QoS classes.
Answer: A request is what the scheduler reserves; a limit is the maximum a container may use. CPU is compressible: over the limit, the container is throttled, which shows as latency. Memory is not: over the limit, the kernel kills the container and reports OOMKilled (Q55).
Kubernetes derives one of three QoS classes. Guaranteed applies when every container sets CPU and memory requests equal to limits; Burstable when some requests or limits are set; BestEffort when none are. Under memory pressure the kubelet evicts BestEffort Pods first, then Burstable Pods above their requests, and Guaranteed Pods last. Check with kubectl get pod NAME -o jsonpath='{.status.qosClass}'.
A common policy is memory request equal to limit, and a CPU request with no CPU limit to avoid throttling. Use a LimitRange for namespace defaults and a ResourceQuota to cap a team's total.
Autoscaling and probes
38. How does the Horizontal Pod Autoscaler work?
Answer: Every 15 seconds by default, the HPA reads metrics for a workload's Pods and computes desiredReplicas = ceil(currentReplicas × currentMetricValue / desiredMetricValue) within minReplicas and maxReplicas. Metrics can be resource utilisation (relative to requests, from metrics-server), custom Pod metrics, object metrics or external metrics such as queue length through an adapter or KEDA.
Depth points: no requests means no CPU-based scaling; a default tolerance of 0.1 (ten percent) prevents flapping, and since 1.37 tolerance is configurable per HPA; the behavior field sets stabilisation windows and rate limits; and scale to zero for object and external metrics is beta and on by default in 1.37. For request-driven services, requests per second or queue depth often scale better than CPU.
39. What is the Vertical Pod Autoscaler, and how does in-place Pod resize change things?
Answer: The VPA, a SIG Autoscaling project, recommends or sets CPU and memory requests from observed usage. Applying a change used to mean evicting and recreating the Pod, which made VPA disruptive. In-place Pod resize, stable since 1.35, lets requests and limits of a running container change through the Pod's resize subresource, often without a restart; each container's resizePolicy says whether a resource change needs one, and conditions such as PodResizePending show progress. Never run VPA and HPA on the same metric; a common split is HPA on traffic and VPA for memory sizing or recommendations only.
40. Compare the Cluster Autoscaler and Karpenter.
Answer: Both add nodes for Pending Pods and remove underused ones, with different models:
| Aspect | Cluster Autoscaler | Karpenter |
|---|---|---|
| Scaling unit | Predefined node groups | Individual nodes from Pod requirements |
| Instance choice | Fixed per node group | Picks from flexible instance types and capacity types |
| Consolidation | Removes underused nodes | Actively replaces nodes with cheaper or fewer ones |
| Providers | Many clouds and on-premises | Strongest on AWS; Azure support exists, check others |
Both react to requests on Pending Pods, so accurate requests matter more than any autoscaler setting. Protect Pods that must not move during consolidation with PDBs and do-not-disrupt annotations.
41. Explain liveness, readiness and startup probes.
Answer: Readiness controls whether a Pod receives Service traffic; failing it removes the Pod from endpoints without a restart. Liveness detects a stuck container; failing it restarts the container. Startup holds off liveness and readiness until a slow app has started. Probes can be HTTP, TCP, gRPC or exec, tuned with delays, periods, timeouts and thresholds.
Mistakes interviewers look for: a liveness probe that checks the database, so a database blip restarts every Pod at once; a liveness timeout so tight it kills Pods under load; and no startup probe on a slow JVM or model-loading app, causing restart loops (Q53). Keep liveness cheap and local.
Security, RBAC and multi-tenancy
42. How does RBAC work in Kubernetes, and how do you implement least privilege?
Answer: RBAC grants verbs (get, list, watch, create, update, patch, delete) on resources. A Role applies in one namespace, a ClusterRole cluster-wide or as a reusable template, and RoleBindings or ClusterRoleBindings attach them to users, groups (from OIDC or cloud IAM) and ServiceAccounts. Permissions are additive, with no deny rules.
Least privilege: bind groups, not people; give teams namespace-scoped roles; give each workload its own ServiceAccount and disable token automounting where unused; avoid cluster-admin and wildcards; treat create pods, escalate, bind and impersonate as sensitive. Verify with kubectl auth can-i --list --as=system:serviceaccount:ns:sa.
43. What are Pod Security Standards and Pod Security Admission?
Answer: Pod Security Standards define privileged (unrestricted), baseline (blocks privileged containers, host namespaces, hostPath) and restricted (also non-root, dropped capabilities, seccomp, no privilege escalation). Pod Security Admission, stable since 1.25, enforces them per namespace with labels such as pod-security.kubernetes.io/enforce: restricted in three modes: enforce, audit and warn. It replaced PodSecurityPolicy, removed in 1.25. Roll out with warn and audit first, fix offenders, then enforce. Use admission policies (Q44) for rules beyond the three levels.
44. How do admission controllers and admission policies work?
Answer: Admission runs after authentication and authorisation, before storage. Mutating admission can change objects; validating admission can reject them. Ways to add policy:
- ValidatingAdmissionPolicy (stable since 1.30): CEL rules inside the API server, no webhook to run; for example, only images from the company registry.
- MutatingAdmissionPolicy (stable since 1.36): the CEL counterpart for mutation.
- Webhooks and engines built on them, such as Kyverno and OPA Gatekeeper, for policy libraries and reporting.
Warning: a webhook with failurePolicy: Fail and a dead backend can block every create in the cluster. Scope webhooks with selectors and exclude kube-system.
45. How do you secure a Kubernetes cluster end to end?
Answer: In layers:
- Control plane: private or restricted API endpoint, SSO authentication, audit logs, Secrets encrypted at rest, rotated certificates (kubeadm needs
kubeadm certsrenewal or regular upgrades). - Access: least-privilege RBAC (Q42) and workload identity (Q29).
- Workloads: Pod Security Admission at restricted, non-root users, read-only root filesystems.
- Network: default-deny NetworkPolicies, mTLS where required, controlled egress.
- Supply chain: minimal images, scanning, signing (for example Sigstore cosign) verified at admission, digests and SBOMs.
- Nodes: patched node images, no default SSH, runtime detection such as Falco.
The CIS Kubernetes Benchmark (with kube-bench) structures an audit; the DevSecOps interview questions go deeper into pipeline gates.
46. How do you design multi-tenancy on Kubernetes, and when do you need multiple clusters?
Answer: Soft multi-tenancy for trusted internal teams: a namespace per team or environment with RBAC, ResourceQuota, LimitRange, default-deny NetworkPolicies, Pod Security Admission and separate node pools for sensitive workloads; virtual clusters such as vCluster add autonomy, including per-tenant CRDs. Hard isolation for untrusted tenants or regulated data: separate clusters, or dedicated nodes plus sandboxed runtimes such as gVisor or Kata Containers, because the kernel is shared. Multiple clusters are justified by blast radius, regulation, region and upgrade independence, at the cost of fleet management with GitOps across clusters, consistent policy and central observability.
Real-world example: Consider a GCC IT team in Hyderabad serving several business units: shared non-production clusters with namespace tenancy and strict quotas, and separate production clusters per regulated business line, managed from one GitOps repository.
Helm, GitOps, upgrades and observability
47. What is Helm, how are charts structured, and how does it compare with Kustomize?
Answer: Helm is a Kubernetes package manager. A chart has Chart.yaml (name, version, appVersion, dependencies), values.yaml, a templates/ directory of Go templates with helpers in _helpers.tpl, and optionally a values schema, tests and CRDs. helm upgrade --install renders it into a release; each upgrade adds a revision you can helm rollback to. Charts are shared through repositories or OCI registries. Kustomize uses plain YAML bases with per-environment overlays, built into kubectl (kubectl apply -k). Helm suits distributable software with many options; Kustomize suits your own apps with small environment differences. Teams often render a vendor chart with Helm and patch it with Kustomize.
Interview tip: Mention semantic chart versions, a values schema, pinned dependencies, and helm lint plus helm template in CI.
48. What is GitOps, and how do Argo CD and Flux implement it?
Answer: GitOps keeps desired cluster state in git, and an in-cluster agent pulls and reconciles it continuously. Changes go through pull requests, history is the audit trail, rollback is a revert, and CI no longer needs cluster credentials. Argo CD models Applications (source path, chart or overlay plus destination), with a UI for sync and health, automated sync with self-heal and pruning, sync waves for ordering and ApplicationSets for many clusters. Flux is a set of CRD-driven controllers (source, Kustomize, Helm, notification, image automation) without a built-in UI. Both are CNCF graduated. Typically CI builds, scans and pushes the image, then updates the tag in the config repository. The advanced scenario-based Kubernetes interview questions cover drift control at platform scale.
49. How do you upgrade a Kubernetes cluster with minimal downtime?
Answer:
- Prepare: read release notes and the deprecation guide; scan manifests, charts and live objects for removed APIs (pluto, kubent, deprecated-API metrics); check add-ons such as CNI, CSI, gateway, mesh and autoscaler.
- Rehearse on a non-production cluster at the same versions.
- Control plane first, one minor version at a time (
kubeadm upgrade planandapply, or the managed service's upgrade). - Nodes: cordon and drain in batches respecting PDBs, or create a new node pool and migrate (blue-green node pools), which gives an easy rollback.
- Verify workloads and dashboards before the next step.
Downtime usually comes from workloads: single replicas, missing or blocking PDBs, and apps without graceful shutdown (Q18). Large fleets sometimes build a new cluster and shift traffic instead.
50. How do you monitor and log a Kubernetes cluster?
Answer:
- Metrics: metrics-server for
kubectl topand HPA; Prometheus scraping kubelet and cAdvisor, kube-state-metrics (desired versus available replicas, restarts, Pending Pods), node exporter and the control plane; Grafana and Alertmanager. kube-prometheus-stack is a common start. - Logs: stdout and stderr shipped by a DaemonSet agent (Fluent Bit, OpenTelemetry Collector, Vector) to Loki, Elasticsearch or cloud logging, with Kubernetes metadata.
- Traces: OpenTelemetry instrumentation and the Collector.
- Events and audit: export events, which expire quickly; enable audit logs.
Alert on user-facing symptoms (errors, latency, saturation) plus a few cluster signals: NotReady nodes, crash loops, long-Pending Pods, filling volumes and certificate expiry. See the Prometheus and Grafana interview questions for PromQL and alert design.
51. What are CRDs and Operators?
Answer: A CustomResourceDefinition adds a new API type, such as Certificate or PostgresCluster, with a schema, versions and validation. A CRD only stores data; an Operator is a controller that reconciles real systems to those resources, encoding operational knowledge such as provisioning, failover, backups and ordered upgrades. Examples are cert-manager, Prometheus Operator, Strimzi and CloudNativePG, usually built with Kubebuilder or Operator SDK. Costs: operators run with broad permissions, CRD version changes need conversion, and deleting a CRD deletes all its resources. Check maturity before trusting one with production data.
AI workloads on Kubernetes
52. How does Kubernetes support AI and GPU workloads?
Answer: GPUs are extended resources advertised by a vendor device plugin (for example nvidia.com/gpu), requested in resource limits and allocated as whole devices. Dynamic Resource Allocation, GA since 1.34, adds attribute-based requests through ResourceClaims, so workloads can ask for a GPU by model or memory and share devices explicitly. GPU pools are usually tainted and scaled on demand by the cluster autoscaler or Karpenter, and image volumes (stable since 1.36) are one way to mount model weights packaged as OCI artifacts. AI serving also breaks familiar assumptions: slow starts, CPU as the wrong scaling signal, long streaming responses and expensive idle capacity. For GPU sharing, KServe, vLLM and Kueue, see the Kubernetes for AI interview questions, and for running AI applications on EKS, AKS and GKE, read Kubernetes for AI applications.
Real-world troubleshooting scenarios
53. A Pod is in CrashLoopBackOff. How do you debug it?
Answer: CrashLoopBackOff means the container keeps exiting and the kubelet restarts it with exponential back-off (capped at five minutes by default). Find out why it exits.
What I would check:
kubectl describe pod: last state and exit code. Code 1 or another app code is an app error; 137 is SIGKILL, often OOMKilled (Q55); a failing liveness probe shows in events.kubectl logs POD --previousfor the crashed container's output.- Config: missing environment variables, ConfigMap or Secret keys, wrong command, bad mount path, or an unreachable dependency at startup.
- Probes: a liveness probe firing before a slow app is ready; add a startup probe.
- If logs are empty, use
kubectl debugor temporarily override the command to inspect the container.
Production consideration: If a new release caused it, roll back first. Set terminationMessagePolicy: FallbackToLogsOnError so the exit reason appears in describe.
54. New Pods are stuck in Pending. What do you do?
Answer: Pending means the Pod is not scheduled yet, or is waiting on a volume. The scheduler explains why in events.
What I would check:
kubectl describe podevents, for example "0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had untolerated taint".- Resources: requests versus node allocatable; oversized requests; the node autoscaler at its maximum or unable to get the instance type.
- Taints, selectors and affinity: label typos, required anti-affinity with too few nodes, missing tolerations.
- Volumes: an unbound PVC, a missing StorageClass, or a zonal disk with no node in its zone.
- Quota: a ResourceQuota rejection stops Pod creation, so check ReplicaSet events too.
Production consideration: Alert on Pods Pending for more than a few minutes, and keep headroom or low-priority placeholder Pods so urgent scale-ups do not wait for new nodes.
55. A container keeps getting OOMKilled. How do you investigate and fix it?
Answer: OOMKilled (exit code 137) means the container exceeded its memory limit. That differs from a Pod evicted because the node ran short of memory, so distinguish the two first.
What I would check:
kubectl describe podforReason: OOMKilledversus anEvictedstatus and node pressure events.- Container working-set memory over time against the limit: a steady climb suggests a leak, a spike suggests a large payload or batch.
- Runtime settings: a JVM or Node.js heap sized above the container limit, with no room for threads, buffers and native memory.
- Recent changes: a new release, bigger payloads, more concurrency per Pod.
Production consideration: Raise the limit only if higher usage is legitimate; otherwise you hide a leak. Set memory requests near real usage, use VPA recommendations, and scale out if memory grows with concurrency.
56. Pods cannot resolve service names, or DNS is intermittently slow. How do you troubleshoot it?
Answer: Work from the Pod outward to CoreDNS and then upstream.
What I would check:
- From a debug Pod:
nslookupthe short name, the fullsvc.cluster.localname and an external name; inspect/etc/resolv.conf. - CoreDNS: Pods Ready, logs, the
kube-dnsService having endpoints, recent Corefile edits. - NetworkPolicies: default-deny egress without an allow for port 53 breaks DNS for the namespace.
- Load: CoreDNS throttled or under-replicated;
ndots:5multiplying external queries (Q24). - Upstream resolvers if only external names fail.
Production consideration: Scale CoreDNS with cluster size, run NodeLocal DNSCache on large clusters and monitor DNS latency. Intermittent five-second delays often mean dropped UDP packets from conntrack races, which node-local caching also helps.
57. A Deployment rollout is stuck and users see errors. How do you handle it and roll back?
Answer: Stabilise first, then diagnose. If the new version serves errors, roll back now; if it simply cannot become Ready, the rolling update pauses with old Pods still serving.
What I would check:
kubectl rollout statusand theProgressingcondition;ProgressDeadlineExceededconfirms it is stuck.- The new ReplicaSet's Pods: crash-looping, failing readiness, Pending or failing to pull, each a scenario in this section.
- Roll back with
kubectl rollout undo, a git revert under Argo CD or Flux, orhelm rollback. - What rollback does not cover: ConfigMaps, Secrets, CRDs and migrations shipped with the release.
- Recovery on error-rate and latency dashboards, not just Pod status.
Production consideration: Prevent repeats with honest readiness probes, maxUnavailable: 0, an automated canary step (Q17) and backward-compatible migrations.
58. A node shows NotReady. What do you do?
Answer: The kubelet has stopped reporting healthy status, because the node is unhealthy or cannot reach the control plane. Its Pods are evicted after the NoExecute toleration period (300 seconds by default).
What I would check:
kubectl describe node: conditions (MemoryPressure, DiskPressure, PIDPressure, Ready), last heartbeat and events.- On the node:
systemctl status kubelet,journalctl -u kubelet, and the runtime (systemctl status containerd,crictl ps). - Resources: a full disk from logs, images or emptyDir; memory or PID exhaustion.
- Network to the API server: security groups, routes, proxies; expired kubelet certificates.
- The CNI agent on that node; if it is down, the node reports network not ready.
Production consideration: On cloud, cordon, drain and replace rather than nurse the node, then investigate from its logs. Use node auto-repair where available, and treat several nodes going NotReady together as a shared cause, such as networking or a bad node image.
59. Pods show ImagePullBackOff or ErrImagePull. How do you fix it?
Answer: The kubelet cannot pull the image, and the event message usually names the cause.
What I would check:
- The image reference: typo, a tag never pushed, or the wrong architecture.
- Authentication: a missing or expired
imagePullSecret, or node IAM permissions for ECR, ACR or Artifact Registry. - Network: private subnets without NAT or a private endpoint to the registry; a corporate proxy.
- Rate limits on public registries.
Production consideration: Mirror third-party images into your own registry, deploy by digest, and have CI verify the image exists before the manifest change merges.
60. A Service returns 503 errors or connections time out, but the Pods look Running. What is wrong?
Answer: Running is not Ready, and a Service routes only to Ready Pods matching its selector. Most cases are a selector or port mismatch.
What I would check:
kubectl get endpointslices -l kubernetes.io/service-name=payments: empty means no matching Ready Pods.- The Service selector against Pod labels, character by character.
- Ports:
targetPortmust match the container port, and the app must listen on0.0.0.0, not only localhost. - Hop by hop:
kubectl port-forwardto a Pod, then curl the Service from a debug Pod. - Upstream: Gateway or Ingress routes, load balancer health checks, NetworkPolicies blocking the gateway namespace.
Production consideration: Standardise labels and named ports in a shared Helm library chart so teams do not reinvent them.
61. Every deployment causes a short spike of 502 or 503 errors. How do you get zero-downtime deploys?
Answer: Old Pods are being killed while load balancers still send them traffic, or new Pods get traffic before they can serve it.
What I would check:
- Whether the app drains in-flight requests on SIGTERM; many frameworks exit immediately.
- A short
preStopsleep, and a grace period longer than the sleep plus the longest request. - Readiness that reflects real readiness, plus
minReadySeconds. maxUnavailable: 0so capacity never drops.- Load balancer deregistration delay and connection draining in the gateway or ingress controller.
Production consideration: Run a load generator during a staging deploy and require zero errors. The same fixes make node drains during upgrades invisible.
62. The HPA is not scaling the Deployment even though traffic is high. Why?
Answer: Read what the HPA reports before tuning anything.
What I would check:
kubectl describe hpa:AbleToScale,ScalingActiveandScalingLimitedconditions;<unknown>targets mean missing metrics.- The metrics pipeline: metrics-server or the adapter returning data (
kubectl top pods). - Requests: missing requests break utilisation; oversized ones make it look low.
- The metric: the bottleneck may be a database or thread pool, so CPU stays flat while latency climbs; scale on requests per second or queue depth.
- Limits: at
maxReplicas, conservativebehavior, or new Pods Pending (Q54).
Production consideration: Load-test the scaling path itself and set minReplicas to absorb bursts while new Pods and nodes start.
63. After a node failure, a StatefulSet Pod is stuck with a Multi-Attach or volume error. How do you recover?
Answer: A ReadWriteOnce disk attaches to one node at a time. After an abrupt node failure it may still be recorded as attached there, so the replacement Pod cannot mount it. Kubernetes is deliberately cautious, because forcing it could let two Pods write to one disk.
What I would check:
- Pod events for
Multi-Attach error, and VolumeAttachment objects for the volume. - Whether the old node is truly gone or just partitioned; shut it down before forcing anything.
- For a node confirmed shut down, the
node.kubernetes.io/out-of-servicetaint (non-graceful node shutdown) lets volumes detach and Pods move. - That the replacement Pod can schedule in the disk's zone.
Production consideration: Replicate stateful systems across zones at the application level, and keep this recovery in a runbook.
64. After upgrading the cluster, the CI pipeline fails to apply manifests with "no matches for kind" errors. What happened?
Answer: The manifests use an API version removed in the new release. Stored objects were already migrated, so running workloads are fine, but old YAML no longer applies.
What I would check:
- The kind and apiVersion in the error, against the deprecated API migration guide.
- Every source: app repositories, vendored Helm charts, Kustomize bases, GitOps-rendered output.
- Helm release metadata with removed APIs, which can block
helm upgrade; the helm-mapkubeapis plugin fixes it. - Operators and controllers that need versions compatible with the new release.
Production consideration: Add a CI scan for APIs removed in the next two releases and make it an upgrade gate (Q49). This is a process failure more than a technical one.
65. Design a production Kubernetes platform for a bank's customer-facing microservices.
Answer: Consider a bank moving its mobile banking APIs to managed Kubernetes. Start from requirements (availability, data residency, audit, separation of duties, change control), then design in layers.
users -> WAF/CDN -> cloud LB -> Gateway (Gateway API)
|
prod cluster (3 zones, private API endpoint)
- system pool | app pools | sensitive pool (tainted)
- namespaces per domain: quotas, PSA restricted,
default-deny NetworkPolicies, mTLS mesh
- workload identity -> secrets manager, KMS
|
managed DB / cache (private endpoints)
GitOps (Argo CD) <- config repo <- CI (scan, sign)
observability: metrics, logs, traces, audit
- Clusters: separate production and non-production, private API, three zones, and a DR cluster or a tested rebuild-from-git plan.
- Workloads: three or more replicas per critical service, zone spread, PDBs, requests everywhere, HPA on traffic, graceful shutdown.
- Security: SSO-backed group RBAC, no standing cluster-admin, restricted Pod Security, signed images from approved registries, mTLS, secrets via workload identity, audit logs to the SIEM.
- Delivery: GitOps with approvals as the change record, automated canaries, a regular upgrade cadence with a rehearsal cluster.
- Operations: SLO-based alerting and runbooks for the scenarios above.
Production consideration: State the trade-offs: managed databases reduce risk, a mesh adds mTLS and operational load, and more clusters shrink blast radius but add fleet work. Interviewers score the reasoning, not one "correct" diagram.
Key takeaways
- Explain Kubernetes as declarative desired state plus reconciliation loops; nearly every answer builds on it.
- Know the 2026 baseline: 1.37 is the newest release, Ingress is frozen, Ingress NGINX is retired, Gateway API is recommended, and sidecars, in-place resize, DRA, image volumes and CEL admission policies are stable.
- Requests drive scheduling and autoscaling; limits drive throttling and OOM kills.
- Readiness probes and graceful shutdown make rollouts, drains and upgrades invisible to users.
- Security is layered: RBAC, Pod Security Admission, NetworkPolicies, secrets management, workload identity and a signed supply chain.
- In troubleshooting, start with
kubectl describe, events and previous logs, and say what you would roll back before you debug.
Interview preparation checklist
- Build a cluster with kubeadm once and use a managed one (EKS, AKS or GKE), so you know what the provider hides.
- Write Deployment, Service, ConfigMap, Secret, PVC, HPA, NetworkPolicy and RBAC manifests from memory.
- Deploy one app with Helm and with Kustomize, then manage it with Argo CD or Flux.
- Break things on purpose (bad tag, wrong selector, tiny memory limit, missing toleration, default-deny without DNS) and fix each using kubectl output only.
- Practise a failed rollout and rollback, and a node drain with and without a PDB.
- Set up a Gateway and HTTPRoute with a weighted canary.
- Upgrade a test cluster one minor version after scanning for deprecated APIs.
- For CKA-style speed, practise
kubectl explainand--dry-run=client -o yaml. - Prepare two stories from your own work: an incident you debugged and a design trade-off.
FAQ
What Kubernetes topics do freshers need for interviews?
Freshers should know the architecture, Pods, Deployments, Services, namespaces, labels, ConfigMaps, Secrets, basic storage and everyday kubectl commands, and be able to write a simple Deployment and Service manifest.
How should I prepare for a Kubernetes troubleshooting interview?
Practise on a real cluster. Break workloads deliberately and diagnose them with kubectl describe, events, logs and node checks, then practise explaining your steps out loud in order.
Are CKA interview questions different from regular Kubernetes interview questions?
They overlap heavily. CKA-style questions focus on hands-on administration such as upgrades, etcd backup, RBAC, networking, storage and troubleshooting. Job interviews add design, trade-offs and production experience.
Do I need Docker knowledge before learning Kubernetes?
Yes, at least the basics: images, layers, containers, registries and Dockerfiles. Kubernetes nodes no longer use Docker Engine as the runtime, but the container concepts carry over directly.
Is Kubernetes still a good career skill in 2026?
Yes. Kubernetes is the common platform for containerised applications on every major cloud and on-premises, increasingly for AI workloads too, and it sits at the centre of DevOps, SRE and platform engineering roles.
Should I learn EKS, AKS or GKE for interviews?
Learn core Kubernetes first, then one managed service in depth, usually the cloud your target employers use. Know what the provider manages and how identity, load balancers and storage integrate with that cloud.
How much YAML do I need to write in a Kubernetes interview?
Expect to read and fix YAML more than write long files. You should be able to write a simple Deployment, Service or NetworkPolicy and spot errors in indentation, selectors, ports and resources.
What Kubernetes projects should I show in a portfolio?
Show a multi-service application deployed through GitOps with probes, resource requests, an HPA, NetworkPolicies and dashboards, plus a short write-up of an incident you simulated and fixed.
Do I need to know Gateway API for Kubernetes interviews in 2026?
Increasingly, yes. The Ingress API is frozen and the Kubernetes project recommends Gateway API, so know GatewayClass, Gateway and HTTPRoute and how weighted routing supports canary releases.
Kubernetes interviews reward people who have broken and fixed real clusters. For structured, lab-heavy preparation, explore the Cloudsoft Kubernetes course, in our Ameerpet classroom or live online. For a broader path that adds AI/ML, cloud and security engineering to your platform skills, look at the APEX AI, ML, Cloud and Cyber Security program. Book a free demo on +91 96660 19191.
