AZ-400 Practice Question: Design and implement build and release pipelines
Your organization uses GitHub Actions for CI/CD. You want to ensure that the workflow runs only when a pull request is labeled 'safe-to-deploy'. Which trigger should you use?
⚠ Common exam trap
Watch out — candidates often confuse `pull_request` with `pull_request_target` or think that `issue_comment` can detect label changes, but only the `labeled` activity type on `pull_request` directly responds to label additions.
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
✓
on: pull_request: types: [labeled] branches: [main]
The `pull_request` trigger with `types: [labeled]` is the correct event to detect label additions. However, it triggers for any label, not just 'safe-to-deploy'. To ensure the workflow runs only when that exact label is applied, you must combine this trigger with a job-level conditional, e.g., `if: github.event.label.name == 'safe-to-deploy'`. The answer option C is still the correct trigger, but the explanation must clarify this additional required condition.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
on: workflow_run: workflows: ["Build"] types: [completed]
Why it's wrong here
The `workflow_run` trigger fires only after the specified 'Build' workflow completes, not when a label is added to a pull request—it is tied to workflow completion, so a label event would not invoke it. It also evaluates in the context of the default branch rather than the PR head, making it unsuitable for label-based gating.
- ✗
on: issue_comment: types: [created]
Why it's wrong here
The `issue_comment` trigger activates whenever any comment is created on an issue or pull request, but it has no connection to label changes. Label addition is a distinct activity type (`labeled`) on the `pull_request` event, so this trigger would not run when a label is applied.
- ✓
on: pull_request: types: [labeled] branches: [main]
Why this is correct
This is correct because the `pull_request` event supports the `labeled` activity type, and the `branches: [main]` filter scopes it to pull requests targeting the main branch. When a label is added to such a PR, this workflow triggers exactly as intended; note it uses the workflow file from the base branch context for security.
- ✗
on: pull_request_target: types: [opened, synchronize] branches: [main]
Why it's wrong here
While `pull_request_target` does have a `labeled` activity type, this configuration only lists `opened` and `synchronize`, so it will not fire when a label is added. To trigger on labeling, `labeled` must be explicitly included in the `types` list, so this option misses the required event.
Go deeper
Related to this question
Learn chapter
Designing a Release Pipeline
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
Key term
Pull request
A pull request is a way for a developer to propose changes to a codebase and ask other team members to review and merge them into the main project.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.