A library CDN caching proxy must run on every worker node and appear automatically when the cluster adds a node. Which workload should the application team use?
Select an answer to reveal the explanation.
Short Explanation
Picture a fire extinguisher on every floor: when the building adds a floor, you want one mounted automatically. A DaemonSet is that rule for nodes—new node, new Pod.
Full Explanation
A library CDN caching proxy that must run on every worker node and appear automatically when the cluster adds a node should be implemented as a DaemonSet. The DaemonSet controller ensures each eligible node gets one Pod without manual replica arithmetic, keeping caches local to library traffic on those nodes as the municipal cluster grows or shrinks during capacity events.
A Deployment scaled to the current node count and then left unchanged goes stale the moment autoscaling or operations adds workers—new nodes will not automatically receive the proxy. A single Job that places one Pod and then exits leaves the fleet uncovered after completion and never tracks node join events. A CronJob that recreates the proxy once a night only provides periodic Pods, not continuous per-node coverage for a caching layer citizens hit throughout the day.
Exam caveat: Whenever the question emphasizes “every node” plus automatic coverage “when nodes are added,” DaemonSet is the intended workload. Remember tolerations and node selectors for tainted or specialized library edge nodes.
Operational check: kubectl get ds library-cdn -o wide; kubectl get pods -o wide -l app=library-cdn and verify one Pod per node; add a node in a lab cluster and confirm a new Pod appears without changing any replicas field.