AZ-400 Practice Question: Design and implement build and release pipelines
Your organization uses GitHub Actions. You need to create a reusable workflow that builds and tests a Node.js application. Which approach should you use to define the workflow?
⚠ Common exam trap
AZ-400 often tests the confusion between reusable workflows and composite actions, where candidates mistakenly believe a composite action can be called like a workflow or that a standard workflow can be reused without the workflow_call trigger.
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
✓
Define a reusable workflow with 'on: workflow_call'
A reusable workflow in GitHub Actions is defined by placing a workflow file in .github/workflows/ and adding the 'on: workflow_call' trigger. This allows the workflow to be called from other workflows in the same repository or organization, enabling centralized build and test logic. Unlike composite actions, reusable workflows can contain multiple jobs and run on their own runners, making them ideal for orchestrating complex CI/CD pipelines like building and testing a Node.js app.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Define a standard workflow in .github/workflows/build.yml
Why it's wrong here
A standard workflow in .github/workflows/build.yml is triggered by repository events (e.g., push, pull_request) and cannot be invoked from another workflow; to be reusable it must explicitly define the workflow_call trigger, otherwise GitHub Actions treats it as a standalone event-driven workflow.
- ✗
Use a composite action to encapsulate the build steps
Why it's wrong here
A composite action encapsulates multiple run/uses steps into a single step, but it is still just an action, not a workflow—it lacks its own triggers, job-level settings, and cannot be called as a top-level workflow from another repository; it is meant for grouping reusable step logic, not orchestrating jobs.
- ✗
Create a custom action and reference it in multiple workflows
Why it's wrong here
A custom action is a reusable building block referenced via uses: in a step, but a single action is not a complete workflow and cannot define jobs, runners, or the workflow-level trigger (workflow_call); it is intended to be composed inside workflows, not to replace the workflow itself.
- ✓
Define a reusable workflow with 'on: workflow_call'
Why this is correct
Defining a reusable workflow with on: workflow_call is correct because it makes the workflow callable from other workflows using the uses: syntax (e.g., uses: ./.github/workflows/build.yml), allowing you to create a standard build pipeline that can be referenced by many workflows without duplicating job definitions.
Go deeper
Related to this question
Learn chapter
Implementing a Build Pipeline
Key term
Repository
A repository is a central storage location where software packages, code, or configuration files are kept, managed, and distributed for use by IT systems.
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.