AZ-400 Practice Question: Design and implement build and release pipelines
Your team uses GitHub Actions to build and deploy a Node.js application to Azure Functions. You need to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and then promotes to production after a manual approval via GitHub Environments. The pipeline must also run unit tests and linting. You want to use the official Azure actions. What should you do?
⚠ Common exam trap
AZ-400 often tests the use of GitHub Environments for approvals versus other approval mechanisms like GitHub Issues or Azure Pipelines approvals; candidates might choose separate workflows or Azure Pipelines, but the question specifies GitHub Actions and manual approval via GitHub Environments.
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
✓
Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.
The correct approach is to create a single GitHub Actions workflow with multiple jobs: one for build and test, one for deploy to staging, and one for deploy to production that uses a GitHub Environment with required reviewers. This allows automatic deployment to staging on push to main, and manual approval for production. The official Azure actions (e.g., azure/functions-action) can be used. Option C is the only one that meets all requirements.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.
Why it's wrong here
Two separate workflows split CI and CD, with the production deployment workflow requiring a manual trigger; however GitHub Actions manual workflow_dispatch does not provide built-in approval/reviewer gates, so it lacks the required environment-based approval control. This also fragments the pipeline and makes release traceability harder.
- ✗
Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.
Why it's wrong here
A single workflow that attempts to pause between staging and production steps by using a condition tied to GitHub Issues cannot actually block execution, because GitHub Actions steps run to completion and cannot wait for external approval events. The platform's supported approval mechanism is an environment with required reviewers, not an issue-based manual gate.
- ✓
Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.
Why this is correct
The correct approach defines one workflow with three jobs: build/test, deploy to staging, and deploy to production; the production job references an environment configured with required reviewers, which automatically pauses the job until approval is granted. This gives a native audit trail and allows environment-specific secrets to be used safely.
- ✗
Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.
Why it's wrong here
Azure Pipelines with multi-stage YAML and pre-deployment approvals is a robust release strategy, but the scenario explicitly states the team is using GitHub Actions, so this answer changes platforms rather than solving the problem. Certifications expect you to recognize the constraint and select a GitHub Actions native solution.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Managing Build Quality and Package Dependencies
Key term
Functions
A function is a reusable block of code that performs a specific task, taking inputs, processing them, and returning a result, helping to organize and automate IT workflows.
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
About these practice questions
This AZ-400 question is part of Courseiva's 696-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.