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

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

Exhibit

Refer to the exhibit.

```yaml
# GitHub Actions workflow snippet
name: CI
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          if [ "${{ github.event_name }}" == "pull_request" ]; then
            echo "Running PR tests"
          fi
```

Refer to the exhibit. A developer creates a pull request from a branch called 'feature/update'. The workflow runs on the pull_request event. What will the output of this workflow be?

⚠ Common exam trap

It's easy for candidates to assume a workflow only runs on the default branch or that branch names like 'feature/update' are excluded, but GitHub Actions `pull_request` events fire for any source branch unless explicitly filtered with `branches` or `paths`.

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

✓

The workflow will run and output 'Running PR tests'.

The workflow is triggered on the `pull_request` event, which fires for any pull request regardless of the source branch name. The condition `github.event_name == 'pull_request'` evaluates to `true` because the event is indeed a pull_request. Therefore, the `if` condition passes, and the step runs, outputting 'Running PR tests'.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The workflow will not run because the branch is not 'main'.
Why it's wrong here
The `pull_request` event triggers based on the target (base) branch, not the source branch; as long as the PR targets `main`, the workflow runs regardless of the head branch's name. Since no `branches:` filter excludes non-main heads, the workflow will run.
✓
The workflow will run and output 'Running PR tests'.
Why this is correct
The workflow is configured with the `pull_request` event, so it runs when a PR is opened or updated. The `if` condition `github.event_name == 'pull_request'` is true for this event, so the echo step executes and outputs 'Running PR tests'.
✗
The workflow will run but output nothing because the condition fails.
Why it's wrong here
The condition will not fail: when a workflow is triggered by a `pull_request` event, the `github.event_name` context is literally the string `pull_request`. Therefore `github.event_name == 'pull_request'` evaluates to `true`, not `false`. The `if` check is performed on every step, and since the event matches exactly, the step executes and prints 'Running PR tests'. There is no reason for the step to be skipped or produce no output.
✗
The workflow will fail due to a syntax error in the conditional expression.
Why it's wrong here
The expression is not a syntax error. In GitHub Actions, an `if` conditional is evaluated as an expression automatically, so the comparison `github.event_name == 'pull_request'` is a valid Boolean expression. The YAML value is a plain string, not a broken construct, and GitHub Actions parses it correctly. Since the expression is syntactically valid and evaluates to `true` for a pull_request event, the workflow proceeds normally and the echo command runs.

Go deeper

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

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question