A municipal open-data portal ingests a monthly CSV upload that feeds a downstream retraining pipeline. The team wants an automated check that flags when a column's data type or expected value range shifts from prior months, before the new data is used for retraining. Which capability addresses this directly?
Select an answer to reveal the explanation.
Short Explanation
It's a quality inspector checking each month's shipment against last month's spec sheet before it goes onto the line, not after the product ships. Glue Data Quality rules do exactly that check, automatically, every time a new upload lands.
Full Explanation
Mechanism: Glue Data Quality lets a team define rules against expected schema, data types, and value ranges, then run those rules automatically against each incoming monthly upload, flagging drift like a column's type changing or values falling outside historical bounds before that data is trusted for retraining. Why the wrong options fail by concept: Model Registry tracks and versions trained models after training completes, it has no role in validating incoming data before retraining even starts, it operates downstream of the concern described. DataBrew's visual transform builder is aimed at interactive profiling and cleaning, manually reformatting each month's file is a labor-intensive workaround rather than an automated drift-detection check wired into the pipeline. OpenSearch Service is built for indexing and searching data, it doesn't evaluate schema conformance or flag statistical drift against a baseline, it answers search queries, not data-quality checks. Scope caveat: drift rules need periodic review as the legitimate data distribution evolves over time, a rule set frozen against last year's baseline will eventually flag normal seasonal or policy-driven shifts as false positives. Operational check: review the Glue Data Quality rule evaluation results for the most recent monthly run and confirm any flagged columns before the retraining job is allowed to consume that data.