Courseiva
Workloads and Scheduling →mediumMultiple Select

CKA Workloads and Scheduling Practice Question

Which TWO statements about DaemonSets are correct? (Select 2)

⚠ Common exam trap

It's easy for candidates to confuse DaemonSets with Deployments, mistakenly thinking DaemonSets have a replica count or are managed by a Deployment, or that they lack update strategies, when in fact DaemonSets are independent and fully support rolling updates.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

DaemonSets are often used for cluster daemons like log collectors or monitoring agents.

Option C is correct because DaemonSets are designed for node-level cluster services such as log collectors (e.g., Fluentd/Fluent Bit), monitoring agents (e.g., node-exporter), and CNI/storage daemons, where one pod per node is needed. Option E is correct because a DaemonSet's core behavior is to ensure that all nodes, or a subset selected via nodeSelector/affinity/tolerations, run a copy of a specified pod, with new nodes automatically getting the pod. Option A is incorrect because DaemonSets are standalone controllers managed directly by the DaemonSet controller, not by a parent Deployment. Option B is incorrect because DaemonSets do support rolling updates via updateStrategy: RollingUpdate (with maxUnavailable), as well as OnDelete. Option D is incorrect because DaemonSets do not use a desired replica count like Deployments or ReplicaSets; their pod count is determined by the number of matching nodes.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    DaemonSets are typically managed by a parent Deployment.

    Why it's wrong here

    DaemonSets are independent API objects managed by their own controller in the kube-controller-manager. They are not subordinate to Deployments; a Deployment owns ReplicaSets, which own Pods with a maintained replica count. A DaemonSet directly creates and manages Pods on targeted nodes without any Deployment parent, so this statement contradicts Kubernetes ownership and controller mechanics.

  • ✗

    DaemonSets do not support rolling updates.

    Why it's wrong here

    DaemonSets fully support rolling updates via the `.spec.updateStrategy` field, with `RollingUpdate` as the default strategy. The DaemonSet controller replaces Pods node-by-node, honoring `maxUnavailable` and `maxSurge` to control disruption; the alternative `OnDelete` strategy updates Pods only after manual deletion. Thus, claiming no rolling update support is incorrect.

  • ✓

    DaemonSets are often used for cluster daemons like log collectors or monitoring agents.

    Why this is correct

    DaemonSets are the standard mechanism for running system-level services that need to be present on every node, such as log collectors (e.g., Fluentd), monitoring agents (e.g., Prometheus Node Exporter), and network components (e.g., kube-proxy, CNI plugins). Because these daemons provide cluster-wide functionality, they must be automatically scheduled on each node and removed when the node leaves, which is exactly what a DaemonSet guarantees.

  • ✗

    DaemonSets have a desired number of replicas that the scheduler tries to maintain.

    Why it's wrong here

    DaemonSets have no `spec.replicas` field or desired replica count; instead, the DaemonSet controller calculates the desired number of pods from the nodes selected by the DaemonSet's node selector, node affinity, and tolerations. The controller creates a pod for every selected node, and if a node is added or removed, the pod count adjusts automatically. The scheduler is not maintaining a static replica count; rather, the DaemonSet controller ensures per-node pod placement.

  • ✓

    DaemonSets ensure that all (or some) nodes run a copy of a pod.

    Why this is correct

    A DaemonSet is designed to run exactly one pod on all nodes that match its node selector, or on every node if no selector is specified. This guarantees cluster-wide coverage for infrastructure services, automatically handling node additions, deletions, and updates. The phrase 'all (or some) nodes' accurately captures the selective behavior enabled by node selectors and affinity rules, making this a correct definition.

About these practice questions

This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.