Courseiva
Design and implement build and release pipelineseasyMultiple ChoiceObjective-mapped

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

Your team uses Azure Pipelines for CI/CD. The pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that only the main branch triggers a build of the Docker image. What should you configure in the pipeline YAML?

⚠ Common exam trap

Many exam-takers confuse CI triggers (`trigger`) with PR triggers (`pr`) or try to use job-level conditions to filter branches, not realizing that conditions only skip job execution but still trigger the pipeline, wasting resources and potentially causing unintended side effects like failed runs or unnecessary ACR pushes.

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 'trigger: branches: include: - main'

Setting `trigger: branches: include: - main` in the pipeline YAML configures a CI trigger that only starts a new pipeline run when changes are pushed to the `main` branch. This ensures that the Docker image build and push to ACR occurs exclusively for the main branch, meeting the requirement.

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 'pr: branches: include: - main'

    Why it's wrong here

    The `pr` key configures pull request validation triggers, not continuous integration triggers; it determines when the pipeline runs for PRs targeting the specified branches, but it has no effect on CI builds triggered by commits to a branch. To restrict CI builds on push, you must use the `trigger` key, so this setting would leave the default CI behavior unchanged.

  • Add a condition: 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' to the job.

    Why it's wrong here

    Adding a job condition such as `eq(variables['Build.SourceBranch'], 'refs/heads/main')` only prevents the job from running when the source branch is not main, but the pipeline run itself is still triggered on every branch push. This avoids executing the job on non-main branches, yet it still creates pipeline runs, consumes resources, and does not limit the trigger at the pipeline level.

  • Set 'trigger: branches: include: - *'

    Why it's wrong here

    Setting `trigger: branches: include: *` explicitly includes all branches in the CI trigger, meaning the pipeline will start on pushes to any branch—the exact opposite of the desired restriction. Since the default behavior (when no trigger is specified) already triggers on all branches, this configuration provides no filtering and fails to limit builds to main.

  • Set 'trigger: branches: include: - main'

    Why this is correct

    Setting `trigger: branches: include: - main` defines the CI trigger to fire only on commits pushed to the `main` branch. This ensures that pushes to feature or other branches do not create pipeline runs, while any commit to `main` correctly starts a new CI build, satisfying the requirement to restrict builds to the main branch.

About these practice questions

This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.