In a deployment pipeline, what is a manual approval gate, and what is the pipeline actually doing while it waits for a human to approve?
answer
- a hold before a protected stage
- pending state, not a running job
- no agent held while waiting
- approves this run and this artifact
- expires on timeout without deploying
basics
~20 sA manual approval gate pauses a run at a boundary before a protected stage until a permitted person approves it. A platform-level gate holds the run as pending state with no agent allocated, and expires after a configured timeout.
solid answer
~50 sIt is a hold placed between two stages: everything up to it has run, and the next stage — typically the deploy to a protected environment — does not begin until a named person or group approves. Two details matter in an interview. First, *where* the wait lives: a platform-level gate keeps the run pending on the control plane, so no build agent, no checkout and no secret is tied up during a two-hour wait; a gate faked as a polling step inside a running job holds all three. Second, *what* is being approved: a specific run carrying a specific artifact, not a blanket permission for the branch or the person. Gates normally also carry a timeout after which the run expires rather than deploying, and an approver list that excludes the person who requested the change.
go deeper
Be able to say plainly that the run pauses before the protected stage until a permitted person approves, and that the approval covers that specific run rather than granting ongoing permission.
Explain the difference between a platform-held pending state and a job that polls in a loop — agent occupancy, checked-out workspace and already-injected credentials — plus timeout behaviour and separation of duties.
Argue about where gates earn their cost: which environments deserve one, why an approver asked to verify test results is the wrong control, and how routine emergency bypass turns the gate into decoration.
Own the policy: how many gates the organisation can sustain before clicking becomes reflex, what the recorded approval must contain to serve as evidence, and how gate latency shows up as larger, riskier batches.
## What the gate is A manual approval gate is a point in a pipeline where automated progress stops and a human decision is required to continue. It sits at a boundary — almost always immediately before a deployment to a protected environment, occasionally before a destructive or irreversible step such as a data migration or a public release publication. Everything before the gate has already happened: the artifact was built, the tests ran, the scans reported. The gate does not add confidence in the change; it adds an *authorization event*, and a person's judgement about timing and risk. That distinction is the heart of the topic. If the approver is being asked to decide whether the tests passed, the gate is in the wrong place — a machine should answer that. ## Where the waiting happens This is the mechanical detail interviewers probe, because the two implementations look identical in a pipeline diagram and behave completely differently. **Platform-level gate.** The run enters a pending or waiting state held by the delivery platform's control plane. No agent is allocated, no workspace is checked out, no credentials are issued. The wait can last hours or days at zero cost, and the deploy job — the one that would hold the production credential — has literally not started. If the approval never comes, nothing was ever exposed. **Gate faked inside a job.** Someone implements approval as a step that polls a chat message, an issue, or a ticket in a loop: ```bash until approved; do sleep 30; done ./deploy.sh production ``` That job is *running*. It occupies a build agent for the whole wait, which on a fixed pool means other work queues behind an idle sleep. The workspace is checked out on that machine, and whatever credentials the job declared are already in its environment, sitting there for the duration. On self-hosted or long-lived agents that is a meaningful exposure window. It is also fragile: an agent restart, a job timeout, or a platform maintenance window loses the run and the approval with it. ## What exactly gets approved An approval should bind to *this run and the artifact it carries*. Common misunderstandings, each of which is a real failure: - **"I approved the branch."** If approving once lets later runs from the same branch through, you have granted a standing permission, not made a decision about a change. - **"I approved the person."** Approval is per-change; it does not confer deploy rights. - **"I approved, then it rebuilt."** If the stage after the gate rebuilds from source rather than deploying the artifact the gate was shown, the approved thing and the deployed thing are different builds. The gate must be attached to an immutable artifact identifier. ## Who may approve The standard rule is separation of duties: the approver must not be the author or requester of the change. A gate where the person who wrote the change clicks their own approve button records an event but exercises no independent judgement — which is exactly what an auditor will notice. Most platforms let you require a group, a minimum number of approvers, or explicitly exclude the requester. Approvals are recorded with identity and timestamp; that record, not the click, is the deliverable. ## Timeouts and expiry Gates carry a timeout — hours or days — after which the run expires as cancelled or failed. Two things follow. It must expire *without deploying*: a gate that proceeds on timeout is a delay, not a gate. And a run that expired should not simply be resumed weeks later; by then the branch has moved and the approval was about a state of the world that no longer holds. Re-running re-evaluates the gate. ## Anti-patterns worth naming A gate on every environment including the throwaway ones trains people to click without reading. A gate whose approvers are a rotating on-call person with no context produces rubber-stamping. And a gate that is routinely bypassed under an emergency procedure has quietly become optional — the emergency path is now the normal path, and nobody measured it.
- Who should be excluded from the approver list for a production gate, and why?The author or requester of the change. Separation of duties is the whole point of the gate: a self-approval produces an audit record with no independent judgement behind it. Most platforms can exclude the requester explicitly or require a minimum number of distinct approvers from a named group.
- What should happen when a gate's timeout expires with nobody having approved?The run expires as cancelled or failed, and nothing deploys. A gate that proceeds on timeout is only a delay. The expiry should be recorded like any other outcome, and restarting later must re-run the pipeline against current head rather than resuming a stale approval decision.
- A reviewer approves a deployment, and the stage after the gate rebuilds the application from source. What is wrong with that?The artifact that was approved and the artifact that ships are different builds — different dependency resolutions, different timestamps, possibly different source if the branch moved. The gate must be attached to an immutable artifact identifier that the deploy step consumes unchanged, otherwise the approval attests to nothing.
saying these in an interview costs you the question
- Thinks a waiting job releases its agent automatically
- Says approving a branch once covers later runs
- Lets the change author approve their own deployment
- Believes a gate should proceed when the timeout expires
- Puts approval gates on every environment including throwaway ones