Two Tasks That Keep a Docker Build Current and Cache-Accelerated
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.
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
Key term
Azure Pipelines
Azure Pipelines is a cloud-based CI/CD service from Microsoft that automatically builds, tests, and deploys code to any platform or cloud.
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
About these practice questions
This AZ-400 question is part of Courseiva's 696-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 →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?
easy- ✓ A.Use a conditional step that runs only when the build succeeds to tag the image as 'latest'
- B.Use the build ID as the tag and manually update 'latest'
- C.Use the Git commit hash as the tag and push 'latest' separately
- D.Always tag the image as 'latest' regardless of build status
Why A: It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.
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.