Implement a manual approval gate for production deployment in pipeline-as-code
This tests embedding human governance in automated pipelines with auditability. A strong answer covers environment-scoped approvals, timeouts, RBAC, and immutable logs. Red flag: Ad-hoc manual deploys outside the pipeline or missing rollback plans.
What's really being asked
The interviewer wants to know if you understand that manual approval is not an escape hatch from automation but a controlled, auditable stage within it. They are looking for governance patterns that prevent unilateral production changes while keeping the pipeline as the single source of truth. This includes identity, authorization, timeouts, observability, and failure handling.
The full answer
First, define the gate in code, not in a side channel. In Azure Pipelines this means using pre-deployment conditions or environment protection rules; in GitHub Actions or GitLab CI it means environment reviewers or protected environments. Second, bind the approval to identity and least-privilege RBAC so only specific users or groups can grant approval, and require that the approver is not the same person who triggered the deployment. Third, set technical boundaries: a timeout so the deployment does not wait indefinitely, an escalation path such as paging an on-call rotation, and a re-evaluation policy if health signals change while waiting. Fourth, ensure auditability by logging who approved, when, and under what pipeline run ID, storing these logs immutably outside the pipeline workspace. Fifth, pair the gate with automated safety mechanisms such as rollback on timeout or automated post-deployment health checks so the human gate does not become a single point of failure.
The mistakes people make
Saying you would have someone run a script locally to approve or deploy. Proposing an approval via email or chat with no programmatic enforcement in the pipeline. Ignoring timeout and escalation, which means a deployment can stall forever. Treating approval as a replacement for automated testing or canary analysis. Failing to mention audit trails or non-repudiation requirements.
What usually comes next
How do you prevent an approver from approving their own change? What happens if the approver is unavailable for four hours? How would you implement this in a multi-region deployment where each region needs separate sign-off? Can you automate the approval away once certain SLOs are met?
A concrete example
In Azure Pipelines you enable a gate in the pre-deployment conditions of a production stage. You configure an Invoke REST API gate or a manual approval gate tied to an Azure DevOps environment with protection rules. You set a delay before evaluation to allow incident management systems to log any new priority-zero bugs, then require approval from the Release Managers group. You configure a timeout of sixty minutes and re-evaluation every five minutes so that if Azure Monitor alerts fire during the wait, the gate fails and the deployment halts. All approvals and gate outcomes are written to the pipeline run logs and retained according to compliance policy.
Interview question
When implementing a manual approval gate for production in pipeline-as-code, which approach best satisfies governance and auditability requirements?
- a.Have the pipeline send an email to the release manager and wait for a reply containing the word APPROVE before continuing to the production stage.
- b.Configure a manual approval gate in the pipeline code, require approval from any team member with repository write access, and retain standard pipeline run logs for thirty days.
- c.Define the approval gate in code using protected environment reviewers, enforce that the approver belongs to a separate RBAC group, set a timeout with re-evaluation, and store immutable audit logs outside the pipeline workspace.Correct
- d.Allow the deploying engineer to obtain verbal approval from an on-call manager, then manually trigger the production stage from their local workstation using personal credentials.
Why? this is the answer
The correct answer captures the core governance pattern: the gate is defined in code, bound to least-privilege identity with separation of duties, bounded by timeouts and re-evaluation, and backed by immutable external audit trails. Option B is tempting because it mentions pipeline code and logs, but it fails to restrict approvers to a specific RBAC group and relies on standard pipeline logs rather than immutable external storage, missing non-repudiation requirements.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
- #ci/cd
- #devops
- #azure-pipelines
- #governance
- #deployment-gates
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles