Question 665 of 823
AZ-400 Configure processes and communications Practice Question
Your organization uses GitHub for source control and GitHub Actions for CI/CD. You need to implement a branching strategy where every commit to the main branch triggers a build and deployment to a staging environment, but only after a successful pull request review. Which GitHub Actions trigger should you use?
⚠ Common exam trap
The trap is confusing pull_request closed with merge. A PR can be closed without merging, so types: [closed] does not guarantee a successful review and merge. The correct event for new commits on a branch 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 with branches: [main]
The `push` trigger with `branches: [main]` runs on every commit pushed to main. When branch protection requires pull request reviews, commits only reach main through a reviewed and merged PR, so this satisfies the 'only after successful pull request review' condition. In contrast, `pull_request_target` with `types: [closed]` triggers for any closed PR, including those not merged, and does not map one-to-one to commits on main. To use a PR event, you would need an additional condition like `if: github.event.pull_request.merged == true`, which is not mentioned.
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_target with branches: [main] and types: [closed]
Why it's wrong here
This trigger fires when a PR is closed (merged) into main, ensuring review was completed.
- ✓
push with branches: [main]
Why this is correct
The push trigger on main fires for every commit pushed directly to the branch, including fast-forward merges and direct pushes, without requiring a pull request, so it cannot enforce branch protection review policies. This means unreviewed changes can trigger the workflow, unlike pull_request_target which only fires on the closed event after a PR is merged.
- ✗
pull_request with branches: [main]
Why it's wrong here
The pull_request trigger fires when a pull request is opened, synchronized, or reopened, and by default does not fire on the merge/close event unless you explicitly specify types: [closed]. Even with types: [closed], it runs in the context of a merge commit and may not have access to secrets in the same way as pull_request_target, but without specifying closed it only runs during PR lifecycle, not at completion.
- ✗
workflow_dispatch
Why it's wrong here
The workflow_dispatch event requires a user to manually trigger the workflow via the GitHub UI, API, or CLI, so it cannot automatically enforce that all merges to main run the workflow. This makes it unsuitable for a required validation that must run on every PR merge, as it depends on human action rather than the merge event.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 25, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.