AI and Machine Learning Model monitoring and MLOps

Data drift

A measurable change in production input data or feature distributions compared with the baseline data used to train or validate a model.

Source: Microsoft Learn - Azure Machine Learning model monitoring Reviewed 2026-05-13

Exam trap: Treating Data drift as a generic concept instead of checking the exact resource, owner, identity, and dependency path.
Production check: Verify the active tenant, subscription, resource group, and resource name before interpreting any result.

Practice this topic Microsoft Learn

Article details and learning context

Aliases: feature drift, input data drift, model data drift
Difficulty: Intermediate
CLI mappings: 4
Last verified: 2026-05-13

Learning paths Learn Machine Learning Operations Data drift

Related context Learning path: Machine Learning Operations Concept cluster: AI and Machine Learning concept cluster

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Data drift is a measurable change in production input data or feature distributions compared with the baseline data used to train or validate. It helps machine learning, data science, risk, and operations teams detect when model inputs no longer resemble trigger investigation, retraining review, alert tuning, or business process checks before model quality silently degrades. In practice, teams use it to answer whether the observed change is expected seasonality, data quality failure, business change, or a signal that. Operators should tie the term to one subscription, resource owner, environment, evidence source, and rollback path before changing production. That keeps glossary.

Why it matters

Data drift matters because model trust, compliance review, customer outcomes, retraining timing, feature ownership, and production monitoring responsibility become real production responsibilities, not abstract design notes. If teams misunderstand it, they may approve the wrong access, miss a dependency, collect weak evidence, or create avoidable outages. It influences security controls, reliability planning, support ownership, cost review, and change approval. For regulated or high-visibility workloads, a technically healthy endpoint can keep returning predictions while the underlying data has moved away from the training population. A strong definition gives architects, operators, auditors, and application owners a shared operating language that can be tested against live Azure configuration, logs, and business objectives.

Official wording and source

A measurable change in production input data or feature distributions compared with the baseline data used to train or validate a model. Microsoft Learn places it in Azure Machine Learning model monitoring; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Data drift sits in Azure Machine Learning model monitoring, online endpoints, data assets, baselines, schedules, alerts, and retraining pipelines. It is configured through monitor schedules, baselines, feature schemas, thresholds, endpoint data collection, storage, alert routes, and workspace permissions and validated by checking drift metrics, monitor runs, data quality warnings, endpoint traffic, schema mismatches, prediction shifts, and alert history. It connects to Azure Machine Learning workspace, model monitors, online endpoints, data assets, storage, managed identity, Azure Monitor. For production reviews, compare portal state, CLI output, deployment JSON, logs, and runbook notes. Treat it as live configuration that affects deployed workloads.

Exam context

Compare with

Model monitoring Model version Online endpoint

Where it is used

Where you see it

In the Azure portal, Data drift appears around Azure Machine Learning model monitoring pages, online endpoint views, data asset screens, job history, alerts, and workspace storage evidence. Operators use this signal to confirm scope, ownership.
In infrastructure or source control, Data drift shows up in monitor YAML, endpoint deployment files, data collection settings, workspace definitions, schedule records, and CLI output for endpoints. Reviewers compare those files with deployed resources before.
In monitoring and support evidence, Data drift appears through drift dashboards, failed monitor jobs, endpoint traffic, feature distribution changes, data quality alerts, and retraining tickets. These signals help teams diagnose failures, drift, security gaps, and.
During incident review, Data drift is visible when teams trace a failed run, blocked dependency, changed identity, or unexpected configuration back to a named owner.

Common situations

Design a production workload where Data drift must be configured, reviewed, and monitored before customer traffic or regulated data is involved.
Create audit evidence that shows the owner, resource scope, access path, and live Azure state for Data drift.
Troubleshoot incidents where Data drift may affect access, dependency behavior, latency, cost, data freshness, or policy compliance.
Compare portal, CLI, infrastructure-as-code, and monitoring evidence so teams do not approve changes from stale assumptions.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Data drift in action for insurance Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Adventure Works Insurance, a insurance organization, needed to catch policy-risk model degradation when weather and claim patterns changed after a major storm season. The platform team used Data drift to monitor input distributions against the approved training baseline.

Goals

Reduce production risk by thirty percent
Make ownership and evidence clear
Improve recovery during incidents
Keep security and cost controls visible

Approach using Data drift

Architects designed the solution around Data drift by using it to monitor input distributions against the approved training baseline. They connected the design to Azure Machine Learning workspace, model monitors, online endpoints, data assets, storage, managed identity, Azure Monitor, and retraining jobs so data engineers, security reviewers, operators, and business owners worked from the same evidence. The team documented the owner, Azure scope, identities, network path, monitoring signals, cost assumptions, and rollback step before production release. Engineers captured CLI output, portal configuration, deployment references, and baseline metrics, then compared first-week telemetry with the expected business result. Any mutating change required an approved ticket and a named operator so support teams could reproduce the behavior during an incident.

Potential outcomes

Incident triage time fell by thirty-two percent because owners could follow one evidence path.
Failed or delayed production runs dropped by twenty-eight percent during the first quarter after rollout.
Audit reviewers accepted the captured configuration, access, and monitoring evidence without extra manual sampling.
Engineering effort for repeat fixes fell by thirty-five percent because the design was documented and reusable.

What to learn

Data drift is valuable when teams connect the glossary concept to live Azure configuration, measurable outcomes, and accountable operations.

Scenario 02 Data drift in action for advertising technology Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Coho Retail Media, a advertising technology organization, needed to detect seller behavior changes that reduced recommendation quality after a marketplace promotion. The platform team used Data drift to alert model owners when production features drifted.

Goals

Reduce production risk by thirty percent
Make ownership and evidence clear
Improve recovery during incidents
Keep security and cost controls visible

Approach using Data drift

Architects designed the solution around Data drift by using it to alert model owners when production features drifted. They connected the design to Azure Machine Learning workspace, model monitors, online endpoints, data assets, storage, managed identity, Azure Monitor, and retraining jobs so data engineers, security reviewers, operators, and business owners worked from the same evidence. The team documented the owner, Azure scope, identities, network path, monitoring signals, cost assumptions, and rollback step before production release. Engineers captured CLI output, portal configuration, deployment references, and baseline metrics, then compared first-week telemetry with the expected business result. Any mutating change required an approved ticket and a named operator so support teams could reproduce the behavior during an incident.

Potential outcomes

Incident triage time fell by thirty-two percent because owners could follow one evidence path.
Failed or delayed production runs dropped by twenty-eight percent during the first quarter after rollout.
Audit reviewers accepted the captured configuration, access, and monitoring evidence without extra manual sampling.
Engineering effort for repeat fixes fell by thirty-five percent because the design was documented and reusable.

What to learn

Data drift is valuable when teams connect the glossary concept to live Azure configuration, measurable outcomes, and accountable operations.

Scenario 03 Data drift in action for medical devices Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Alpine Diagnostics, a medical devices organization, needed to prove that a sensor model was receiving out-of-range manufacturing measurements after a supplier change. The platform team used Data drift to connect drift alerts to data-quality triage and retraining review.

Goals

Reduce production risk by thirty percent
Make ownership and evidence clear
Improve recovery during incidents
Keep security and cost controls visible

Approach using Data drift

Architects designed the solution around Data drift by using it to connect drift alerts to data-quality triage and retraining review. They connected the design to Azure Machine Learning workspace, model monitors, online endpoints, data assets, storage, managed identity, Azure Monitor, and retraining jobs so data engineers, security reviewers, operators, and business owners worked from the same evidence. The team documented the owner, Azure scope, identities, network path, monitoring signals, cost assumptions, and rollback step before production release. Engineers captured CLI output, portal configuration, deployment references, and baseline metrics, then compared first-week telemetry with the expected business result. Any mutating change required an approved ticket and a named operator so support teams could reproduce the behavior during an incident.

Potential outcomes

Incident triage time fell by thirty-two percent because owners could follow one evidence path.
Failed or delayed production runs dropped by twenty-eight percent during the first quarter after rollout.
Audit reviewers accepted the captured configuration, access, and monitoring evidence without extra manual sampling.
Engineering effort for repeat fixes fell by thirty-five percent because the design was documented and reusable.

What to learn

Data drift is valuable when teams connect the glossary concept to live Azure configuration, measurable outcomes, and accountable operations.

Azure CLI

Use Azure CLI for Data drift when you need repeatable evidence from live Azure resources instead of a one-off portal screenshot. Start with read-only checks, compare output with source-controlled intent, and attach the result to the change, incident, or audit record.

Useful for

Confirm the active subscription, resource group, owner, and current configuration before approving a change involving Data drift.
Export read-only evidence for audits, incidents, migrations, or architecture reviews where Data drift affects production behavior.
Compare CLI output with infrastructure templates and monitoring dashboards to find drift, missing dependencies, or unsafe assumptions.

Before you run a command

Confirm the tenant, subscription, resource group, region, and exact resource names before trusting command output.
Prefer read-only commands first; require change approval before commands that create, update, start, stop, rerun, or delete resources.
Check RBAC, extension requirements, production freeze windows, and whether output may expose identifiers, endpoints, secrets, or sensitive metadata.

What the output tells you

It shows whether Data drift exists in the expected scope and whether live Azure state matches the documented design.
It exposes identities, endpoints, component names, run history, policy settings, dependency references, or output values not obvious from application code.
It gives reviewers evidence they can attach to tickets, dashboards, audit notes, deployment records, and post-incident timelines.

Mapped commands

Data drift operational checks

direct

az ml schedule list --resource-group <resource-group> --workspace-name <workspace-name>

az ml schedulediscoverAI and Machine Learning

az ml schedule show --name <schedule-name> --resource-group <resource-group> --workspace-name <workspace-name>

az ml schedulediscoverAI and Machine Learning

az ml online-endpoint show --name <endpoint-name> --resource-group <resource-group> --workspace-name <workspace-name>

az ml online-endpointdiscoverAI and Machine Learning

az ml online-deployment show --name <deployment-name> --endpoint-name <endpoint-name> --resource-group <resource-group> --workspace-name <workspace-name>

az ml online-deploymentdiscoverAI and Machine Learning

Architecture context

Architecture reviews for Data drift should connect the term to resource scope, identity, networking, monitoring, cost ownership, and rollback evidence.

Security: Security for Data drift starts with knowing who can configure it, who can read its evidence, and which identities, secrets, network paths, or data stores it depends on. Focus on least-privilege access to inference data, protected storage, sensitive feature handling, monitored identities, and controlled export of drift evidence. Use least privilege, managed identities where appropriate, private or approved network paths, and diagnostic logging that is reviewed regularly. Document the owner, approval path, and exception process before production use. During incidents, prove whether access, policy, data, or network controls changed recently instead of relying on stale assumptions. Record the current owner, logging path, approval, and emergency exception process.
Cost: Cost for Data drift is not only the direct service charge. Watch monitor frequency, endpoint logging, storage growth, feature volume, retraining experiments, alert triage, and retained baseline datasets. Small configuration choices can multiply across environments, schedules, regions, or repeated runs. Use budgets, tags, owner reports, and run history to separate valuable usage from avoidable waste. Before expanding scope, estimate volume, retention, test activity, and support effort. After rollout, compare expected cost with actual usage and capture remediation tasks for unused resources, noisy settings, or oversized paths. Review cleanup tasks and expected usage before approving wider rollout. Review cleanup tasks and expected usage before approving wider rollout.
Reliability: Reliability for Data drift means the workload still behaves predictably when dependencies fail, schemas change, policies update, or traffic spikes. Plan around monitor schedules, baseline freshness, schema compatibility, endpoint data collection, alert routing, and recovery when monitoring jobs fail. Monitor both the Azure resource and the user-visible symptom, because the first warning may appear in logs, metrics, latency, missing data, or failed background work. Keep rollback steps and dependency owners visible in the runbook. Test permission loss, stale configuration, regional events, and partial deployment failures before production reliance. Record tested fallback steps and the first alert responders should trust. Record tested fallback steps and the first alert responders should trust.
Performance: Performance for Data drift depends on how quickly the related workflow produces trustworthy results without overloading sources, agents, networks, or downstream services. Pay attention to endpoint logging overhead, monitor runtime, feature computation, schedule frequency, query latency, and retraining pipeline throughput. Measure the user-visible or operator-visible outcome, not just whether the resource exists. For production changes, compare baseline and post-change latency, throughput, error rate, and queue behavior. Tune in small steps, because aggressive parallelism, broad filters, or oversized test data can create throttling and hide the real bottleneck. Retest after network, source, sink, or dependency changes are released. Retest after network, source, sink, or dependency changes are released.
Operations: Operations for Data drift should be repeatable and easy for a second engineer to verify. The runbook should cover threshold reviews, owner queues, retraining triggers, run history, data-quality tickets, CLI evidence, and documented escalation to model owners. Keep naming, tags, dashboards, tickets, and infrastructure definitions aligned so support teams do not rely on memory. Use read-only CLI commands for routine evidence, and require review before mutating commands. After rollout, compare live state with approved design, check first signals, and record owner follow-up before closing the change. Keep before-and-after evidence linked to the ticket, dashboard, and owning team. Keep before-and-after evidence linked to the ticket, dashboard, and owning team.

Common mistakes

Treating Data drift as a generic concept instead of checking the exact resource, owner, identity, and dependency path.
Running a mutating command in the wrong subscription or resource group because the active CLI context was not verified.
Assuming the portal, IaC template, CLI output, and monitoring dashboard all represent the same current state without comparing them.