Kubernetes interview questions and answers

A Pod is the smallest deployable unit: one or more containers that share a network namespace, so they reach each other on localhost, and can share volumes. They are always scheduled together on one node.

You do not create bare Pods because nothing looks after them. If the node dies, a bare Pod dies with it and nothing brings it back. A controller such as a Deployment holds a desired state and reconciles toward it, so a lost Pod is replaced.

The consequence to state out loud: Pods are disposable. Their name, their IP and their local disk are all temporary, so anything you care about belongs to a controller, a Service or a PersistentVolume rather than to the Pod.

They are a chain of ownership, not alternatives.

A rolling update is a Deployment creating a second ReplicaSet and shifting replicas from the old one to the new one, which is exactly why a rollback is fast: the old ReplicaSet is still there at zero replicas.

The question underneath is usually whether you understand that you edit the Deployment and never the ReplicaSet or the Pod, because the controller will reconcile your change away.

A Service gives a stable name and virtual IP in front of a changing set of Pods, selected by label. Pods come and go with different IPs; the Service does not.

The detail worth volunteering: a Service does not track Pods directly. It selects them by label, and the endpoints controller writes the matching Pod IPs into an EndpointSlice. That is why kubectl get endpointslices is the first thing to check when a Service accepts connections and forwards them nowhere.

Both hold key-value configuration and are mounted as files or injected as environment variables. The difference is intent, not much protection.

The answer interviewers want is that base64 is not security. A Secret is only meaningfully protected if etcd encryption at rest is turned on and RBAC actually restricts who can read it, and for real secret management you would use an external store with the Secrets Store CSI driver or External Secrets Operator.

Four, in this order, because each one rules out a different layer.

1. 1`kubectl get pods -o wide` tells you the phase, the restart count and which node it landed on. Pending, CrashLoopBackOff and 0/1 Ready are three different problems.
2. 2`kubectl describe pod <name>` shows the Events at the bottom, which is where Kubernetes tells you why in plain language: FailedScheduling, ImagePullBackOff, FailedMount.
3. 3`kubectl logs <name> --previous` reads the container that crashed rather than the one starting now, which is the whole trick during a backoff.
4. 4`kubectl get events --sort-by=.lastTimestamp` widens it to the namespace when the Pod itself looks fine.

Saying describe before logs is the signal. Events explain scheduling and image problems that logs cannot, because in those cases the container never ran.

Three probes, three different consequences, and conflating them causes real outages.

The mistake to name: pointing a liveness probe at a dependency. If the probe checks the database and the database has a bad minute, Kubernetes restarts your entire fleet, turning a degraded dependency into a full outage. Liveness should test only whether this process is stuck.

The startup probe exists so you do not have to set a long initialDelaySeconds on liveness, which would otherwise leave a genuinely wedged container unkilled for that whole window.

A request is what the scheduler reserves. A limit is what the kernel enforces.

That asymmetry is the answer most candidates miss. CPU is compressible so exceeding the limit slows you down; memory is not, so exceeding it kills the container.

The requests also determine the QoS class, which decides who gets evicted first when a node is under pressure:

• Guaranteed: requests equal limits for every container. Evicted last.
• Burstable: requests set and lower than limits. Evicted in the middle.
• BestEffort: nothing set. Evicted first.

A production workload with no requests is BestEffort, which means it is first out of the door when a node runs short. That is worth saying.

Confirm it, then work out which of the two causes it is.

kubectl get endpointslices -l kubernetes.io/service-name=payments-api

Empty means the Service has no backends. There are exactly two reasons.

The selector matches nothing. Kubernetes never validates a selector, so a Service with a typo is created successfully and routes nowhere.

kubectl get svc payments-api -o jsonpath='{.spec.selector}{"\n"}'
kubectl get pods --show-labels

The Pods match but are not Ready. Only Ready Pods become endpoints, which is deliberate and is the entire point of a readiness probe.

kubectl get pods -l app=payments-api

STATUS: Running with READY: 0/1 is that signature. Also worth naming: selectors never cross namespaces, so a Service and its Pods in different namespaces will never match.

The Deployment creates a new ReplicaSet and shifts replicas across, bounded by two settings:

• `maxUnavailable`: how many replicas may be down at once.
• `maxSurge`: how many extra replicas may exist above the desired count.

With the defaults of 25% each, it scales the new set up and the old set down in steps, waiting for new Pods to become Ready before continuing. That is why a broken readiness probe makes a rollout hang rather than fail: Kubernetes is doing exactly what you asked.

kubectl rollout status deployment/payments-api
kubectl rollout undo deployment/payments-api
kubectl rollout history deployment/payments-api

Rollback is fast because the previous ReplicaSet still exists at zero replicas, so it is scaled back up rather than rebuilt.

Worth adding that progressDeadlineSeconds is what eventually marks a stuck rollout as failed, and without it a bad deploy hangs indefinitely while looking like it is working.

It depends how it is consumed, and this catches people out.

• Mounted as a volume: the file updates in place, usually within a minute or two. The application still has to notice and re-read it, which most do not.
• Injected as environment variables: never updates. Environment is set at process start, so the Pod must be recreated.

The usual answer is to force a rollout, which is safe and explicit:

kubectl rollout restart deployment/payments-api

The better answer names the durable pattern: put a hash of the ConfigMap into a Pod template annotation, so that changing the config changes the Pod spec and Kubernetes rolls it automatically. Helm charts do this with a checksum annotation, and it removes the "somebody changed config and nothing happened" class of incident entirely.

Pending means the scheduler has not placed it, so nothing about your image or application is relevant yet. kubectl describe pod lists a reason per node.

The detail that shows experience: the scheduler counts requests, not usage, so a node sitting at 5% CPU can be fully booked and correctly refuse your Pod. And WaitForFirstConsumer on a StorageClass means the PVC binding is deliberately deferred until scheduling, which is not a fault even though it looks like one.

Three objects, and the separation is the point.

1. 1StorageClass describes a kind of storage and which provisioner creates it.
2. 2PersistentVolumeClaim is what the application asks for: a size, an access mode, a class. It belongs to a namespace.
3. 3PersistentVolume is the actual piece of storage. With dynamic provisioning the CSI driver creates it in response to the claim.

The reason for the split is portability: the developer writes a PVC and never names a disk, so the same manifest works on EKS, on GKE and on a laptop.

Access modes are where the misunderstanding usually is:

RWO being per-node rather than per-Pod is the detail worth getting right, and RWX is why teams reach for EFS or a file service rather than EBS.

CoreDNS runs as a Deployment, and every Pod's /etc/resolv.conf points at its Service IP. Services get an A record of the form:

<service>.<namespace>.svc.cluster.local

Within a namespace you can use the short name; across namespaces you need at least <service>.<namespace>.

The part worth knowing is ndots. Kubernetes sets ndots:5, so any name with fewer than five dots is first tried against every entry in the search path. Resolving api.example.com therefore produces several failed cluster lookups before the external one succeeds, which is a real and commonly missed source of DNS latency. A trailing dot, or a tuned dnsConfig, avoids it.

kubectl run tmp --rm -it --image=nicolaka/netshoot -- nslookup payments-api

When DNS fails cluster-wide, check whether CoreDNS itself is running and whether a NetworkPolicy is blocking port 53.

When the Pods are not interchangeable.

So: databases, message brokers, anything doing leader election or needing each replica to keep its own data.

Two honest caveats worth adding. A StatefulSet gives you stable names and storage, not clustering; the application still has to handle replication and failover itself. And scaling down leaves the PVCs behind on purpose, so that scaling back up reattaches the same data, which surprises people who expect a clean delete.

Every controller runs the same loop: read the desired state from the API server, observe the actual state, and act to close the gap. Forever. Nothing in Kubernetes is a one-off command; kubectl apply only records intent, and a controller makes it true.

That single idea explains most surprising behaviour:

• Deleting a Pod owned by a ReplicaSet gets you a new Pod, because the loop notices.
• Editing a ReplicaSet directly is undone, because the Deployment reconciles it back.
• Manually scaling a Deployment managed by an HPA is reverted on the next cycle.
• A cluster recovers from a node loss without anyone acting, because the loop never stops.

The senior extension is what happens when a controller is gone. Objects with a finalizer whose controller has been removed hang in Terminating forever, because the finalizer is a request for cleanup that nothing is left to perform. That is the usual reason a namespace will not delete, and it is a reconciliation answer rather than a Kubernetes bug.

Four objects in two pairs. A Role and a ClusterRole list permitted verbs on resources; a RoleBinding and a ClusterRoleBinding attach them to a subject. Role and RoleBinding are namespaced, the Cluster variants are not.

A useful subtlety: a ClusterRole bound by a RoleBinding grants those permissions only inside that namespace, which is how you reuse one role definition across many namespaces.

Everything is additive and there is no deny. If a subject has any binding granting the verb, it is allowed.

Where it goes wrong:

• `cluster-admin` handed out because something failed and nobody went back.
• Wildcards, where resources: ["*"] quietly includes things added by future CRDs.
• Escalation paths that do not look like admin. Permission to create a Pod lets you mount any Secret in the namespace and run as any service account. Permission to create a pods/exec lets you enter a running container. Permission to edit a Deployment is permission to run arbitrary code on a node.

kubectl auth can-i --list --as=system:serviceaccount:payments:api

That command is the answer to "how would you audit it", and naming it lands well.

Not what most people expect, and the timing matters.

The kubelet stops reporting. After node-monitor-grace-period, about 40 seconds, the node controller marks the node NotReady. Pods are not deleted: they are tainted with node.kubernetes.io/unreachable, and the default toleration keeps them for a further 300 seconds before eviction.

So there is roughly a five-minute window in which the Pods still exist in the API, the Service still lists them as endpoints if they were Ready, and traffic is being sent to a node that is gone. That gap is why readiness probes and sensible client timeouts matter more than node monitoring does.

Then eviction happens, and what follows depends on the controller. A Deployment's ReplicaSet creates replacements elsewhere immediately. A StatefulSet does not, because Kubernetes cannot tell a dead node from a partitioned one, and starting a second db-0 while the first may still be writing risks split brain. That Pod stays Terminating until the node returns or somebody force-deletes it, which is a deliberate safety choice.

They push from opposite directions, which is the distinction being tested.

A toleration does not attract; it only permits. A Pod tolerating a GPU taint will not prefer GPU nodes, it is merely allowed on them, so you generally need affinity as well.

Taint effects are worth knowing: NoSchedule stops new Pods, PreferNoSchedule is a soft version, and NoExecute also evicts Pods already running that do not tolerate it.

The practical use of anti-affinity is spreading replicas across zones so one failure does not take all of them, though topologySpreadConstraints is the more precise modern tool for that.

Four, and each has a different fix.

1. 1The container does not handle SIGTERM. Kubernetes sends it, waits terminationGracePeriodSeconds, then SIGKILLs. An application that ignores it drops in-flight requests. The container must stop accepting new connections and drain.
2. 2Endpoint removal races the shutdown. Removing a Pod from endpoints and telling the kubelet to stop it happen in parallel, so a proxy can still send traffic to a container that has begun shutting down. A preStop sleep of a few seconds covers the gap and is the standard fix.
3. 3The readiness probe never fails on shutdown, so the Pod stays in endpoints longer than it should.
4. 4No PodDisruptionBudget, so a node drain can take down every replica at once during a cluster upgrade.

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]
terminationGracePeriodSeconds: 30

Naming the endpoint race specifically is what marks this as experience rather than reading, because it is the one that survives a correct SIGTERM handler.

More often than the industry admits, and being able to say so is the point of the question.

Kubernetes is worth its cost when you have enough services that scheduling is a real problem, a team that can operate it, and requirements such as self-healing, rolling deploys and horizontal scale that you would otherwise build yourself.

It is the wrong tool when:

• The team is small. A cluster is a distributed system with its own failure modes, its own upgrade cadence and its own on-call load. That is a permanent tax.
• There are three services. A managed platform or a couple of VMs behind a load balancer is cheaper, faster to reason about, and easier to hire for.
• The workload is not a good fit. Long-lived stateful systems with their own clustering often gain little, and a managed database is usually the better answer.
• You are adopting it for portability you will never use. Cloud-agnostic is a real goal for very few teams and a stated goal for many.

The strongest version names the cost honestly and then says what would change your mind.

PodSecurityPolicy was deprecated in 1.21 and removed in 1.25. Pod Security Admission replaced it, and it works differently: rather than a policy object you bind with RBAC, it is a built-in admission controller configured with a label on the namespace.

kubectl label namespace payments \
  pod-security.kubernetes.io/enforce=restricted

Three levels: privileged allows everything, baseline blocks known privilege escalations, restricted additionally requires non-root, a read-only root filesystem, dropped capabilities and a seccomp profile. Each can be set to enforce, audit or warn, so you can roll it out by watching what would break before you break it.

The honest limitation, and the reason to mention OPA Gatekeeper or Kyverno: PSA only covers Pod security context. Anything else you want to enforce, such as required labels, permitted registries or resource limits, needs a policy engine.

Ephemeral containers, which is the purpose-built answer:

kubectl debug -it payments-api-7d4f --image=nicolaka/netshoot --target=api

That attaches a container sharing the target's process and network namespaces, so your tools see its processes and its network without the production image carrying a shell.

Two related forms worth knowing. kubectl debug node/ip-10-0-1-42 -it --image=busybox gives you a Pod on the node with the host filesystem mounted, for node-level problems. And kubectl debug <pod> --copy-to=debug-pod --set-image=api=busybox makes a modified copy rather than touching the running Pod.

Say that you would not add a shell to the production image to make this easier, because that removes the reason the image is hardened.

create is imperative: it makes the object and fails if it already exists. apply is declarative: it creates or updates toward the manifest, and can be run repeatedly.

apply also records the manifest in a last-applied-configuration annotation, which is how it works out that a field you removed from your file should be removed from the object. create has no such memory, so switching between the two causes confusing results.

Use apply for anything in version control. create is for one-off imperative work, usually generating a manifest to edit:

kubectl create deployment api --image=nginx --dry-run=client -o yaml > deploy.yaml

Worth a mention that server-side apply is now the more robust mechanism, since it tracks field ownership on the server rather than in an annotation, which is what makes multiple controllers editing one object behave sanely.

A Service exposes one workload at layer 4. An Ingress is a layer 7 router for HTTP that fronts many Services, matching on host and path, and terminating TLS.

The critical detail: an Ingress object does nothing on its own. It is configuration read by an ingress controller, such as nginx or Traefik or a cloud implementation, and with no controller installed the object simply sits there. A surprising number of "my Ingress does not work" problems are exactly that, or a missing ingressClassName.

The Gateway API is the successor, and the reason is organisational as much as technical. Ingress accumulated vendor-specific annotations for anything beyond basic routing, so manifests stopped being portable. Gateway API splits the concern into roles: infrastructure teams own the GatewayClass and Gateway, application teams own the HTTPRoute. It also handles traffic splitting, header matching and non-HTTP protocols as first-class fields rather than annotations.

Saying Ingress is effectively feature-frozen in favour of Gateway API is current and lands well.

It reads a metric, compares it to a target, and computes the replica count roughly as current replicas times current metric over target metric, then applies that within the min and max you set.

Requirements people forget: the metrics-server must be installed for CPU and memory, and the Pods must have resource requests set, because CPU utilisation is expressed as a percentage of the request. No requests means no CPU-based autoscaling at all.

kubectl get hpa
kubectl describe hpa payments-api

Three things worth adding. CPU is often a poor signal, since an IO-bound service can be saturated at 20% CPU, and autoscaling/v2 supports custom and external metrics such as queue depth for exactly that reason. Scale-down is deliberately slower than scale-up to avoid flapping. And HPA and a manually set replicas field fight each other, with the HPA winning on its next cycle, which is a common source of confusion.

The point of the question is whether you know the control plane is a set of independent loops rather than one program.

1. 1kubectl resolves the manifest and sends it to the API server, authenticated by your kubeconfig.
2. 2The API server authenticates, authorises through RBAC, runs mutating admission webhooks, validates the object, runs validating admission webhooks, and persists it to etcd. Nothing has been scheduled yet.
3. 3The Deployment controller notices a Deployment with no matching ReplicaSet and creates one.
4. 4The ReplicaSet controller notices it has fewer Pods than it wants and creates Pod objects. They have no node.
5. 5The scheduler watches for Pods with no nodeName, filters nodes by feasibility, scores the survivors, and writes a binding.
6. 6The kubelet on that node sees a Pod bound to it, pulls the image through the container runtime, sets up the network via CNI, mounts volumes via CSI, and starts the containers.
7. 7The kubelet reports status back, and once readiness passes the endpoints controller adds the Pod to its Service's EndpointSlice.

The insight to state: no component calls another. Each watches the API server and acts, which is why the system is resilient and also why debugging means asking which loop has stopped.

hostPath is the one to be careful about in an interview. It ties a Pod to a specific node, breaks the moment it is rescheduled, and is a serious security concern: mounting /var/run/docker.sock or a host root path is a standard container escape route. Say that you would use it only for something that genuinely is node-scoped, such as a log shipper.

emptyDir with medium: Memory is a useful detail, giving you a tmpfs that never touches disk, which suits secrets and scratch data.

A namespace is a scope for names, so two teams can both have a Service called api. It is also the unit that RBAC, ResourceQuotas and LimitRanges attach to.

What it does not do is the part that matters:

• It is not a network boundary. By default every Pod can reach every other Pod in the cluster regardless of namespace. Only a NetworkPolicy changes that.
• It is not a security boundary on its own. Without RBAC restricting access, a namespace is organisational only.
• It does not scope nodes. Pods from different namespaces share the same machines, so a noisy workload affects its neighbours unless requests and limits say otherwise.
• Some objects are cluster-scoped anyway: nodes, PersistentVolumes, StorageClasses, ClusterRoles and CRDs.

For genuinely hostile multi-tenancy, namespaces are not enough and the answer is separate clusters or a sandboxed runtime.

Almost always a finalizer on a resource inside it whose controller is gone.

A finalizer is a request: do not actually delete this until I have cleaned up. The API server honours it by leaving the object in Terminating until the finalizer is removed. If the controller that would remove it has been uninstalled, nothing ever will, and the namespace waits on the object forever.

Find what is left:

kubectl api-resources --verbs=list --namespaced -o name \
  | xargs -n1 kubectl get --show-kind --ignore-not-found -n stuck-namespace

Then inspect the offender's metadata.finalizers. The right fix is to reinstall the controller and let it clean up properly. Only when that is impossible do you remove the finalizer by hand, and you should say out loud that this leaks whatever it was going to clean up, typically a cloud load balancer or a volume that now has no owner.

Forcing the namespace object's own finalizer through the API is the last resort, and it orphans everything inside rather than deleting it.

Nothing happens, and that is the problem. The default is a flat network: every Pod can reach every other Pod in the cluster, across every namespace.

A NetworkPolicy selects Pods and describes allowed ingress and egress. The important semantics:

• A Pod selected by any policy becomes default-deny for the direction that policy covers. Until then it is allow-all.
• Policies are additive, with no deny rules; the union of what matches is permitted.
• It needs a CNI that implements it. Calico and Cilium do; a plain flannel setup does not, and your policies are silently ignored.

That last point is the one worth volunteering, because a policy that does nothing looks exactly like a policy that works until somebody tests it.

The standard starting position is a default-deny ingress policy per namespace, then allowing what is actually needed, which turns a lateral-movement problem into a small number of explicit paths.