Machine Learning Associate · 29% of the exam

ML Workflows: free practice questions

5 sample questions from our 73-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real Databricks exam.

1. A machine learning engineer is registering a model trained with Databricks Feature Store. During batch inference, the engineer calls FeatureStoreClient.score_batch(). What key advantage does this method provide over calling model.predict() directly on a DataFrame?

  • A. It automatically retrains the model if feature values have drifted since the last training run
  • B. It automatically looks up and joins the latest feature values from the Feature Store using the primary keys in the input DataFrame, ensuring feature consistency between training and serving✓ Correct
  • C. It converts the model to ONNX format for lower-latency inference
  • D. It bypasses MLflow tracking to reduce overhead during high-throughput batch jobs
Explanation

score_batch() accepts a DataFrame containing only primary keys (and any on-demand features) and automatically retrieves and joins the latest feature values from the Feature Store tables. This guarantees that the same feature definitions and transformations used during training are applied at inference, eliminating training-serving skew. It does not retrain the model—that requires a separate pipeline. It does not convert models to ONNX; that is a separate optimization step. score_batch() still logs to MLflow when configured; it does not bypass tracking.

2. An ML platform team is building a CI/CD pipeline for model promotion. When a new model version is registered in Unity Catalog, they want an automated system to: (1) run integration tests, (2) compare the new version against the current `champion` model on a hold-out dataset, and (3) conditionally assign the `champion` alias if the new version wins. Which Databricks/MLflow capability is the PRIMARY mechanism for triggering the automated workflow upon model registration?

  • A. An MLflow `ModelSignature` attached to the registered model, which can be configured to call an external validation service when a new version is logged.
  • B. A Unity Catalog `AFTER INSERT` SQL trigger on the model registry's underlying Delta table that calls a Databricks notebook.
  • C. A webhook registered on the MLflow Model Registry (workspace-level) or a Unity Catalog model event notification integrated with an external CI/CD system (e.g., triggering a Databricks Job or Azure DevOps pipeline) upon the `MODEL_VERSION_CREATED` event.✓ Correct
  • D. A Databricks Feature Store trigger that detects schema changes in the feature table and automatically initiates model revalidation.
Explanation

Correct: MLflow Model Registry webhooks (for workspace-level registries) and Unity Catalog model event notifications allow teams to subscribe to lifecycle events such as `MODEL_VERSION_CREATED`, `TRANSITION_REQUEST_CREATED`, etc. These events can trigger external systems (e.g., a Databricks Job, Jenkins, GitHub Actions, Azure DevOps) to run integration tests, challenger comparisons, and conditionally update model aliases — exactly the described CI/CD workflow. Wrong - A: `ModelSignature` defines the input/output schema of a model for validation during inference; it has no triggering or notification capability and cannot call external services. Wrong - B: While Delta tables underlie much of Databricks, directly querying or triggering on the Model Registry's internal Delta tables is not a supported or recommended pattern; it bypasses the API layer and could break with platform updates. Wrong - D: Databricks Feature Store does not have a trigger mechanism that initiates model revalidation; it is used for feature storage and retrieval, not orchestration of model promotion workflows.

3. A Databricks ML team wants to implement a CI/CD pipeline that automatically tests a newly trained model version and, if tests pass, promotes it to the 'champion' alias in the Unity Catalog MLflow Model Registry. Which mechanism should they use to trigger the CI/CD pipeline when a new model version is registered?

  • A. Schedule a Databricks Job to poll the model registry every 5 minutes for new versions.
  • B. Configure a Unity Catalog model webhook that fires an HTTP callback to the CI/CD system when a new version is created or its status changes.✓ Correct
  • C. Use an MLflow autolog callback function decorated with @mlflow.on_model_registered to invoke the pipeline.
  • D. Set up a Delta Live Tables pipeline that monitors the model registry table and triggers downstream transformations.
Explanation

Option B is correct: MLflow Model Registry webhooks (supported in Unity Catalog) allow teams to configure HTTP endpoints that are called when specific events occur, such as MODEL_VERSION_CREATED or MODEL_VERSION_TAG_SET. This is the standard, event-driven mechanism for integrating the model registry with external CI/CD tools like GitHub Actions, Azure DevOps, or Jenkins. Option A works but is inefficient and introduces latency; polling is an anti-pattern when event-driven webhooks are available. Option C is fabricated; there is no @mlflow.on_model_registered decorator in the MLflow API. Option D is incorrect; Delta Live Tables is a data pipeline orchestration tool, not a mechanism for triggering CI/CD workflows based on model registry events.

4. A retail ML team wants to perform batch inference on 2 billion records stored in a Delta table using a model registered in Unity Catalog. They want to maximize throughput and leverage Spark parallelism. Which of the following approaches is MOST appropriate?

  • A. Collect all 2 billion records to the Spark driver with `df.collect()`, run inference in a loop, then write results back with `spark.createDataFrame()`.
  • B. Use `mlflow.pyfunc.spark_udf()` to create a Spark UDF from the registered model, then apply it to the Delta table using `df.withColumn()` or `df.select()` to distribute inference across the cluster.✓ Correct
  • C. Use Databricks Model Serving to expose the model as a REST endpoint and call the endpoint in a `for` loop over batches of records from the driver.
  • D. Convert the Delta table to a pandas DataFrame, run inference with `model.predict()`, and write results to a new Delta table using `spark.createDataFrame()`.
Explanation

Correct: `mlflow.pyfunc.spark_udf()` wraps a registered MLflow model as a Spark UDF, allowing inference to be distributed across all worker nodes in the cluster. This is the recommended pattern for large-scale batch inference on Databricks, fully leveraging Spark parallelism and Delta Lake I/O. Wrong - A: `df.collect()` moves all 2 billion records to the single driver node, which will cause out-of-memory errors and completely defeats the purpose of a distributed cluster. Wrong - C: Model Serving REST endpoints are designed for real-time/online inference with low-latency requirements, not high-throughput batch workloads. Calling a REST endpoint in a loop over billions of records would be extremely slow due to HTTP overhead and is not a scalable batch pattern. Wrong - D: Converting a 2-billion-row Delta table to a pandas DataFrame requires collecting all data to the driver, which will cause OOM errors — same problem as option A.

5. A data science team is building a real-time fraud scoring API on Databricks. The model requires features computed from both (a) a pre-computed aggregation table updated hourly and (b) on-the-fly transaction-level features computed at request time. The team wants to serve these features with the lowest possible latency. Which architecture BEST satisfies these requirements?

  • A. Compute all features at request time using a Spark SQL query against the Delta table, then call the model endpoint.
  • B. Use a Databricks Feature Store online store (e.g., backed by DynamoDB or CosmosDB) for the pre-computed aggregations and compute transaction-level features in the serving function logic, combining both before scoring.✓ Correct
  • C. Run a streaming Structured Streaming job that updates features in real time and writes them to the MLflow artifact store for retrieval at inference time.
  • D. Precompute and cache all possible feature combinations in a Pandas DataFrame on the model serving node at startup.
Explanation

Option B is correct: the Databricks Feature Store supports publishing feature tables to online stores (low-latency key-value stores such as DynamoDB or Azure CosmosDB). Pre-computed aggregations are published there and can be retrieved in sub-millisecond time by entity key during real-time serving. Transaction-level features that depend on the incoming request payload are computed inline within the serving function. Combining both sources at the model server is the standard pattern for hybrid feature serving. Option A is wrong because issuing a Spark SQL query against Delta at request time introduces seconds-level latency due to Spark job overhead, violating real-time SLAs. Option C is wrong because the MLflow artifact store is an object store (e.g., S3/ADLS) designed for model artifacts, not for low-latency feature retrieval at serving time. Option D is impractical because enumerating and caching all possible feature combinations is computationally infeasible for a large entity space and would consume enormous memory.

68 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free