A single stage in a YAML pipeline defines three jobs named Lint, UnitTest, and SecurityScan. As written, each job lists the previous one in its dependsOn, so they run strictly one after another and the stage takes far longer than necessary. The three jobs share no outputs and can run independently. The team wants all three to start at the same time on separate agents to shorten the stage, without splitting them into separate stages. Which change makes the three jobs run concurrently?
- AAdd a matrix strategy to the stage that lists the three job names, so the platform expands them into parallel copies and runs Lint, UnitTest, and SecurityScan side by side on separate agents.
- BSet maxParallel on the stage to three, which raises the concurrency limit so the existing dependsOn chain is allowed to dispatch all three jobs at the same time once enough agents are free.
- CAdd a condition of succeeded to each job so the platform recognises the jobs are independent and schedules Lint, UnitTest, and SecurityScan together rather than waiting for the prior job in the chain.
- DRemove the dependsOn entry from each job so none of them declares a dependency, which lets all three jobs start at once on separate agents because jobs in a stage run in parallel when nothing forces an order. Correct
Why A is wrong: A matrix strategy is defined on a single job to fan one job into parallel variants by variable values, not on a stage to parallelise three distinct jobs, so it tempts with the word parallel but does not apply to differently named jobs.
Why B is wrong: A maxParallel limit caps how many already-eligible items run at once and never overrides an explicit dependsOn ordering, so a chained set of jobs stays serial no matter how high the limit is set.
Why C is wrong: A succeeded condition controls whether a job runs based on prior results but does not change dependency order, so with the dependsOn chain intact the jobs still run one after another rather than concurrently.
Why D is correct: Jobs in a stage run in parallel by default; the only thing serialising them is the dependsOn chain, so clearing each job's dependency lets all three start together on separate agents, which is the requested behaviour with no extra stages.