A media company retrains a recommendation model through a Cloud Build pipeline. Engagement patterns shift erratically rather than on a clock, so a fixed weekly schedule both wastes compute in quiet periods and lags behind sudden shifts. Leadership also caps monthly retraining spend. The team wants a retraining policy that fires when the model is genuinely degrading yet still respects the budget ceiling. Which TWO design choices together implement this policy? (Select TWO.)
- ATrigger the pipeline from a drift or performance signal raised by model monitoring rather than a fixed schedule Correct
- BConfigure the pipeline to retrain once every single hour regardless of any drift or accuracy signal
- CReplace the recommendation model with a static rules engine so that retraining is never required at all
- DDisable model monitoring entirely so that drift alerts cannot accidentally start an unbudgeted run
- EEnforce a guardrail that caps retraining frequency or per-period spend so runs cannot exceed the budget Correct
Why A is correct: Correct because firing on a measured degradation signal makes retraining track actual model decay, so runs happen when the model needs them instead of on an arbitrary clock that misses erratic shifts.
Why B is wrong: Tempting because frequent runs feel safe, but hourly retraining ignores actual degradation and would blow straight through the budget ceiling, contradicting both the data-driven and cost goals.
Why C is wrong: Abandoning the model removes the retraining question entirely, but it discards the model the business relies on rather than implementing a retraining policy, so it does not answer the requirement.
Why D is wrong: Switching off monitoring does cap accidental triggers, but it blinds the team to genuine degradation, defeating the goal of retraining when the model is truly declining.
Why E is correct: Correct because a frequency or spend cap keeps the drift-triggered policy within the budget ceiling, ensuring genuine degradation drives runs while total cost stays bounded.