Google ACE Practice Question: A platform engineer is deploying a Kubernetes Job…

A platform engineer is deploying a Kubernetes Job that processes a batch of records. The Job should run 10 parallel workers, each processing a subset of records, and complete when all workers finish successfully. Which Job spec configuration achieves this?

⚠ Common exam trap

Google Cloud often tests the distinction between Deployment fields (like `replicas`) and Job-specific fields (like `parallelism` and `completions`), trapping candidates who confuse the two or assume `replicas` applies to Jobs.

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

✓

Set parallelism: 10 and completions: 10 in the Job spec

In Kubernetes, a Job's `parallelism` field specifies the number of Pods that can run concurrently, and `completions` specifies the total number of successful Pod completions required for the Job to be considered finished. Setting both to 10 ensures exactly 10 Pods run in parallel, each processing a subset of records, and the Job completes only when all 10 have succeeded.

Answer analysis

Option-by-option breakdown

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

✗
Set replicas: 10 in the Job spec
Why it's wrong here
`replicas` is a field for Deployments and ReplicaSets, which manage long-running, stateless services; it is not part of the Job's API. A Job spec containing `replicas` would be invalid, and even if it were accepted, `replicas` does not encode the completion criteria that Jobs need. Jobs use `parallelism` to control concurrency and `completions` to declare when the batch is done, so `replicas` is fundamentally the wrong tool for a one-off worker batch.
✓
Set parallelism: 10 and completions: 10 in the Job spec
Why this is correct
Setting `parallelism: 10` and `completions: 10` in a Job spec is exactly the right way to run 10 workers in parallel while ensuring the Job is considered complete only after all 10 Pods have succeeded. `parallelism` controls the maximum number of Pods allowed to run at the same time, and `completions` tells the Job controller how many successful Pod runs are required overall. This is the standard configuration for a deterministic parallel batch job.
✗
Create 10 separate Job objects — one per worker
Why it's wrong here
Creating 10 separate Job objects means managing 10 independent controller lifecycles, each with its own tracking, backoff limits, and cleanup. This approach adds operational overhead and gives you no unified view of the batch as a single unit; if one Job fails, you have to handle it separately, and you cannot rely on a single Job's `completions` count to know when the overall workload is done. A single Job object with `parallelism` and `completions` is the native, self-contained way to run a fixed set of parallel tasks.
✗
Set concurrency: 10 in the Job spec
Why it's wrong here
`concurrency` is not a recognized field in the `batch/v1` Job spec. The Kubernetes API server will reject a Job manifest that contains this field because the schema only supports `parallelism` (for the number of simultaneous Pods) and `completions` (for the total required successes). Using an unknown field means your Job never even gets created, so it cannot satisfy the need to run 10 workers.

Go deeper

Google ACE Practice Question: A platform engineer is deploying a Kubernetes Job…

Why each option matters

Option-by-option breakdown

Related to this question