Kubernetes interview questions on workloads: Deployments, StatefulSets, Jobs (k8s)
Reviewed by Mark Dickie · Last updated
6 questions on this page you can answer and see marked on the spot. Go to the first one
Kubernetes workloads are the API objects that run your containers inside Pods and keep them running. Interviewers usually test whether you can match a job to the right controller and state what that controller guarantees about replica count, Pod identity, and completion. Expect to explain how a Deployment manages a ReplicaSet during a rolling update, and why a StatefulSet gives each Pod a stable name and its own storage.
Which Kubernetes workload object fits which job?
| Object | What it guarantees | Common interview trap |
|---|---|---|
| Deployment | Keeps N identical Pods running through a ReplicaSet, with rolling updates bounded by maxSurge and maxUnavailable | Editing a Pod directly; the ReplicaSet recreates it, and kubectl rollout undo depends on retained revision history |
| StatefulSet | Stable Pod names (web-0, web-1), ordered startup, one PVC per Pod from volumeClaimTemplates | Deleting the StatefulSet leaves its PVCs behind, and stable DNS needs a headless Service |
| DaemonSet | Exactly one Pod per eligible node, including nodes added later | Taints block scheduling unless a matching toleration is set |
| Job | Runs Pods until the requested completions succeed, with backoffLimit capping retries | restartPolicy must be Never or OnFailure; Always is rejected |
| CronJob | Creates a Job on a cron schedule | The default concurrencyPolicy of Allow lets runs overlap, and startingDeadlineSeconds decides whether a missed run still starts |
Work through these on a local cluster before the quiz:
- Run kubectl create deployment web --image=nginx, then kubectl scale deployment web --replicas=3, and confirm three Pods exist.
- Change the image, watch kubectl rollout status, then roll back with kubectl rollout undo deployment/web and read kubectl rollout history.
- Apply a StatefulSet with two replicas and confirm the Pods are named web-0 and web-1, each with its own PersistentVolumeClaim.
- Create a CronJob with schedule "*/5 * * * *" and concurrencyPolicy set to Forbid, then list the Jobs it spawns.
Key facts
- Tarmac has 14 Kubernetes interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 2,814 job postings asking for Kubernetes in October 2026.
- Roles asking for Kubernetes advertise a median base salary of £80,000, across 772 job postings as of October 2026.
- Tarmac last reviewed these Kubernetes interview questions on 9 November 2026.
At a glance
| Questions | 10 shown · 14 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Multiple choice, Flashcard, True / false, Fill in the blank, Ordering, Find the bug, Short answer, Design exercise, Multiple answer |
What you'll review
- deployments
- pods
- daemonsets
- statefulsets
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
A Deployment keeps a set of identical Pods running. Which object does it create and manage to actually do that?#
Options
Show answer
A Deployment manages its Pods indirectly through a ReplicaSet: the Deployment owns one or more ReplicaSets, and each ReplicaSet owns the Pods. That indirection is what enables rolling updates — Kubernetes creates a new ReplicaSet for the updated Pod template and scales it up while scaling the old ReplicaSet down. kubectl get rs reveals the ReplicaSets behind a Deployment.
A Deployment manages Pods indirectly through a ReplicaSet: the Deployment owns ReplicaSets, and each ReplicaSet owns the Pods. This indirection is what makes rolling updates work — a new ReplicaSet is created for the new template and scaled up while the old one scales down. kubectl get rs shows the ReplicaSets behind your Deployments.
What is a Pod in Kubernetes?#
Show answer
The smallest deployable unit in Kubernetes: one or more containers that are always scheduled together on the same node and share a network namespace (one IP, reachable on localhost) and can share storage volumes. You rarely create bare Pods directly — a controller like a Deployment or StatefulSet creates and manages them.
A Pod, not a container, is the unit Kubernetes schedules. Grasping that containers in a Pod share network and can share storage explains the sidecar pattern and why a Pod has a single IP.
A Pod can contain more than one container, and containers in the same Pod share a network namespace, so they can reach each other over localhost.#
Options
Show answer
True. A Pod is the smallest deployable unit and can hold multiple containers — the sidecar pattern. Containers in one Pod share its network namespace and IP address, so they reach each other over localhost on different ports, and they can share mounted volumes. They do not share a filesystem by default, which is why a proxy or logging sidecar can talk to the main container with no Service in between.
A Pod is the smallest deployable unit and may hold multiple containers (the sidecar pattern). They share the Pod's network namespace and IP, so they communicate over localhost on different ports, and they can share volumes. They do not share a filesystem by default. This is why a logging or proxy sidecar can talk to the main container without any Service in between.
A Deployment manifest begins with apiVersion: _____ and kind: _____.#
Show answer
A Deployment manifest begins with apiVersion: **apps/v1** and kind: **Deployment**.
Deployments live in the apps/v1 API group/version — the older extensions/v1beta1 and apps/v1beta* versions were removed back in v1.16, so apps/v1 is the only served version today. Getting the apiVersion wrong is a common copy-paste error from old tutorials.
A DaemonSet uses the default RollingUpdate strategy (maxUnavailable: 1, maxSurge: 0). You change its pod template image and apply it. Put these events for one node's pod, and the move to the next node, in the order they occur.#
Put these in order
Show answer
Order for a DaemonSet rolling update: apply the new template, delete the old pod on a node, create its replacement, wait until that pod is ready, then move to the next node. With maxSurge: 0, the old pod must be removed before the new one starts on the same node. The controller waits for readiness so that only one node is unavailable at a time under the default maxUnavailable: 1.
The change must be applied to the DaemonSet spec before the controller can act on it. With maxSurge set to 0, the controller cannot run a new pod alongside the old one on a node, so it must delete the old pod first and then create the replacement from the updated template. Because maxUnavailable is 1, the controller waits for the new pod to become available before it cycles the next node, so the readiness step precedes moving on.
Which requirement most specifically calls for a StatefulSet instead of a Deployment?#
Options
Show answer
Choose a StatefulSet when each replica needs a stable, ordinal identity (db-0, db-1), a matching stable DNS name, and its own durable storage that follows it across restarts — the guarantees clustered databases and quorum systems rely on. Stateless tiers belong in a Deployment, one-Pod-per-node workloads in a DaemonSet, and run-to-completion tasks in a Job.
StatefulSets give each replica a stable, ordinal identity (db-0, db-1), a matching stable DNS name, and a PersistentVolumeClaim that follows that identity across reschedules — exactly what clustered databases and quorum systems need. A stateless tier is a Deployment, one-Pod-per-node is a DaemonSet, and run-to-completion work is a Job. Reaching for a StatefulSet for a stateless app just adds ordering constraints you don't want.
This Deployment is rejected by the API server. What's wrong?#
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: frontend
spec:
containers:
- name: web
image: nginx:1.27Options
Show answer
spec.selector.matchLabels (app: web) doesn't match the Pod template's labels (app: frontend)
A Deployment's selector must match the labels on its Pod template — that's how it claims the Pods it creates. Here the selector looks for app: web but the template stamps app: frontend, so the controller could never find its own Pods; the API server rejects this at admission. apps/v1 is the correct (and only served) API version, ports is optional, and replicas don't require resource requests. Selector/label drift is one of the most common Deployment authoring bugs.
When would you choose a StatefulSet over a Deployment, and what guarantees does a StatefulSet provide that a Deployment doesn't?#
Show answer
Use a StatefulSet for stateful, identity-sensitive workloads — databases, message brokers, quorum systems — where replicas aren't interchangeable. It provides a stable, ordinal identity per replica (pod-0, pod-1, …), a matching stable network identity via a headless Service and per-Pod DNS, stable per-replica storage through PersistentVolumeClaims that stay bound to the same ordinal across reschedules, and ordered, predictable rollout/scaling (one at a time, in order). A Deployment treats Pods as fungible with random names and shared/no per-replica storage, which is wrong for anything that needs a durable identity. The cost is that StatefulSets are heavier and slower to scale.
The guarantees that matter: stable identity, stable network name, stable per-replica storage, ordered operations. Those are precisely what clustered/stateful systems need and what a Deployment (fungible Pods, random names) can't give. A strong answer names the workloads (databases, brokers) and acknowledges the scaling cost.
Design how you'd run a primary–replica PostgreSQL on Kubernetes with durable storage and safe failover.#
Show answer
Workload. A StatefulSet (ideally driven by a Postgres operator such as CloudNativePG or Patroni-based Zalando). StatefulSet gives each replica a stable ordinal identity (pg-0, pg-1) and stable DNS, and does ordered, one-at-a-time rollouts — essential for a database where replicas are not interchangeable.
Storage. volumeClaimTemplates so every replica gets its own PVC, bound to its ordinal and re-attached on reschedule. A StorageClass backed by zonal block storage (ReadWriteOnce) per Pod — never a single shared volume. Storage and Pod must stay in the same zone, so spread/affinity is zone-aware.
Networking. A headless Service gives stable per-Pod DNS (pg-0.pg.ns.svc). Expose two logical endpoints: a write/primary Service whose selector (or operator-managed label) points at the current primary, and a read Service spanning replicas. On failover the operator repoints the write endpoint.
Failover. Kubernetes won't promote a database on its own — a StatefulSet just restarts/reschedules Pods with the same identity and data. An operator/Patroni runs leader election (via a distributed lock), promotes a healthy, most-caught-up replica, reconfigures the others to follow it, and updates the write endpoint. Fencing/quorum prevents split-brain so two Pods never accept writes at once.
Backups. Continuous WAL archiving plus periodic base backups to object storage (S3/GCS), enabling point-in-time recovery — replication protects against node loss, not against a bad migration or DELETE, so backups are separate and their restore path must be tested.
Tradeoffs. Running Postgres on k8s buys consistency with the rest of the platform but costs real operational complexity (storage performance, failover correctness, upgrades) and failure risk. For most teams a managed database (RDS/Cloud SQL) is the right default; self-hosting on k8s makes sense for cost at scale, multi-cloud portability, or strict data-locality needs — and only with a mature operator.
The make-or-break insight is that a StatefulSet provides stable identity and storage but does NOT make Postgres failover-aware — promotion, leader election, and split-brain prevention come from an operator/Patroni, not from Kubernetes. Strong answers pair volumeClaimTemplates + a zonal RWO StorageClass with an operator for failover, keep backups distinct from replication, and are honest that a managed database is often the better default. This separates candidates who've run databases in production from those reciting StatefulSet features.
In a current Kubernetes cluster (v1.28 or later), which statements about how the DaemonSet controller places and keeps its pods on nodes are correct? Select all that apply.#
Options
Pick every one that applies.
Show answer
In current Kubernetes, DaemonSet pods are bound by the default scheduler, which honors a per-node required affinity the DaemonSet controller injects. The controller also adds tolerations for unschedulable, not-ready, and unreachable taints, so cordoned or unreachable nodes keep their DaemonSet pods. Setting maxSurge above zero does the opposite of forced deletion: it creates replacement pods before old ones are removed.
The DaemonSet controller pins each pod to its target node by injecting a required nodeAffinity on metadata.name, and the default scheduler performs the binding, which has been the mechanism since the DaemonSet scheduling change in 1.12. The controller also injects tolerations for the unschedulable NoSchedule taint and for the not-ready and unreachable NoExecute taints without a tolerationSeconds limit, which is why cordoning does not stop DaemonSet pods from running and why node-lifecycle eviction leaves them alone. The statement about maxSurge is false because a positive maxSurge lets the controller start the new pod on a node while the old one is still running, the reverse of forced deletion. The statement that the controller writes spec.nodeName directly is false because it relies on the scheduler to bind pods.
Related interview questions
Job market
See kubernetes salaries and hiring demand from live job postings.
The other 4 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 4 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 answers per 30 days, each marked with written feedback