CKAD Application Deployment Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  DaemonSet

  Why it's wrong here

  A DaemonSet guarantees a pod copy runs on every node (or a subset) and is intended for long-running infrastructure components like log shippers or health probes, not for one-off tasks. Deploying a batch job as a DaemonSet would start the container on potentially many nodes simultaneously and there is no controller logic to treat a successful pod exit as a completed task—the pod would be restarted or remain failed. The batch's expectation of running once and exiting successfully is therefore fundamentally at odds with DaemonSet's per-node, continuous execution model.

• ✗

  Deployment

  Why it's wrong here

  Deployment manages a replica set of pods that are meant to run indefinitely, with a desired state that is continuously maintained through restarts, scaling, and rolling updates. A batch job is by definition transient: it should run to completion and then exit with a zero status. If wrapped in a Deployment, the pod's exit would be seen as a crash, triggering an automatic restart with backoff, so the work would either never be acknowledged as complete or would loop unexpectedly. Deployment is appropriate for stateless web services, not finite batch workloads.

• ✓

  Job

  Why this is correct

  A Job creates one or more pods and tracks them until a specified number of successful completions are reached, which exactly matches the semantics of a batch operation. The Job controller uses a restart policy of Never or OnFailure, and it implements backoff limits, active deadlines, parallelism, and completion counts to govern how failed pods are retried. This allows the developer to express 'run this container once' and have Kubernetes guarantee the task eventually ends in a completed state, or fail according to policy. Hence, for a container that runs a batch job and exits, Job is the correct workload controller.

• ✗

  StatefulSet

  Why it's wrong here

  StatefulSet is designed for stateful applications that require stable unique network identifiers, persistent storage per instance, and ordered scaling/termination—characteristics of databases, key-value stores, or other clustered services. A batch job typically has no such needs: it is stateless, requires no stable identity, and is expected to terminate when the work is done. Using a StatefulSet would force the batch container to be treated as a long-lived, replicated service, and because the controller expects pods to stay alive, the successful completion of a batch workload would be misread as a failure. StatefulSet therefore adds unnecessary complexity and breaks the job-completion model.

Go deeper

Related to this question