Design and implement build and release pipelines →easyMultiple SelectObjective-mapped

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

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

⚠ Common exam trap

Many exam-takers confuse `pull_request` with `pull_request_target` or forget that `push` and `pull_request` are separate events, leading them to select only one trigger or add irrelevant triggers like `release` or `schedule`.

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

✓

pull_request: branches: [ main ]

The `pull_request` trigger with `branches: [ main ]` ensures the workflow runs when a pull request is opened (or updated) targeting the main branch. Option B is correct because the `push` trigger with `branches: [ main ]` ensures the workflow runs when commits are pushed directly to the main branch. Together, these two triggers cover the exact requirement: changes pushed to main and pull requests opened against main.

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 this is correct
The `pull_request` event triggers the workflow when a pull request is opened, synchronized, or reopened, and the `branches: [ main ]` filter ensures it only runs for PRs whose base branch is `main`. This is the correct choice because it enables CI on proposed changes before merging, catching issues early in the review process while avoiding runs for PRs targeting other branches.
✓
push: branches: [ main ]
Why this is correct
The `push` event triggers the workflow whenever commits are pushed to the `main` branch, which is ideal for continuous integration after a merge or for deploying directly from the main branch. This is correct because it automatically fires on every code change to main, but it does not run for PRs unless the PR is merged, so it complements pull_request-based CI by validating the integrated state.
✗
release
Why it's wrong here
The `release` event triggers only when a GitHub Release is published, created, or edited, which is a manual or externally initiated action rather than an automated response to code changes. It is incorrect here because it would not run for pull requests or pushes, failing to provide continuous integration on every commit or PR targeting main.
✗
workflow_dispatch
Why it's wrong here
The `workflow_dispatch` event is a manual trigger that requires a user to explicitly select and run the workflow from the GitHub Actions UI or via the REST API, with no automatic activation on code changes. It is incorrect because it lacks the automation needed for CI; developers would have to remember to run it after each PR update, which is impractical and error-prone.
✗
schedule
Why it's wrong here
The `schedule` event uses a cron expression to run the workflow at predefined times, such as nightly or hourly, independent of any code changes or pull request activity. It is incorrect because scheduled runs do not validate the latest commit in real-time; they only execute at fixed intervals, so they cannot serve as the primary continuous integration trigger for PRs targeting main.

Go deeper

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

Why each option matters

Option-by-option breakdown

Related to this question