In this article
Architecture
The first group covers what the cluster is made of. This page sits in the DevOps and cloud hub, which lists the neighbouring topics. Start from the picture below and you can answer most basic questions by pointing at one box: the application programming interface (API) server (the front door of the cluster) is the hub, and every other component talks only to it.
Step-by-step description
- kubectl sends the Deployment to the API server, which stores it in etcd.
- The controller manager creates the ReplicaSet and Pods via the API server.
- The scheduler writes a binding for each unbound Pod.
- The kubelet sees its Pod; the container runtime starts it.
- The API server stores cluster state in etcd.
- The controller manager creates the ReplicaSet and Pods through the API server.
- The scheduler writes a binding to the API server.
- The kubelet watches the API server for its Pods and asks the container runtime to start the containers.
In words: the API server stores the Deployment in etcd. The controller manager creates the ReplicaSet and Pods through the API server. The scheduler writes a binding to the API server for each unbound Pod. The kubelet on that node watches the API server for its Pods and asks the container runtime to start the containers.
What is Kubernetes?
Kubernetes is an open-source system that runs containerised applications across a group of machines and keeps them in the state you declare. You describe the desired state, such as three copies of a web server, and controllers keep changing the real state until it matches. The unit it schedules is the Pod, not the container.
Why it is asked: it checks that you can define the tool without product language. For where it fits in a larger design, see the system design hub.
What are the main components of a cluster?
The control plane is the set of components that make cluster decisions, and the nodes run the workloads. Per the Kubernetes components page: kube-apiserver exposes the API, etcd stores all API server data, kube-scheduler assigns unbound Pods to nodes, and kube-controller-manager runs the controllers (cloud-controller-manager adds cloud-specific ones). Each node has a kubelet, which ensures Pods are running, and a container runtime, reached through the container runtime interface (CRI), such as containerd or CRI-O, which actually runs the containers. kube-proxy, optional, implements Services.
Why it is asked: it is the standard opener. The follow-up is "what breaks if etcd is lost": the API server keeps its state only in etcd, so the cluster cannot accept changes until you restore from a snapshot (etcd operations documentation); containers the kubelets already started keep running meanwhile.
What is a Pod and why not run bare containers?
A Pod is a group of one or more containers with shared storage and network resources and a specification for how to run them. The Pods documentation calls it the smallest deployable unit you can create and manage, and describes Pods as relatively ephemeral, disposable entities. Containers in one Pod share a network identity and volumes, which suits a main process plus a helper.
Why it is asked: it tests whether you know Kubernetes schedules Pods and that Pods are replaceable.
Workloads
Workload controllers are the objects that keep Pods running. The questions here ask which controller fits which application.
What is a Deployment and how does a rolling update work?
A Deployment manages a set of Pods for a workload that usually does not keep state, and provides declarative updates for Pods and their ReplicaSets, the objects that keep a set number of identical Pods running (Deployments documentation). When the Pod template changes, a rolling update replaces old Pods with new ones gradually, by default allowing a quarter more and a quarter fewer Pods than desired during the change. If the new version is unhealthy, kubectl rollout undo returns to an earlier revision.
Why it is asked: it shows whether you have shipped a change without downtime. Read the full explanation: Deployment strategies.
What is the difference between a Deployment and a StatefulSet?
A StatefulSet manages stateful applications and gives each Pod a sticky identity: a stable ordinal name such as web-0, a stable network identity through a headless Service, and its own storage through volume claim templates. Pods are created from the same spec but are not interchangeable, and by default they start and stop in order (StatefulSets documentation). A Deployment's Pods are interchangeable and unordered.
Why it is asked: it separates people who match the controller to the data from people who use Deployments for everything.
What is a DaemonSet used for?
A DaemonSet makes sure all, or some, nodes run a copy of one Pod. Pods are added as nodes join the cluster and removed as nodes leave. Typical uses in the DaemonSet documentation are a cluster storage daemon, a log collection daemon and a node monitoring daemon on every node.
Why it is asked: it checks that you know the node-level pattern, not just the replica-level one.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Networking
Networking questions test whether you can explain how traffic reaches Pods that keep changing address.
What are the Service types and when do you use each?
A Service is a way to expose an application that runs as one or more Pods behind a stable endpoint. The default type, ClusterIP, is reachable only inside the cluster. NodePort opens a static port on every node, LoadBalancer asks a cloud provider for an external load balancer, and ExternalName maps the Service to a DNS (domain name system) name (Service documentation). Use ClusterIP for internal calls and put an Ingress or LoadBalancer in front for outside traffic.
Why it is asked: Pod addresses change, so interviewers want the reason a Service exists.
What is the difference between a Service and an Ingress?
A Service gives Pods a stable address and balances load among them. An Ingress is an API object that manages external access to Services, typically Hypertext Transfer Protocol (HTTP), with load balancing, TLS (transport layer security) termination and name-based virtual hosting. An Ingress does nothing without an Ingress controller, and the documentation now recommends the Gateway API; the Ingress API is generally available but frozen (Ingress documentation).
Why it is asked: it probes whether you know that a resource needs a controller to take effect.
What does a NetworkPolicy do?
A NetworkPolicy limits which Pods can talk to which. By default a Pod is non-isolated, so all inbound and outbound connections are allowed; it becomes isolated in a direction once a policy selects it for that direction. Policies are additive, so the allowed traffic is the union of all that apply, and they have no effect unless the network plugin enforces them (Network Policies documentation).
Why it is asked: it checks the default-open surprise and whether you know the plugin dependency.
Configuration and storage
Are Kubernetes Secrets encrypted?
Not by default. The Secrets documentation says Secrets are stored unencrypted in etcd, and that anyone with API access, or anyone who can create a Pod in the namespace, can read them. Base64 in a manifest is an encoding, not protection. The listed mitigations are encryption at rest, least-privilege RBAC (role-based access control) rules, restricting access to specific containers and considering external secret stores.
Why it is asked: it is the classic "common belief versus the documentation" question.
What are a PersistentVolume, a PersistentVolumeClaim and a StorageClass?
A PersistentVolume is a piece of storage in the cluster, provisioned by an administrator or dynamically through a StorageClass, with a lifecycle independent of any Pod. A PersistentVolumeClaim (PVC) is a user's request for storage of a size and access mode. A StorageClass describes a kind of storage and is the basis for dynamic provisioning (Persistent Volumes documentation).
Why it is asked: it tests whether you can keep data when a Pod dies.
What happens to the data when a PVC is deleted?
It depends on the volume's reclaim policy. With Retain the volume and its data are kept and an administrator cleans up manually; with Delete the volume object and the underlying storage are removed. The policy set on a StorageClass is copied onto the volumes it provisions, so check it before you delete a claim that holds data you need.
Why it is asked: it is a follow-up that catches data-loss mistakes.
Scheduling and resources
How does the Kubernetes scheduler choose a node?
In two steps. The scheduler first filters out nodes that cannot run the Pod, leaving the feasible nodes, then scores those nodes and binds the Pod to the highest score, choosing at random among ties (Kubernetes scheduler documentation, last modified February 2024). It looks only at resource requests, never at limits, when it decides whether a Pod fits.
Why it is asked: the two-step filter-then-score answer is the expected one.
What is the difference between resource requests and limits?
A request is the amount the scheduler uses to place the Pod and the kubelet reserves for the container. A limit is the most the container may use, enforced by the kernel. Going over a CPU (central processing unit) limit slows the container through throttling, while going over a memory limit can get it killed by the out-of-memory (OOM) handler (Resource Management documentation).
As an illustration, a node with 4,000 millicores and 16,384 MiB of memory allocatable to Pods, and Pods each requesting 250 millicores and 512 MiB, fits at most 16 Pods, limited by CPU. Real nodes reserve capacity for system daemons and the eviction threshold, and DaemonSet Pods take their requests first, so the usable count is lower; the scheduler packs against Node Allocatable (reserve compute resources documentation).1
Why it is asked: misjudged requests cause both wasted money and evictions.
What are taints and tolerations, and how do they differ from node affinity?
A taint on a node repels Pods that lack a matching toleration; a toleration lets a Pod be scheduled onto a tainted node but does not require it. The effects are NoSchedule, PreferNoSchedule (a soft version) and NoExecute, which also evicts running Pods. Node affinity is set on the Pod and attracts it to nodes (Taints and Tolerations documentation). To dedicate nodes, taint them and give the target Pods both a toleration and affinity. Machine-learning clusters do this for GPU (graphics processing unit) nodes; see the GPU fundamentals page.
Why it is asked: it separates repel from attract, a common mix-up.
How does the horizontal pod autoscaler decide the replica count?
It computes desired replicas as the current replicas multiplied by the ratio of the current metric value to the desired value, rounded up (Horizontal Pod Autoscaling documentation); the default check interval is 15 seconds. With 4 replicas at 90% CPU against a 60% target, the result is 6; with 6 replicas at 30% against 60%, it is 3.1
Why it is asked: interviewers want the formula and one worked case.
Reliability and security
What does Kubernetes do when a node fails?
The control plane marks the node NotReady or Unreachable and adds a NoExecute taint. Pods get a default toleration for that taint of 300 seconds, so after about five minutes they are evicted (Taints and Tolerations documentation). A ReplicaSet then creates replacement Pods, which the scheduler places on healthy nodes. StatefulSet Pods are different: the replacement waits until the old Pod is confirmed gone, to avoid two copies with the same identity (StatefulSets documentation).
Why it is asked: it tests whether you know that recovery is automatic but delayed, and why stateful Pods are slower.
What is the difference between a liveness and a readiness probe?
A liveness probe checks whether the container is healthy, and on failure the kubelet kills and restarts it. A readiness probe checks whether the container can accept traffic, and on failure the Pod is removed from Service endpoints but not restarted. A startup probe holds the other two off until a slow container has started (probes documentation).
Why it is asked: confusing the two causes restart loops in production.
How do you debug a Pod that keeps restarting?
A Pod that keeps restarting shows the status CrashLoopBackOff in kubectl get pods: a container keeps starting and exiting, so the kubelet waits longer between restarts, with an exponential back-off of 10 s, 20 s, 40 s and so on, capped at five minutes (Pod Lifecycle documentation). Read the previous container's logs with kubectl logs --previous, then kubectl describe pod for the exit code, events and probe failures. Common causes are a bad command or configuration, a liveness probe that fires too early, or an out-of-memory kill from a memory limit set too low, which kubectl describe shows as OOMKilled with exit code 137.
Why it is asked: it tests a method, not a memorised command.
How does RBAC work in Kubernetes?
RBAC is Kubernetes' role-based authorisation. A Role grants permissions inside one namespace and a ClusterRole is a cluster-wide set of permissions; a RoleBinding grants either to users, groups or service accounts in one namespace, and a ClusterRoleBinding grants a ClusterRole cluster-wide. Permissions are purely additive: there are no deny rules, so access is refused unless a rule grants it (RBAC documentation).
Why it is asked: it checks least-privilege thinking. Commands for inspecting a node when something is wrong are in Linux commands.
How would you prepare for a Kubernetes interview?
Run a small cluster yourself, deploy an application with a Deployment, a Service and an Ingress, break it on purpose with a bad image and a failing probe, and fix it from kubectl describe and logs. Then rehearse the answers above aloud. Related rounds are described in the interview loops hub, and the design-level questions are in cloud architect interview questions.
Why it is asked: it shows whether you have operated anything.
- Name the components by job: API server serves, etcd stores, controllers create Pods, scheduler places, kubelet and runtime run them.
- Match the controller to the data: Deployment for interchangeable Pods, StatefulSet for identity.
- A Service gives Pods a stable address; an Ingress needs a controller.
- Secrets are not encrypted by default; requests place Pods, limits cap them.
- When a node fails, Pods are evicted after about five minutes and recreated elsewhere.
- Readiness removes a Pod from traffic; liveness restarts it.
Sources
- Kubernetes components — Kubernetes documentation, 24 Oct 2026
- Pods — Kubernetes documentation, 24 Oct 2026
- Deployments — Kubernetes documentation, 24 Oct 2026
- StatefulSets — Kubernetes documentation, 24 Oct 2026
- DaemonSet — Kubernetes documentation, 24 Oct 2026
- Service — Kubernetes documentation, 24 Oct 2026
- Ingress — Kubernetes documentation, 24 Oct 2026
- Network Policies — Kubernetes documentation, 24 Oct 2026
- Secrets — Kubernetes documentation, 24 Oct 2026
- Persistent Volumes — Kubernetes documentation, 24 Oct 2026
- Resource Management for Pods and Containers — Kubernetes documentation, 24 Oct 2026
- Configure Liveness, Readiness and Startup Probes — Kubernetes documentation, 24 Oct 2026
- Taints and Tolerations — Kubernetes documentation, 24 Oct 2026
- Kubernetes Scheduler — Kubernetes documentation, 16 Feb 2024
- Using RBAC Authorization — Kubernetes documentation, 24 Oct 2026
- Pod Lifecycle — Kubernetes documentation, 24 Oct 2026
- Reserve Compute Resources for System Daemons — Kubernetes documentation, 24 Oct 2026
- Operating etcd clusters for Kubernetes — Kubernetes documentation, 24 Oct 2026
- Horizontal Pod Autoscaling — Kubernetes documentation, 24 Oct 2026
