In GitLab, how do you require human approval before a pipeline job deploys to production, and what happens to that job while it waits?

## Where the control actually lives A candidate who reaches for a YAML keyword here has the wrong model. In GitLab the pipeline file *names* the environment and nothing more: ```yaml deploy_prod: stage: deploy script: ./deploy.sh production environment: name: production url: https://app.example.com ``` Authority over that environment is configured in the project's **Settings → CI/CD → Protected environments**, out of reach of anyone who can only edit `.gitlab-ci.yml`. That separation is the design: if the gate lived in the pipeline file, whoever can open a merge request against the pipeline file could remove it. Protected environments and deployment approvals are paid-tier features (Premium and above). ## The two controls **Allowed to deploy** is an access list: roles (maintainers, developers), specific users, or groups whose jobs may run against the environment. A deployment job triggered by anyone outside it fails rather than waiting — this is authorisation, not queueing. **Approval rules** are separate. They require a number of approvals before the deployment proceeds, drawn from named approvers or groups. Multiple independent rules can be configured — a release manager *and* a security approver, each with their own required count — so no single person can satisfy the whole gate. A restriction preventing the person who triggered the deployment from also approving it is the usual complement; without it the control degrades into a formality. Note the granularity: approval is on the **deployment**, not on the merge request. The same commit deploying to staging and to production produces two deployments, and only the production one is gated. This is what makes protected environments the right place for the gate rather than merge request approval rules, which are about code review. ## What the job does while waiting The pipeline runs normally until it reaches the deploy job. The job is created, and the deployment enters a blocked state pending approval rather than being dispatched to a runner. Nothing is executing and no runner slot is held. The environment page and the job page show the pending deployment and who may act on it, and approvers approve or reject there. On approval the job proceeds to a runner and runs; on rejection it does not run. The operational consequences follow from that: the pipeline is not finished while a deployment waits, an unattended approval keeps a release open indefinitely, and any downstream job that depends on the deploy is waiting too. Teams that gate production usually keep the deploy job in a late, narrow stage so a pending approval blocks as little as possible. ## Interaction with the rest of the environment machinery Protection is matched on the environment **name**, and that is where the sharp edge is. Rename `production` to `prod` in the pipeline file and the job targets an unprotected environment — the gate does not fail closed, it simply does not apply, and the deploy runs. The same applies to a *new* environment nobody protected, which is why wildcard-style protection of production-shaped names and periodic review of the environment list matter. Environment-scoped CI/CD variables key on the same names, so production credentials that resolve only for the protected environment reinforce the gate: a job deploying to an unprotected environment does not get the values it would need to touch production even if it tried. ## Choosing this over the alternatives GitLab offers a second, cruder gate: a manual job, which anyone permitted to run jobs can start. A manual job is a *pause*, not an approval — it records who clicked, allows self-service, and is trivially removed in a merge request that edits the pipeline file. Use it for convenience ("deploy when you are ready"), and use protected environments when the requirement is that a specific set of people, distinct from the author, authorised this specific deployment, with an audit trail attached to the deployment record. ## Version note This area has moved: deployment approvals gained multiple approval rules and self-approval restrictions over several GitLab 14.x–15.x releases, and older documentation describes a single required-approval count. Say which behaviour you are describing, and confirm against the version the team runs. ## What to say in an interview Lead with the split — pipeline names the environment, project settings own who may deploy and who must approve — then describe the blocked deployment state, then name the failure mode: protection keys on the name, so a renamed or newly created environment is unprotected by default.