A team deploys an agent to handle routine infrastructure changes — updating environment variables and rotating non-critical secrets. They want human-in-the-loop oversight without blocking the rest of the CI/CD pipeline when a reviewer is unavailable. Which design best achieves both goals?
Select an answer to reveal the explanation.
Short Explanation
You don't have to shut down the whole pipeline just to get a human sign-off. Run the agent's changes in a parallel approval workflow, so the main pipeline keeps moving while the proposal waits for review, with a timeout that escalates if nobody responds.
Full Explanation
Human-in-the-loop (HITL) oversight and delivery pipeline velocity are often perceived as conflicting goals — but a well-designed asynchronous approval workflow resolves this tension without sacrificing either.
The correct design is the parallel approval workflow: the main pipeline continues while the agent's proposal waits asynchronously for reviewer sign-off, with a configurable timeout that escalates if unreviewed. This decouples the human oversight gate from the main pipeline critical path. The main pipeline (tests, builds, deployments of other components) continues unblocked. The agent's infrastructure changes are held in a pending state, waiting for explicit reviewer sign-off. A configurable timeout with escalation (e.g., after 2 hours without a response, escalate to a secondary reviewer or auto-approve if the change is below a defined risk threshold) ensures that reviewer unavailability does not cause indefinite blocking. This design is used in mature GitOps workflows (e.g., Atlantis, Spacelift) and gives teams confidence that changes are reviewed without creating a pipeline bottleneck.
The design that pauses the entire pipeline and sends a Slack notification to the on-call engineer, requiring their response before any other pipeline stage can proceed, is incorrect. Blocking the entire pipeline for reviewer availability is exactly the tradeoff the question asks you to avoid. If an on-call engineer is unavailable (attending an incident, in a meeting, asleep in a different timezone), the pipeline stalls for all work — not just the agent's changes. This design destroys velocity and creates a single point of failure.
The design that allows the agent to execute all changes autonomously and sends a post-execution report to the team for awareness, with no approval gate, is incorrect. Post-execution reporting with no approval gate eliminates the human-in-the-loop requirement. An awareness notification is not oversight — it is notification of a done deed. If the agent made an error, the change is already applied by the time anyone reads the report. This design prioritizes velocity at the complete expense of safety.
The design that skips human review for environment variable updates and requires approval only for secret rotations, regardless of reviewer availability, is incorrect. Separating review requirements by change type (env vars vs. secrets) without considering reviewer availability does not solve the pipeline-blocking problem. If a reviewer is unavailable and a secret rotation is queued, the pipeline still blocks. Additionally, the question asks for a design that handles reviewer unavailability — that design does not address this dimension at all.
Key principle: human oversight and delivery speed are not mutually exclusive. Async approval workflows with escalation paths are the standard pattern for achieving both in agentic CI/CD pipelines.