StatefulSet and DaemonSet are two specialized Kubernetes workload types that go beyond the standard Deployment. Each solves a specific problem that Deployments cannot. This article covers what each one is for, how they differ from Deployments, and how the Associate Cloud Engineer exam tests them.
It does not cover every StatefulSet update strategy, all DaemonSet scheduling rules, or the implementation details of how stable network identity actually works under the hood. The goal is to give you the ACE exam version, which is mostly about recognizing the right workload type for a scenario.
To understand StatefulSet and DaemonSet, you need to understand what a Deployment does first.
A Deployment manages a set of identical, interchangeable pods. It does not matter which pod is which. Pods are like cattle in this model, not pets. If a pod dies, you replace it with a new one and nothing in the system cares about the difference. Deployments are perfect for stateless services like web servers and APIs, where one replica is functionally indistinguishable from another.
StatefulSet and DaemonSet are for cases where pods are not interchangeable. They each handle a different reason why pods might need to be distinguished from each other.
StatefulSet is the answer when pods need stable identity and persistent state.
The classic example is a database. A three-replica database cluster cannot be made of identical pods that just get rescheduled at random. The replicas have distinct roles. They have distinct storage volumes that hold their share of the data. They need stable network identities so other replicas know how to find them. If pod-2 dies and is replaced, the replacement needs to be the new pod-2 with pod-2's storage volume, not a generic new pod with no identity.
StatefulSet handles this. Each pod in a StatefulSet has a stable name like myapp-0, myapp-1, myapp-2. Each pod has its own persistent volume claim, so its storage follows it across restarts and reschedulings. The pods come up in order and shut down in reverse order, so the system maintains consistent state.
You use StatefulSet for databases (PostgreSQL, MongoDB, Cassandra), distributed message queues that maintain state (Kafka, RabbitMQ in cluster mode), and any other workload that needs persistent storage tied to specific replicas.
DaemonSet is the answer when you need a pod running on every node in the cluster, automatically.
The classic examples are node-level agents. A logging agent that collects logs from each node's filesystem. A monitoring agent that scrapes node-level metrics. A network agent that runs as part of a service mesh. A security tool that scans local activity. All of these need to run once per node, not once per cluster, because the work they do is bound to the node they run on.
DaemonSet handles this. When you create a DaemonSet, Kubernetes ensures one copy of the specified pod runs on every node. When a new node joins the cluster, the DaemonSet automatically schedules a pod on it. When a node is removed, the corresponding pod goes away. You never have to manually adjust the count.
You can also restrict a DaemonSet to a subset of nodes using a nodeSelector. For example, only run the GPU monitoring agent on nodes labeled accelerator=nvidia. Without that, every node gets the pod.
Deployment runs N identical pods, scheduled wherever Kubernetes finds room. Pods are interchangeable. Pod count is set explicitly.
StatefulSet runs N pods with stable identities and persistent storage. Each pod is distinct. Pod count is set explicitly. The unit of identity is the pod's ordinal name.
DaemonSet runs one pod per node (or per matching subset of nodes). Pod count is determined by the cluster's node count. Each pod is bound to its node.
The exam tests this through scenario matching.
The first pattern is the database scenario. A team is deploying a stateful database to GKE and needs persistent storage and stable pod identity. The answer is StatefulSet. If you see "database" or "stateful application" or "persistent storage tied to a specific pod," think StatefulSet.
The second pattern is the per-node agent scenario. A team needs to run a logging agent or monitoring agent on every node in the cluster. The answer is DaemonSet. If you see "log collection on every node" or "monitoring agent on each node" or "running on every node automatically," think DaemonSet.
The third pattern is recognizing what NOT to use. A team is deploying a stateless web service. The answer is Deployment, not StatefulSet. StatefulSet adds operational complexity (ordered startup, persistent volume claims, stable identity) that does not benefit a stateless app. The exam sometimes includes StatefulSet as a wrong answer for stateless workloads to test whether you know the difference.
If you see "stateful" or "persistent storage per pod," think StatefulSet. If you see "every node" or "one pod per node," think DaemonSet. If you see "stateless" or "interchangeable replicas," it is a Deployment.
StatefulSet is for stateful applications that need stable identity and persistent storage per pod. DaemonSet is for workloads that need to run on every node automatically. Deployment is the default for everything else.
The Associate Cloud Engineer exam tests this through scenario matching. Identify the constraint (state, per-node, or interchangeable), and the workload type follows directly.
My Associate Cloud Engineer course covers StatefulSet, DaemonSet, and Deployment in the Kubernetes workloads section, alongside the storage and scheduling patterns each one relies on.
