Design and implement build and release pipelines →mediumMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

You are implementing a release pipeline that deploys a web app to Azure App Service. The deployment must be approved by a manager before proceeding to the production slot. However, the manager is on leave and the deployment is critical. What should you do to ensure the deployment can proceed without delaying the release?

⚠ Common exam trap

Candidates often think skipping or removing the approval is acceptable for a critical release, but Azure DevOps enforces governance; the correct approach is to add an additional approver to maintain control while enabling progress.

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

✓

Add an additional approver in the pre-deployment approval settings.

Adding an additional approver in the pre-deployment approval settings allows another authorized user (e.g., a backup manager or team lead) to approve the deployment while the primary manager is unavailable. This maintains the required governance and security controls without blocking the critical release. Azure Pipelines supports multiple approvers, and any one of them can approve to proceed.

Answer analysis

Option-by-option breakdown

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

✗
Skip the approval for this deployment by overriding the settings.
Why it's wrong here
Overriding the approval setting bypasses the configured governance gate and any audit trail, so while Azure DevOps may allow a user with Manage deployments permission to skip it, this contradicts the safety and compliance controls the approval was designed to enforce. Skipping approval violates the defined release process and should only be considered in extreme emergencies with explicit justification.
✓
Add an additional approver in the pre-deployment approval settings.
Why this is correct
Adding an additional approver in the pre-deployment approval settings ensures that if the primary approver is unavailable, a designated backup can review and approve the release, allowing the deployment to proceed without delay. This maintains the required human gate and auditability, unlike skipping or auto-approving, making it the correct approach to handle approver unavailability.
✗
Configure the approval to time out after 24 hours and automatically approve.
Why it's wrong here
Configuring the approval to time out after 24 hours and automatically approve means that if the designated approver does not respond, the release will be deployed without their review, effectively bypassing the security checkpoint. This auto-approval on timeout violates compliance and security policies because it allows code to reach production without explicit human authorization, and a missing approval often indicates a problem that should not be ignored.
✗
Remove the approval requirement from the pipeline.
Why it's wrong here
Removing the approval requirement from the pipeline permanently deletes the pre-deployment gate, leaving the release process with no human oversight for all future deployments. This weakens the overall release governance, increases the risk of unauthorized or unreviewed changes reaching production, and is not a valid solution to an unavailable approver because it would permanently alter the pipeline's security posture.

Visual reference

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Why each option matters

Option-by-option breakdown

Related to this question