CKAD Application Design and Build 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.

• ✗

  replicas

  Why it's wrong here

  The Job spec does not define a replicas field because a Job is a controller designed to run a batch task to completion rather than maintain a stable set of running Pods. Replicas belongs to long-running workload controllers like Deployments or ReplicaSets, where the controller ensures a desired number of Pods are always available. In a Job, the desired number of successful completions is expressed via completions, and concurrency is controlled by parallelism, not replicas. Including replicas in a Job spec would be rejected by the API server as an invalid field.

• ✓

  backoffLimit

  Why this is correct

  backoffLimit is a valid field in the Job spec that determines how many retries the Job controller will attempt before marking the Job as failed. Each time a Pod fails, the controller increments the failure count, and when that count exceeds backoffLimit, the Job is considered failed and no further Pods are created. The default value is 6, and setting it to 0 means the Job fails immediately after the first unsuccessful Pod. This field works in conjunction with activeDeadlineSeconds and pod failure policies to control batch job resilience.

• ✗

  schedule

  Why it's wrong here

  The schedule field is not part of a Job spec; it belongs to the CronJob spec, which defines a cron expression for creating Jobs on a recurring basis. A bare Job is a one-off task that runs once and has no time-based scheduling mechanism. To run a Job periodically, you must wrap it in a CronJob object, which uses its schedule field to create Jobs automatically. In the Job spec itself, there is no field for time-based triggering; only the pod template and completion/parallelism parameters are defined.

• ✗

  restartPolicy

  Why it's wrong here

  restartPolicy is a field within the Pod template that is nested inside the Job spec, not a direct field of the Job spec object. The Job spec contains a podTemplate field, and restartPolicy is set there, but the Job spec itself does not have this field. For Jobs, restartPolicy must be either Never or OnFailure to allow the Job controller to manage Pod termination correctly; Always is disallowed because it would prevent Pods from being considered as failed or completed. Therefore, restartPolicy is not a valid field at the Job spec level.

• ✓

  parallelism

  Why this is correct

  parallelism is a valid Job spec field that specifies the desired number of Pods the Job should run concurrently during execution. If parallelism is unset, the Job runs one Pod at a time, but when multiple completions are required, setting parallelism greater than 1 can speed up batch processing. The Job controller creates up to parallelism Pods simultaneously, and the total number of successful Pods needed is defined by completions. This field is part of the Job spec's spec section, helping balance throughput and resource utilization for batch workloads.

Go deeper

Related to this question