Scenario practice questions

A machine learning engineer is using MLflow to track experiments and has logged a model with a signature. They now want to register this model in the MLflow Model Registry and promote it to Production. Which MLflow API call should they use to add the model to the registry?

Trap 1: mlflow.log_model(model, artifact_path, registered_model_name=name)

While mlflow.log_model with registered_model_name can register a model during logging, the scenario states the model is already logged. Using this call would log a new model, which is not desired. The engineer needs to register the existing model, so register_model is the appropriate API.

Trap 2: mlflow.pyfunc.save_model(path, loader_module, data_path,…

This saves a pyfunc model to a local path and optionally registers it, but it is used for creating a new model, not for registering an existing run's artifact. It requires specifying a loader module and data path, which is not applicable here. The correct approach is to register the already logged model.

Trap 3: mlflow.create_registered_model(name)

mlflow.create_registered_model only creates the registered model entity (a container) without a version. It does not link a specific run's model artifact. To add a version, you need to call register_model. This option is a step that might precede registration, but it does not register the model itself.

A
mlflow.log_model(model, artifact_path, registered_model_name=name)
Why it fails: While mlflow.log_model with registered_model_name can register a model during logging, the scenario states the model is already logged. Using this call would log a new model, which is not desired. The engineer needs to register the existing model, so register_model is the appropriate API.
B
mlflow.pyfunc.save_model(path, loader_module, data_path, registered_model_name=name)
Why it fails: This saves a pyfunc model to a local path and optionally registers it, but it is used for creating a new model, not for registering an existing run's artifact. It requires specifying a loader module and data path, which is not applicable here. The correct approach is to register the already logged model.
C
mlflow.register_model(model_uri, name)
mlflow.register_model is the correct API to register an existing model artifact from a run into the Model Registry. It takes the model URI (e.g., runs:/<run_id>/model) and the desired model name. This call creates a new model version in the registry, which can then be transitioned to Production.
D
mlflow.create_registered_model(name)
Why it fails: mlflow.create_registered_model only creates the registered model entity (a container) without a version. It does not link a specific run's model artifact. To add a version, you need to call register_model. This option is a step that might precede registration, but it does not register the model itself.

Question 2easymultiple choice

When developing a machine learning model on Databricks, what is the primary benefit of using Feature Store over standard Delta Lake tables for feature management?

Trap 1: It provides built-in GPU acceleration for all training jobs.

Feature Store is a metadata and storage management layer, not a compute optimization layer. GPU acceleration is provided by the underlying Databricks cluster configuration and deep learning frameworks, not by the Feature Store itself. Feature Store manages the data lifecycle, not the hardware-level execution of training tasks.

Trap 2: It automates the elimination of data leakage during training.

Feature Store assists in managing features but does not automatically detect or prevent data leakage. Leakage prevention requires careful architectural design, such as time-travel or point-in-time joins, which the developer must implement using the feature tables to ensure historical data is used correctly during model training.

Trap 3: It automatically converts all data types to tensors.

Feature Store stores data in optimized Delta format tables. It does not perform automatic type conversion to tensors. Tensor conversion is a specific data-loading task handled by deep learning libraries like PyTorch or TensorFlow, occurring after the data has been retrieved from the Feature Store.

A
It provides built-in GPU acceleration for all training jobs.
Why it fails: Feature Store is a metadata and storage management layer, not a compute optimization layer. GPU acceleration is provided by the underlying Databricks cluster configuration and deep learning frameworks, not by the Feature Store itself. Feature Store manages the data lifecycle, not the hardware-level execution of training tasks.
B
It automates the elimination of data leakage during training.
Why it fails: Feature Store assists in managing features but does not automatically detect or prevent data leakage. Leakage prevention requires careful architectural design, such as time-travel or point-in-time joins, which the developer must implement using the feature tables to ensure historical data is used correctly during model training.
C
It ensures feature consistency between training and inference.
Feature Store maintains consistent definitions and transformations for features, allowing the same logic to be served to both batch training and real-time inference pipelines. This consistency is essential to prevent training-serving skew, ensuring the model performs as expected when it encounters live data in production environments.
D
It automatically converts all data types to tensors.
Why it fails: Feature Store stores data in optimized Delta format tables. It does not perform automatic type conversion to tensors. Tensor conversion is a specific data-loading task handled by deep learning libraries like PyTorch or TensorFlow, occurring after the data has been retrieved from the Feature Store.

Question 3hardmultiple choice

You are monitoring a production model deployed on Databricks Model Serving. You notice that the model's predictions have gradually become less accurate over time, likely due to data drift. You need to implement a solution that automatically detects drift and triggers retraining. Which Databricks feature should you use to monitor the model's input data and performance?

Trap 1: Databricks SQL dashboards that query the inference table and…

SQL dashboards can visualize metrics but do not automatically detect drift or trigger actions. They require manual interpretation and do not provide statistical drift detection. While useful for reporting, they are not a substitute for automated monitoring features like Lakehouse Monitoring, which includes built-in drift metrics and alerts.

Trap 2: MLflow Tracking to log prediction results and manually compare…

MLflow Tracking is designed for experiment tracking during development, not for production monitoring. While you can log predictions, it lacks automated drift detection and alerting. Manually comparing distributions is not scalable or timely for production. A dedicated monitoring solution like Lakehouse Monitoring is required for automated drift detection.

Trap 3: Unity Catalog lineage to track data transformations and identify…

Unity Catalog lineage helps understand data provenance but does not monitor model input distributions or performance over time. It cannot detect drift or trigger retraining. Lineage is about data flow, not statistical monitoring. For drift detection, you need a monitoring solution that analyzes the actual data distributions and model outputs.

A
Databricks SQL dashboards that query the inference table and display accuracy metrics.
Why it fails: SQL dashboards can visualize metrics but do not automatically detect drift or trigger actions. They require manual interpretation and do not provide statistical drift detection. While useful for reporting, they are not a substitute for automated monitoring features like Lakehouse Monitoring, which includes built-in drift metrics and alerts.
B
MLflow Tracking to log prediction results and manually compare distributions over time.
Why it fails: MLflow Tracking is designed for experiment tracking during development, not for production monitoring. While you can log predictions, it lacks automated drift detection and alerting. Manually comparing distributions is not scalable or timely for production. A dedicated monitoring solution like Lakehouse Monitoring is required for automated drift detection.
C
Databricks Lakehouse Monitoring for model quality and data drift, configured on the inference table that logs requests and responses.
Databricks Lakehouse Monitoring can be configured on inference tables to track data drift and model performance metrics over time. It provides automated alerts and can trigger retraining workflows. This is the native Databricks solution for monitoring model quality in production, integrating with the lakehouse for scalable analysis.
D
Unity Catalog lineage to track data transformations and identify changes in input data sources.
Why it fails: Unity Catalog lineage helps understand data provenance but does not monitor model input distributions or performance over time. It cannot detect drift or trigger retraining. Lineage is about data flow, not statistical monitoring. For drift detection, you need a monitoring solution that analyzes the actual data distributions and model outputs.

Question 4easymultiple choice

You are monitoring a model deployed to a Databricks Model Serving endpoint. You need to track the distribution of input features and model predictions over time to detect data drift. Which Databricks feature should you use?

Trap 1: Delta Live Tables

Delta Live Tables is a framework for building ETL pipelines, not for capturing inference data. While you could build a pipeline to process logs, it is not the direct feature for monitoring model serving. Inference tables are purpose-built for this use case.

Trap 2: MLflow tracking server logs

MLflow tracking server logs record experiment runs, parameters, and metrics during training, not inference requests. They do not capture the input features or predictions at serving time. Therefore, they cannot be used to monitor data drift in production.

Trap 3: Databricks SQL dashboards

Databricks SQL dashboards can visualize data, but they rely on an underlying data source. They do not automatically capture inference data. You would need inference tables or another logging mechanism to populate the data before visualizing it in a dashboard.

A
Inference tables
Inference tables automatically capture the input features and model predictions for each request to a Model Serving endpoint. They store the data in a Delta table, enabling you to analyze feature distributions and detect drift over time. This is the built-in solution for monitoring model serving traffic on Databricks.
B
Delta Live Tables
Why it fails: Delta Live Tables is a framework for building ETL pipelines, not for capturing inference data. While you could build a pipeline to process logs, it is not the direct feature for monitoring model serving. Inference tables are purpose-built for this use case.
C
MLflow tracking server logs
Why it fails: MLflow tracking server logs record experiment runs, parameters, and metrics during training, not inference requests. They do not capture the input features or predictions at serving time. Therefore, they cannot be used to monitor data drift in production.
D
Databricks SQL dashboards
Why it fails: Databricks SQL dashboards can visualize data, but they rely on an underlying data source. They do not automatically capture inference data. You would need inference tables or another logging mechanism to populate the data before visualizing it in a dashboard.

Question 5hardmulti select

A fraud-detection model is served via a Databricks Model Serving endpoint. Compliance requires that every prediction request be traceable to the exact model artifact that produced it and that the model's inputs be auditable for drift analysis. Which two actions should you take to satisfy these requirements? (Choose two.)

Trap 1: Set the endpoint's scale-to-zero behavior to disabled so logs are…

Scale-to-zero affects latency and cost by keeping replicas warm; it has no bearing on whether request payloads are persisted. Disabling it does not create an audit trail and does not associate predictions with a model version. This option addresses availability, not the traceability and drift-audit requirements in the scenario.

Trap 2: Configure the endpoint to use a custom container image that writes…

A custom container is supported for bringing dependencies, but it does not automatically provide payload logging tied to the model version. Writing to S3 bypasses Unity Catalog governance, breaks lineage, and adds operational overhead. It also does not guarantee the response payloads are captured, so it fails the compliance requirement for complete auditability.

Trap 3: Tag the registered model version in Unity Catalog with the…

Tags add metadata to the model version but do not record per-request inputs or outputs. They help identify which artifact is deployed, yet they cannot support drift analysis because no payload data is stored. Tagging alone does not create an auditable request log, so it does not meet the stated compliance requirement.

A
Set the endpoint's scale-to-zero behavior to disabled so logs are never lost during cold starts.
Why it fails: Scale-to-zero affects latency and cost by keeping replicas warm; it has no bearing on whether request payloads are persisted. Disabling it does not create an audit trail and does not associate predictions with a model version. This option addresses availability, not the traceability and drift-audit requirements in the scenario.
B
Configure the endpoint to use a custom container image that writes each request to an external S3 bucket.
Why it fails: A custom container is supported for bringing dependencies, but it does not automatically provide payload logging tied to the model version. Writing to S3 bypasses Unity Catalog governance, breaks lineage, and adds operational overhead. It also does not guarantee the response payloads are captured, so it fails the compliance requirement for complete auditability.
C
Enable inference tables on the endpoint so requests and responses are automatically logged to a Delta table.
Inference tables capture the payloads sent to and returned from a Model Serving endpoint and persist them to a Unity Catalog Delta table. This gives an auditable record of the model inputs for drift analysis and links each request to the served model version, satisfying both traceability and auditability requirements without custom logging code.
D
Tag the registered model version in Unity Catalog with the deployment timestamp and serving endpoint name.
Why it fails: Tags add metadata to the model version but do not record per-request inputs or outputs. They help identify which artifact is deployed, yet they cannot support drift analysis because no payload data is stored. Tagging alone does not create an auditable request log, so it does not meet the stated compliance requirement.
E
Enable automatic model version capture on the endpoint so the served model version is recorded with request logs.
Model Serving can record the model version alongside request logs when version capture is enabled, which ties each prediction to the exact artifact. Combined with inference tables, this produces the end-to-end traceability the compliance team requires, ensuring an auditor can map any prediction back to the registered model version.