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

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

You are setting up a GitHub Actions workflow to deploy an Azure Resource Manager (ARM) template. The workflow must run whenever a pull request is opened against the main branch. Which trigger should you use?

⚠ Common exam trap

Candidates often confuse `pull_request_target` with `pull_request`. `pull_request_target` runs in the context of the base repository and has access to secrets, but it should be used with extreme caution because it can be exploited via malicious PRs. `pull_request` is the standard, safer trigger for PR events and does not expose secrets to untrusted forks; however, it also does not allow access to secrets for fork PRs without additional mechanisms.

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] types: [opened]

The `pull_request` trigger with `branches: [main]` and `types: [opened]` ensures the workflow runs only when a pull request targeting the `main` branch is newly opened. This is the correct trigger for the stated requirement. Note that `pull_request` events from forks run with limited permissions and do not have access to repository secrets by default, which is a safety measure. If secrets are required for deployment, additional configuration such as using `pull_request_target` (with caution) or environment-scoped secrets would be necessary, but the trigger itself remains `pull_request`.

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] types: [opened]
Why this is correct
This trigger fires automatically when a pull request targeting the main branch is opened, using the code from the pull request's merge commit rather than the base branch. It is the correct choice for deploying the ARM template proposed in the PR, because it runs as a pre-merge validation and uses the PR's changes.
✗
pull_request_target: branches: [main]
Why it's wrong here
`pull_request_target` is incorrect because it executes the workflow in the context of the *base* branch, utilising its code and elevated permissions, rather than the code from the pull request itself. Consequently, it would deploy the ARM template already present in the `main` branch, not the template proposed within the pull request. This option is tempting due to its name, but it is designed for scenarios requiring base repository write access, such as labelling pull requests or deploying trusted code from maintainers, where the `GITHUB_TOKEN` needs elevated permissions.
✗
workflow_dispatch
Why it's wrong here
The workflow_dispatch event requires manual invocation from the GitHub UI or API, so it will never execute automatically in response to a pull request opening. Because the requirement is an automatic deployment when a PR is opened, this trigger does not satisfy it.
✗
push: branches: [main]
Why it's wrong here
A push trigger on the main branch fires only after commits are directly pushed to main, not when a pull request is opened. Thus it would deploy the ARM template that already exists in main, ignoring any changes proposed by the PR, and is not the correct trigger.

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