Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.
Question 1 · choose 1
A credit model runs on a batch endpoint each night. The team wants Azure Machine Learning model monitoring for data drift and data quality, and enabled the deployment's data collector, but no production data appears. What should it do?
AWrite the scoring inputs and outputs to storage, register them as a data asset and monitor that
BTurn on payload logging in the batch deployment's data collector so request and response bodies are kept
CMove the scoring to a managed online endpoint that the batch clients call once per row
DSet the monitor's production data to the training data asset so that the signals can compute
Show the answer and why
AWrite the scoring inputs and outputs to storage, register them as a data asset and monitor that
Correct
The data collector logs only online endpoints, so batch scoring data must be collected by the team.
BTurn on payload logging in the batch deployment's data collector so request and response bodies are kept
Incorrect
Payload logging is a data collector mode, and the collector supports only online endpoints.
CMove the scoring to a managed online endpoint that the batch clients call once per row
Incorrect
That changes the serving pattern only to obtain logging that's available another way.
DSet the monitor's production data to the training data asset so that the signals can compute
Incorrect
That isn't production inference data from the nightly scoring.
Model monitoring compares production inference data with reference data. If you deploy to an Azure Machine Learning online endpoint, the data collector can log inference data; if you deploy to a batch endpoint or outside Azure Machine Learning, you're responsible for collecting production inference data, which you can then use for monitoring. The data collector supports only managed and Kubernetes online endpoints.
When a model monitor finds that data drift breached its threshold, a Logic App must start the retraining pipeline automatically. Which Event Grid subscription on the workspace fits?
AEvent type Run status changed, filtered on the monitor's threshold_breached run tag
BEvent type Dataset drift detected, with the Logic App set as the subscription's endpoint
CEvent type Model registered, filtered on the monitored model's name
DEvent type Run completed, filtered on whether the signal's threshold was breached
Show the answer and why
AEvent type Run status changed, filtered on the monitor's threshold_breached run tag
Correct
Monitor runs report breaches through this run tag on run status changed events.
BEvent type Dataset drift detected, with the Logic App set as the subscription's endpoint
Incorrect
Dataset drift detected applies to data drift v1, not model monitoring.
CEvent type Model registered, filtered on the monitored model's name
DEvent type Run completed, filtered on whether the signal's threshold was breached
Incorrect
Monitor results are identified by the threshold-breached run tag on run status changes.
To act on model monitoring results with Event Grid, create an event subscription on the workspace with only Run status changed selected, not Dataset drift detected, which is for data drift v1. Add an advanced filter with key data.RunTags.azureml_modelmonitor_threshold_breached and String contains, optionally filtering by the signal name, and use an event handler such as Event Hubs, Functions or Logic Apps.
A team sets up advanced model monitoring and must choose comparison baselines. Which reference data does Microsoft recommend?
AValidation data for every signal to keep the baselines consistent
BTraining data for drift and data quality, validation data for prediction drift
CThe last week of production data for every signal
DGround truth data for data drift and data quality, and training data for prediction drift
Show the answer and why
AValidation data for every signal to keep the baselines consistent
Incorrect
Data drift and data quality compare best against training data.
BTraining data for drift and data quality, validation data for prediction drift
Correct
These baselines give the most meaningful comparisons.
CThe last week of production data for every signal
Incorrect
Recent production data works but isn't the recommended baseline.
DGround truth data for data drift and data quality, and training data for prediction drift
Incorrect
Ground truth belongs to model performance; prediction drift compares to validation data.
For more meaningful comparisons, use training data as the baseline for data drift and data quality, and validation data for prediction drift. Recent past production data is also allowed as reference data.
Which two metrics belong to the data quality monitoring signal? (Choose TWO.)
ANull value rate
BPopulation Stability Index
CNormalized discounted cumulative gain
DOut-of-bounds rate
EMean absolute error
Show the answer and why
ANull value rate
Correct
Data quality tracks the rate of null values per feature.
BPopulation Stability Index
Incorrect
That's a data drift and prediction drift metric.
CNormalized discounted cumulative gain
Incorrect
That's the feature attribution drift metric.
DOut-of-bounds rate
Correct
Data quality tracks values outside the reference range or set.
EMean absolute error
Incorrect
That's a model performance metric.
The data quality signal tracks the integrity of a model's input with three metrics: null value rate, data type error rate and out-of-bounds rate. Population Stability Index and Jensen-Shannon distance measure drift, normalized discounted cumulative gain is used for feature attribution drift, and MAE belongs to regression model performance.
Which compute does Azure Machine Learning use to run scheduled model monitoring jobs?
AThe deployment's own inference instances
BA compute instance owned by whoever created the monitor
CServerless Spark compute with a supported instance type
DAn attached Kubernetes cluster
Show the answer and why
AThe deployment's own inference instances
Incorrect
Monitoring doesn't run on the serving instances.
BA compute instance owned by whoever created the monitor
Incorrect
Monitors use serverless Spark.
CServerless Spark compute with a supported instance type
Correct
Monitoring jobs are scheduled on serverless Spark pools.
DAn attached Kubernetes cluster
Incorrect
That isn't the documented monitoring compute.
Model monitoring jobs are scheduled to run on serverless Spark compute pools; you set the instance type in the monitor's compute settings, for example create_monitor.compute.instance_type in the CLI YAML.
How does the data quality signal decide a feature's expected data type for the data type error rate?
AIt infers the type from the reference data
BIt reads the type from the model's signature
CIt uses a schema the user uploads
DIt assumes every feature is a string
Show the answer and why
AIt infers the type from the reference data
Correct
Types inferred from reference data are compared with production values.
BIt reads the type from the model's signature
Incorrect
The signal infers types from the reference data.
CIt uses a schema the user uploads
Incorrect
No schema upload is needed.
DIt assumes every feature is a string
Incorrect
Types are inferred per feature.
During each monitoring run, model monitoring infers each feature's data type from the reference data. The data type error rate is the share of production values whose type differs, for the PySpark types it supports.
Right after a deployment with data collection goes live, some early requests and responses appear unmatched in storage. What explains it?
AThe collection sampling rate is set below 100%
BThe model returned errors for those requests
CThe storage account is in another region
DCollection initializes with the first traffic, and early items log separately
Show the answer and why
AThe collection sampling rate is set below 100%
Incorrect
Sampling drops rows; it doesn't unmatch pairs.
BThe model returned errors for those requests
Incorrect
Errors aren't the documented cause.
CThe storage account is in another region
Incorrect
Region isn't the cause.
DCollection initializes with the first traffic, and early items log separately
Correct
The warm-up behavior is expected and temporary.
Inference data collection is initialized when traffic first arrives. During a brief warm-up period after deployment, early requests or responses may be logged independently. Send a few warm-up requests or wait briefly before running validation or smoke tests.