AZ-400 Configure processes and communications Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use the 'pull_request' event and the 'actions/assign' action to assign the issue.

  Why it's wrong here

  The 'pull_request' event fires when a pull request is opened, updated, or merged, but it does not fire when an issue is closed. Moreover, the 'actions/assign' action is not an official GitHub Action, and pull request events provide no direct context about the issue being closed or its author, so this approach cannot reliably assign the closed issue.

• ✓

  Use the 'issues' event with 'closed' type and an action that assigns the issue to the PR author.

  Why this is correct

  The 'issues' event with type 'closed' is the appropriate trigger because GitHub Actions fires it synchronously when an issue is closed, providing the issue payload directly. A workflow can then invoke the GitHub API (or a purpose-built action) to inspect the issue timeline, locate the 'cross-referenced' event pointing to the pull request that closed it, and fetch that PR's author for assignment. This reacts in real time without polling and does not require external state tracking.

• ✗

  Use the 'push' event and call the GitHub API to assign the issue.

  Why it's wrong here

  A 'push' event occurs when commits are pushed to a repository branch, not when issues transition to 'closed'. Even if you called the GitHub API from a push-triggered workflow, you would have no built-in trigger metadata identifying which issue closed or which PR closed it, so you would need to add brittle, external logic to infer the issue and its author.

• ✗

  Use the 'schedule' event to periodically check for closed issues and assign them.

  Why it's wrong here

  A 'schedule' event triggers workflows on a cron timetable, independent of issue activity, so it would only allow polling for recently closed issues after the fact. This is inefficient (you pay for constant workflow runs), introduces latency between closure and assignment, and requires extra state tracking to avoid duplicate or delayed assignments instead of reacting immediately to the 'issues' event.