A benefits-eligibility fraud-detection model needs to move automatically through dev, test, and production stages as code changes are merged, with each stage gated by an approval or automated test step. Which pipeline design best supports this?
Select an answer to reveal the explanation.
Short Explanation
Promoting a model to production without staged gates is like handing someone the keys to city hall on their first day — some checkpoints exist for a reason. A multi-stage pipeline with build, test, and deploy stages, each requiring a passed test or a sign-off before the next stage runs, is what turns "we merged the code" into "we verified it's safe to ship."
Full Explanation
A CI/CD pipeline built with sequential stages — build, then automated test, then deploy — formalizes the promotion path from dev to test to production, and gating each transition on a test result or an explicit approval action is what prevents an untested or unreviewed change from reaching production automatically. A manually-run script depends entirely on a person remembering every step correctly every time, which doesn't scale and reintroduces the human error that staged automation exists to reduce. A fixed daily redeploy schedule decouples deployment from whether a change actually happened or passed its checks, so it can either deploy nothing useful on a quiet day or, worse, deploy an unvetted change simply because the clock hit a certain hour. Treating dev and test as optional collapses the whole point of staged promotion, since it removes the checkpoints meant to catch problems before a fraud-detection model — one with real consequences for benefits decisions — reaches residents. Scope caveat: approval gates for a model with this level of impact often need a named human reviewer, not just an automated test, given the stakes of a wrong eligibility determination. Operational check: intentionally push a change that fails a test stage and confirm the pipeline halts before it reaches production.