AZ-400 Practice Question: Design and implement build and release pipelines
Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?
⚠ Common exam trap
The trap is that `pull_request: types: [closed]` is not the same as 'merged'. A merge to a branch is a push event, not a pull_request event. Candidates may incorrectly choose the `pull_request` trigger, but the correct trigger for a merge is `push`.
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
✓
push: branches: [main]
In GitHub Actions, merging a pull request into `main` results in a `push` event to `main`. The `push` trigger with `branches: [main]` therefore correctly fires whenever a PR is merged. `pull_request: types: [closed]` fires on any PR closure, whether merged or not, so it would deploy even when a PR is closed without merging. To use `pull_request` for merges, you would need an additional `if: github.event.pull_request.merged == true` check, but the question asks for the event trigger alone.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
pull_request: branches: [main]
Why it's wrong here
This trigger fires for every pull request event (opened, synchronized, reopened, etc.) targeting the main branch, not only when the PR is merged. Therefore, it would run CI/CD pipelines on intermediate commits and PR updates, not just on the final merge to main.
- ✗
pull_request: types: [closed] branches: [main]
Why it's wrong here
This trigger uses the `closed` activity type, which fires when a PR is closed. Combined with `branches: [main]`, it ensures the workflow runs only when a pull request targeting main is closed (which includes merged PRs), making it the correct choice for automating tasks on merge to main. Note that `closed` also fires on unmerged PR closures, so you may need to check `github.event.pull_request.merged` if you want strictly merged PRs.
- ✓
push: branches: [main]
Why this is correct
This push trigger activates on any push to the main branch, including direct pushes, force pushes, or pushes from branch creation, not just pushes resulting from a pull request merge. It does not distinguish between a merge commit and a direct push, so it would trigger on all commits pushed to main, violating the requirement to only respond to PR merges.
- ✗
release: types: [published]
Why it's wrong here
This trigger fires when a GitHub Release is published, which is an entirely different event from a pull request merge. It would not run when a PR is merged to main; it only runs when you manually create and publish a release, so it is incorrect for automating actions on PR merge.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
Key term
Check
A Check in Azure DevOps is a gating mechanism that evaluates predefined conditions before allowing a pipeline deployment to proceed to a specific environment.
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 →
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.