Requiring Staging Success and Senior Approval Before Production
Your organization uses GitHub Actions for CI/CD. You need to ensure that deployment to production only occurs after a successful deployment to a staging environment and requires approval from a senior developer. The deployment workflow is defined in a single YAML file. What is the most efficient way to achieve this?
Quick Answer
GitHub Actions environments with required reviewers are built for exactly this: define separate staging and production environments, deploy to staging first with a conditional step, then let the production environment's required-reviewer protection rule hold the job until a senior developer approves. It's all native to Actions — no external webhook or manual trigger needed to enforce the staging-then-approval order.
⚠ Common exam trap
A common mix-up: candidates think a build matrix or manual trigger is sufficient, but they overlook the need for sequential deployment and built-in approval gating, which is exactly what GitHub Environments with required reviewers provide.
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 two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.
GitHub Actions supports deployment environments with required reviewers. By defining separate 'staging' and 'production' environments, you can use a conditional step to deploy to staging first, and then require manual approval from a senior developer before the production deployment proceeds. This approach is built into GitHub Actions and does not require external webhooks or manual workflow triggers, making it the most efficient and secure method.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a step that pauses the pipeline until a manual approval is received via a custom webhook.
Why it's wrong here
Implementing a custom webhook requires external infrastructure and manual logic to manage the pause state, whereas GitHub Environments provide native deployment protection rules. This approach is intended for integrating third-party orchestration tools that exist outside of GitHub's built-in workflow engine. You would use webhooks if your approval process required validation from an external system, such as a bespoke security scanning tool or a custom ticketing platform integrated with Microsoft Entra ID.
- ✗
Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.
Why it's wrong here
Manual trigger does not enforce staging deployment first.
- ✗
Use a build matrix to run staging and production deployments in parallel.
Why it's wrong here
Matrix builds run all jobs simultaneously, not sequentially.
- ✓
Use two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.
Why this is correct
Environment protection rules enforce approvals, and conditional steps ensure order.
Go deeper
Related to this question
Learn chapter
Implementing Deployment Patterns and Strategies
Key term
GitHub
GitHub is a cloud-based platform for storing, tracking, and collaborating on code using Git version control.
Key term
Environment
An environment is a dedicated set of computing resources, configurations, and services used to develop, test, or host software applications in a controlled and repeatable way.
About these practice questions
This AZ-400 question is part of Courseiva's 823-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 →
Same concept, more angles
3 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You need to ensure that a release pipeline in Azure Pipelines automatically deploys to production only if the deployment to staging succeeds and all manual intervention checks pass. What is the best way to configure this?
easy- ✓ A.Add a pre-deployment approval gate on the production stage
- B.Configure a branch policy on the main branch
- C.Assign a deployment group to the production stage
- D.Add a post-deployment approval gate on the staging stage
Why A: A pre-deployment approval gate on the production stage is the standard and direct way to require manual approval before deploying to production. Because the pipeline executes stages sequentially, production only runs after staging succeeds, ensuring the 'deployment to staging succeeds' condition automatically. The manual intervention checks are fulfilled by the pre-deployment approval. While a post-deployment approval on staging could also block progress to production, it is not the 'best' or only correct answer; it is less directly tied to protecting the production environment.
Variation 2. You have a release pipeline that deploys to multiple environments. You need to ensure that a manual approval is required before deploying to production. What should you configure?
medium- A.Add a manual intervention task in the production stage
- B.Set a post-deployment approval on the production stage
- ✓ C.Set a pre-deployment approval on the production stage
- D.Set a branch policy on the release branch
Why C: Pre-deployment approvals are configured on a stage in Azure Pipelines to require manual sign-off before any deployment to that stage begins. Since the question specifies that approval is needed before deploying to production, a pre-deployment approval on the production stage enforces that gate before the release pipeline executes any deployment tasks in that environment.
Variation 3. You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?
hard- A.Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.
- ✓ B.Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.
- C.Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.
- D.Use a classic release pipeline with pre-deployment approvals on the production stage.
Why B: A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.
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.