Design and implement build and release pipelines →hardMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

{
  "triggers": [
    {
      "branchFilters": ["main", "develop"],
      "paths": {
        "include": ["/src/*"],
        "exclude": ["/src/tests/*"]
      },
      "batchChanges": true,
      "maxConcurrentBuildsPerBranch": 1,
      "triggerType": "continuousIntegration"
    }
  ]
}

Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?

⚠ Common exam trap

Watch out — candidates often confuse `batchChanges` with `maxConcurrentBuildsPerBranch`, thinking that batching affects concurrency limits, or mistakenly believe that modifying multiple folders in a single commit triggers multiple builds.

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

✓

1 build, because batchChanges is true.

The trigger configuration has `batchChanges` set to `true`. When `batchChanges` is enabled, Azure Pipelines groups all commits that arrive while a build is in progress into a single build, rather than triggering a separate build for each commit. In this scenario, the developer pushes a single commit that modifies files in both `/src/app/` and `/src/tests/`. Since `batchChanges` is true, only one build is triggered for that commit, regardless of the number of modified folders.

Answer analysis

Option-by-option breakdown

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

✓
1 build, because batchChanges is true.
Why this is correct
With batchChanges set to true, all commits and file changes from a single push are coalesced into one build invocation; you don't get a separate build per modified file or folder. Because at least one changed path matches an include pattern, the pipeline queues exactly one batched build for that change set.
✗
0 builds, because the excluded path takes precedence.
Why it's wrong here
The excluded path does not blindly outrank included paths; Azure Pipelines evaluates the set of changed files against the include/exclude filters as a whole. A build is triggered whenever any changed file matches an include, even if other files match an exclusion. Since the change set contains an included path, the excluded path cannot suppress the build, so zero builds is impossible.
✗
3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.
Why it's wrong here
maxConcurrentBuildsPerBranch controls the maximum number of builds that can run simultaneously for a branch, not the number of builds triggered by a single push. Setting it to 1 means one build runs at a time; any additional triggered builds would wait in the queue, but batchChanges already consolidates all changes from the same push into a single build. Therefore, the concurrency limit does not multiply the trigger count to three.
✗
2 builds, one for each modified folder.
Why it's wrong here
The trigger is branch-conditioned and path-filtered, but it does not iterate over folders and create one build per folder; a single push is processed as one event. When batchChanges is enabled, every change in that push is folded into one build, so having changes in two modified folders does not yield two builds. This option confuses path filtering (which merely includes or excludes files) with build-per-path semantics.

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question