A cloud security operations team relies on a machine learning model trained on last year's telemetry to flag anomalous activity. Since the company moved many workloads to serverless functions and opened two new regions, the model's true-positive rate has fallen steadily while false positives keep rising. What is the most appropriate response?
Select an answer to reveal the explanation.
Short Explanation
Think of a guard dog trained in one house and then moved to a new neighborhood: it barks at the wrong things until you retrain it. That's model drift, and the fix is monitoring plus retraining on data you've validated. The trap is rushing in unvetted data, which is how you poison the model you're trying to repair.
Full Explanation
Model drift occurs when the statistical properties of the data a model sees in production move away from the data it was trained on. New serverless workloads and new regions change traffic patterns, identities and API call profiles, so a detector tuned to last year's environment loses precision and recall. The managed response is to measure detection quality continuously against a baseline, treat sustained degradation as a trigger, and retrain on current telemetry whose source and labels have been validated and verified, as objective 1.6 emphasizes. Lowering the alert threshold trades one problem for another: it raises volume and false positives without teaching the model what normal now looks like. Abandoning ML for static signatures discards the value of anomaly detection; models can adapt, they simply need a governed retraining cycle. Retraining immediately on raw, unchecked telemetry is the dangerous shortcut, because unvalidated data can carry mislabeled or attacker-influenced events and lead to data poisoning. Exam caveat: drift is an operational property of any model, not proof of compromise. Operational check: confirm a drift metric and retraining trigger exist, and that training data passes provenance and label validation before use.