Tax-portal production deploy stages must not start until an authorized operator confirms. Which pipeline trigger practice applies?
Select an answer to reveal the explanation.
Short Explanation
You should require manual approval before the production tax-portal job runs, so an authorized operator explicitly confirms the deploy. That keeps automation from promoting a staging build on its own and prevents unauthenticated chat users from approving production.
Full Explanation
Requiring a manual approval or manual trigger before the production tax-portal job runs is the right practice because it makes an authorized operator confirm the change before it reaches a sensitive, citizen-facing system. Automation can build and validate the artifact, while the approval gate supports change control and accountability. Automatically promoting each successful staging build fails because a passing validation is not always sufficient authorization for production; change windows, business sign-off, or a freeze may still prevent deployment. Allowing any anonymous chat user to approve fails because an unauthenticated action cannot establish who authorized the change and leaves production exposed to anyone with access to the chat. Hiding the pipeline and editing production servers directly over SSH fails because it bypasses the controlled deployment path, including artifact provenance, approvals, and auditability. Exam caveat: a manual gate is meaningful only when approvals are tied to authenticated identities, with separation of duties where policy requires; a build bot should not be able to self-approve. Practical check: verify that the production stage pauses for approval, that an authorized operator can approve and proceed, and that a denied or timed-out approval leaves production unchanged; review the audit record for the approver.