A housing authority's SageMaker endpoint scores casework eligibility, and applicant income data shifts after a policy change even though the endpoint keeps returning responses without errors. Staff want to catch this shift before it silently degrades decision quality. Which monitoring approach addresses this?
Select an answer to reveal the explanation.
Short Explanation
Think of error-rate alarms like a smoke detector that only goes off once there's fire, but drift is more like a slow gas leak with no smoke at all. The endpoint keeps answering just fine, it's just answering questions that look statistically different from what it trained on. Distribution drift monitoring compares incoming income data against the training baseline so you catch the shift before decisions quietly go wrong.
Full Explanation
A data-distribution drift check computes statistical distance between the feature distribution the endpoint is scoring now and the baseline distribution captured from training data, then alerts once drift exceeds a configured threshold, exactly the shift a policy change to income reporting would produce even while the endpoint returns healthy, error-free responses. Error-rate alarms fire on invocation failures like malformed payloads or throttling, so a well-formed request scored against stale assumptions never trips them. Latency alerts catch performance regressions, not a change in what data means, so a fast, wrong answer sails right through. CPU and memory monitoring watches infrastructure health, unrelated to whether the input data still resembles what the model was trained on. Scope caveat: drift monitoring flags a statistical shift, not a correctness verdict; a flagged shift still needs a human or an evaluation job to confirm it actually degraded eligibility decisions before retraining is triggered. A concrete operational check: compare a weekly drift report's flagged features against the policy-change effective date to confirm the income field is driving the alert.