Creating a GitHub Issue Automatically When an Azure Pipelines Build Fails
Your team uses GitHub Issues for tracking bugs and features. They want to automatically assign issues to the person who created the pull request that closes the issue. Which GitHub Actions workflow trigger and action should you use?
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
✓
Use the 'issues' event with 'closed' type and an action that assigns the issue to the PR author.
The 'issues' event with 'closed' type triggers a workflow when an issue is closed, and the 'actions/github-script' action can be used to assign the issue to the pull request author by querying the pull request that closed the issue. Option A is incorrect because the 'pull_request' event does not directly close issues; closing an issue is done via a commit or pull request merge. Option C is incorrect because the 'push' event is not related to issue closure. Option D is incorrect because the 'schedule' event is time-based and does not respond to issue closures.
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.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-400 question from scratch — 696 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.