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

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

Exhibit

resources:
  repositories:
    - repository: internal
      type: git
      name: MyProject/MyRepo
      ref: refs/heads/main
      trigger:
        branches:
          include:
            - main
            - release/*

pool:
  vmImage: 'ubuntu-latest'

steps:
  - checkout: self
  - checkout: internal
  - script: echo "Building..."

Refer to the exhibit. A developer creates a pipeline with this YAML. When a commit is pushed to the 'main' branch of the repository 'MyProject/MyRepo', the pipeline does NOT trigger. Which is the most likely cause?

⚠ Common exam trap

A common mix-up: candidates assume the YAML 'trigger' block alone is sufficient to enable CI for any repository type, but Azure Pipelines requires an additional UI-based trigger enablement for internal Azure Repos, which is a subtle but critical distinction.

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

✓

The 'internal' repository trigger requires a pipeline trigger to be enabled in the UI.

When using the 'internal' repository type in Azure Pipelines YAML, the pipeline must have a 'Pipeline trigger' explicitly enabled in the UI settings. The YAML 'trigger' branch specification alone is insufficient for 'internal' repositories; the UI trigger acts as a required gate. Without this UI setting, commits to 'main' will not initiate the pipeline.

Answer analysis

Option-by-option breakdown

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

✗
The 'checkout: internal' step should use a different syntax.
Why it's wrong here
The syntax 'checkout: internal' is exactly how you consume a repository resource in an Azure Pipelines YAML by its alias, in this case 'internal'. There is no alternative syntax needed for a repository resource named 'internal'; 'checkout: none' would skip the resource, while 'checkout: self' would check out the source repository. Thus the step itself is valid and this option does not explain the pipeline failure.
✗
The 'ref' property should be set to a commit SHA, not a branch name.
Why it's wrong here
The 'ref' property for a repository resource trigger is not required to be a commit SHA; it can be a branch name, tag, or ref. In fact, using a fixed commit SHA would make the trigger static and prevent new commits on that branch from initiating pipeline runs. Branch names are the standard way to specify which branch should trigger the pipeline, so this option is incorrect.
✗
The branch specification 'main' is case-sensitive and should be 'Main'.
Why it's wrong here
Git branch names are case-sensitive in Azure Repos, and the repository's default branch here is lowercase 'main'. Changing the branch specification to 'Main' would cause the pattern to match a nonexistent branch, so no triggers or checkouts would occur. Since the YAML already uses lowercase 'main' consistently, the existing configuration is correct and this proposed change is wrong.
✓
The 'internal' repository trigger requires a pipeline trigger to be enabled in the UI.
Why this is correct
For a repository resource trigger to fire, the pipeline's overall Continuous Integration trigger must be enabled in the Azure DevOps UI, not just the YAML trigger under 'resources'. When the CI trigger is turned off, Azure Pipelines ignores both the pipeline-section branch filters and the repository resource trigger configurations. Because the pipeline trigger may be disabled in the UI, this statement identifies the actual root cause and is therefore correct.

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