The KCNA exam spends a large share of its Kubernetes Fundamentals domain on one deceptively simple question: given a workload, which resource do you create to run it? You will not be asked to write YAML from scratch, but you will be shown a scenario — “a stateless web API that needs three identical replicas,” “a log-shipping agent that must run on every node,” “a nightly database backup” — and asked to name the right workload resource. Each of those phrases maps to exactly one correct answer, and the exam is testing whether you can translate a workload’s shape into the controller built for it.
This guide covers the workload resources you must be able to tell apart for the KCNA: the Pod itself, and the controllers that manage Pods — ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, and CronJob. We will start with the controller pattern that ties them all together, walk each resource and the exact workload it exists to serve, and finish with a decision table and FAQ so that when a scenario appears, the right resource is already obvious. If you are still mapping out your preparation, start with the KCNA study guide and the KCNA exam guide for 2026.
Why Workloads Dominate the KCNA Fundamentals Domain
Kubernetes Fundamentals is the single largest domain on the KCNA, worth 46% of your score. Within it, the workload resources are the most concrete, most testable topic — they are objects you can name, compare, and match to scenarios, which makes them ideal exam material. Everything else in the fundamentals domain supports them: the object model and declarative API describe how you tell Kubernetes what you want, and scheduling and resource management describe where the resulting Pods land. Workloads are the what.
The exam’s real test here is discrimination. All of these controllers create and manage Pods, so the surface behavior looks similar. The skill is knowing the one property that separates them — stateless versus stateful, one-per-node versus a fixed replica count, run-to-completion versus run-forever — and matching it to the scenario’s wording.
The Controller Pattern: Desired State and Reconciliation
Before the individual resources, understand the idea underneath all of them, because the KCNA loves to test it directly. Kubernetes is declarative: you describe the desired state of the system in an object, and a controller continuously works to make the actual state match. This never-ending compare-and-correct loop is called reconciliation.
A controller is a control loop that watches a resource through the API server and takes action when reality drifts from the spec. If you declare “I want 3 replicas of this Pod” and a node dies taking one Pod with it, the controller notices that actual (2) no longer equals desired (3) and creates a replacement. You did not tell it to create a Pod — you told it the desired count, and it reconciled. This is the difference between declarative management (“make it so”) and imperative commands (“do this one thing now”), and it is why you almost never create bare Pods in production.
Every workload controller below is a specialization of this pattern. They differ only in what desired state they manage and how they create the Pods to satisfy it.
The Pod: The Smallest Deployable Unit
A Pod is the smallest object you can deploy in Kubernetes. It wraps one or more containers that share a network namespace (the same IP and port space) and can share storage volumes. Containers in the same Pod are always scheduled onto the same node and are treated as a single unit — they start, stop, and move together.
The critical exam fact about a bare Pod is that it is ephemeral and unmanaged. If the node it runs on fails, or the Pod is deleted, nothing recreates it. A Pod has no self-healing, no scaling, and no rolling updates on its own. That is why, in practice, you rarely create a Pod directly — you create a controller that creates and manages Pods for you. Remember this framing: a Pod is a single instance; a controller keeps the right number of the right Pods running over time.
A common multi-container Pod pattern the KCNA may reference is the sidecar — a helper container (for logging, a proxy, or syncing files) that runs alongside the main application container in the same Pod and shares its lifecycle.
ReplicaSet: Keeping N Copies Alive
A ReplicaSet is the controller that guarantees a specified number of identical Pod replicas are running at any time. Its desired state is a replica count and a Pod template. If there are too few Pods, it creates more; if there are too many, it deletes some. It uses a label selector to know which Pods it owns.
Here is the key exam nuance: you almost never create a ReplicaSet directly. It is the lower-level primitive that a Deployment manages on your behalf. The KCNA wants you to know that the ReplicaSet provides the replication and self-healing, but the Deployment sits on top of it to provide updates and rollbacks. If a question asks which object maintains a stable set of replica Pods, ReplicaSet is correct — but if it asks what you should actually deploy a stateless app with, the answer is Deployment.
Deployment: The Default for Stateless Apps
A Deployment is the workhorse of Kubernetes and the default answer for running a stateless application. It manages ReplicaSets, which in turn manage Pods, giving you a full lifecycle: declarative scaling, self-healing, rolling updates, and rollbacks.
The feature that distinguishes a Deployment from a bare ReplicaSet is the rolling update. When you change the Pod template — say, bump the container image to a new version — the Deployment creates a new ReplicaSet and gradually shifts Pods from the old ReplicaSet to the new one, a few at a time, so the application stays available throughout. If the new version is broken, you can roll back to the previous ReplicaSet with a single command because the Deployment keeps the revision history.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.27You scale it declaratively — change replicas and re-apply — or imperatively for quick demos with kubectl scale deployment web --replicas=5. On the KCNA, when a scenario says “stateless,” “identical replicas,” “web frontend,” “rolling update,” or “no rollback pain,” the answer is Deployment. The rolling updates deep dive shows the mechanics in more hands-on detail if you want to go further.
StatefulSet: When Identity and Order Matter
A StatefulSet manages stateful applications — the ones where each Pod is not interchangeable. It is the answer whenever a workload needs stable, unique network identities, stable persistent storage per Pod, and ordered, graceful deployment and scaling.
The differences from a Deployment are precise and heavily tested:
- Stable identity. Pods get predictable, sticky names —
mysql-0,mysql-1,mysql-2— instead of the random suffixes a Deployment gives (web-7d9f8b6c4-xk2lp). A Pod’s name and its DNS hostname survive rescheduling. - Stable storage. Each Pod gets its own PersistentVolumeClaim that follows it. When
mysql-1is rescheduled, it reattaches to the same volume, so its data persists. (See persistent volumes, PVCs, and StorageClasses for how that storage is provisioned.) - Ordered operations. Pods are created in order (0, then 1, then 2) and terminated in reverse. This matters for clustered software that needs a primary up before replicas join.
Classic StatefulSet workloads are databases (MySQL, PostgreSQL), distributed data stores (Cassandra, MongoDB), and message brokers (Kafka, ZooKeeper). On the exam, keyword triggers are “database,” “stateful,” “stable network identity,” “ordered,” “each replica needs its own persistent volume,” or “leader/follower.” If you see those, do not answer Deployment.
DaemonSet: One Pod Per Node
A DaemonSet ensures that a copy of a Pod runs on every node in the cluster (or every node matching a selector). As nodes are added to the cluster, the DaemonSet automatically schedules its Pod onto them; as nodes are removed, those Pods are garbage-collected. You do not set a replica count — the count is the number of matching nodes.
DaemonSets exist for node-level infrastructure: log collectors (Fluentd, Fluent Bit), monitoring agents (the Prometheus node exporter), storage daemons, and CNI networking plugins. The mental model is “one agent per machine.” The KCNA keyword triggers are unmistakable: “on every node,” “on each node,” “node-level agent,” “log collector on all nodes,” or “monitoring daemon.” If the workload must have exactly one instance per node, it is a DaemonSet — never a Deployment with a matching replica count, because that would not track nodes joining and leaving.
Job: Run to Completion
A Job runs a Pod (or several) until it completes successfully, then stops. Unlike a Deployment, whose Pods are meant to run forever and are restarted if they exit, a Job’s Pods are supposed to finish. Once the required number of successful completions is reached, the Job is done and does not restart the Pods.
Jobs are for batch and one-off tasks: a data migration, a database backup, processing a queue of work items, a report generation. A Job can run its Pods sequentially or in parallel (via completions and parallelism), and it will retry a failed Pod up to a backoffLimit.
apiVersion: batch/v1
kind: Job
metadata:
name: db-migrate
spec:
backoffLimit: 4
template:
spec:
restartPolicy: OnFailure
containers:
- name: migrate
image: myapp/migrations:1.4The exam signal is “run once,” “batch job,” “process and exit,” “run to completion,” or “one-time task.” Note the apiVersion: batch/v1 — Jobs and CronJobs live in the batch API group, whereas Deployments, StatefulSets, DaemonSets, and ReplicaSets live in apps/v1. That grouping is a fair KCNA detail.
CronJob: Jobs on a Schedule
A CronJob creates Jobs on a repeating time-based schedule, using standard cron syntax. It is the Kubernetes-native answer to “do this task every night,” “every hour,” or “every Monday at 2 a.m.” Each time the schedule fires, the CronJob creates a new Job, which creates a Pod that runs to completion.
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-backup
spec:
schedule: "0 2 * * *" # 02:00 every day
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: backup
image: myapp/backup:2.1The relationship is a clean hierarchy: CronJob → creates Jobs → which create Pods. Keyword triggers are “scheduled,” “recurring,” “nightly,” “every X hours,” “cron,” or “periodic.” If a task must repeat on a clock, it is a CronJob; if it runs once, it is a plain Job. The Jobs and CronJobs guide walks through the parallelism and scheduling knobs in more depth.
The Decision Table: Which Workload Resource?
This is the single most valuable thing to memorize for this topic. Read a scenario, find the row, name the resource.
| Workload characteristic | Resource | Why |
|---|---|---|
| Single container instance, no management | Pod | Smallest unit; ephemeral, no self-healing |
| Stateless app, N identical replicas, rolling updates | Deployment | Manages ReplicaSets; updates + rollbacks |
| Guaranteed replica count only (low-level) | ReplicaSet | Replication primitive under a Deployment |
| Stateful app: stable identity, per-Pod storage, order | StatefulSet | Sticky names, own PVC, ordered ops |
| One Pod on every node | DaemonSet | Node-level agents; tracks node membership |
| Run once to completion | Job | Batch task that finishes, then stops |
| Run on a repeating schedule | CronJob | Creates Jobs on a cron timetable |
Two comparisons the KCNA tests most often deserve extra emphasis. Deployment vs. StatefulSet: stateless and interchangeable versus stateful with identity and storage. DaemonSet vs. Deployment: one-per-node versus a fixed replica count you choose. Get those two straight and you will handle the majority of workload questions.
Common KCNA Traps
- Answering “Pod” when the scenario implies production. A bare Pod has no self-healing. If the scenario mentions resilience, scaling, or “keep it running,” it wants a controller, not a Pod.
- Choosing a Deployment for a per-node agent. A Deployment with
replicas: <number of nodes>does not guarantee one Pod per node and does not adapt when nodes join or leave. Node-level agents are always DaemonSets. - Choosing a Deployment for a database. Deployments give random Pod identities and shared update behavior. Databases need stable identity and per-Pod storage — that is StatefulSet.
- Confusing Job and CronJob. A Job runs once; a CronJob runs Jobs on a schedule. “Nightly backup” is a CronJob; “one migration” is a Job.
- Mixing up the API groups. ReplicaSet, Deployment, StatefulSet, and DaemonSet are in
apps/v1; Job and CronJob are inbatch/v1.
Frequently Asked Questions
What is the difference between a Deployment and a StatefulSet?
A Deployment runs stateless, interchangeable Pods with random names and shared storage — ideal for web servers and APIs where any replica can serve any request. A StatefulSet runs stateful Pods that each have a stable, predictable name (app-0, app-1), their own persistent volume that follows them across restarts, and ordered creation and deletion. Use a Deployment when replicas are identical and disposable; use a StatefulSet when each replica has a distinct identity and its own data, such as a database or a clustered message broker.
Why should I use a Deployment instead of creating Pods directly?
A bare Pod is ephemeral and unmanaged — if it or its node fails, nothing recreates it, and there is no scaling or rolling update. A Deployment adds a controller that continuously reconciles desired state: it self-heals failed Pods, scales replicas up and down declaratively, performs rolling updates when you change the image, and lets you roll back to a previous version. In practice you always use a controller in production and reserve bare Pods for quick tests.
When do I use a DaemonSet instead of a Deployment?
Use a DaemonSet when a Pod must run on every node (or every node matching a selector) — typically node-level infrastructure like log collectors, monitoring agents, or networking plugins. A DaemonSet automatically adds a Pod when a new node joins and removes it when the node leaves. A Deployment cannot do this: it maintains a fixed replica count you specify and has no awareness of node membership.
What is the difference between a Job and a CronJob?
A Job runs one or more Pods until they complete successfully and then stops — it is for one-off, run-to-completion tasks like a migration or a backup. A CronJob is a higher-level object that creates Jobs automatically on a repeating schedule defined with cron syntax, such as “every night at 2 a.m.” The relationship is CronJob → Job → Pod. Use a Job for a single run and a CronJob for anything recurring.
What is a ReplicaSet and do I create one directly?
A ReplicaSet is the controller that ensures a specified number of identical Pod replicas are running, using a label selector to identify the Pods it owns. In almost all cases you do not create a ReplicaSet directly — a Deployment creates and manages ReplicaSets for you, adding rolling updates and rollbacks on top. Know that the ReplicaSet provides replication and self-healing, while the Deployment provides update management.
What is the controller pattern in Kubernetes?
The controller pattern is a control loop that continuously compares the desired state declared in an object with the actual state of the cluster and takes action to close the gap — this is called reconciliation. Every workload resource (Deployment, StatefulSet, DaemonSet, Job, CronJob) is built on this pattern; they differ only in what desired state they manage. It is why Kubernetes is declarative: you describe the end state you want, and controllers make and keep it true.
Conclusion and Next Steps
Kubernetes workloads become easy points on the KCNA once you stop memorizing YAML and start matching workload shape to controller. A Pod is a single, unmanaged instance. A Deployment runs stateless replicas with rolling updates and is the default choice. A StatefulSet adds stable identity and per-Pod storage for databases and clustered apps. A DaemonSet puts one Pod on every node for infrastructure agents. A Job runs to completion, and a CronJob runs Jobs on a schedule. Underneath all of them is the same controller pattern reconciling desired state — learn that idea and the individual resources fall into place.
The fastest way to turn this understanding into exam-day reflexes is realistic practice. Sailor.sh’s Kubernetes and Cloud Native Associate (KCNA) Mock Exam Bundle gives you exam-style questions that mirror the real format and difficulty — including the Deployment-vs-StatefulSet and DaemonSet-vs-Deployment distinctions covered here — with detailed explanations that surface the exact concept each question tests. Working through realistic scenarios is the surest way to find your gaps before they cost you points.
Pair the practice with the KCNA study guide, then round out your fundamentals with the Kubernetes object model & kubectl, scheduling & resource management, and services & networking. When you are ready to go hands-on beyond the KCNA’s conceptual level, the CKA workloads & scheduling guide shows how these same objects behave in a performance exam.