Databricks Machine Learning Associate · 38% practice allocation

Databricks Machine Learning Associate: Databricks Machine Learning Practice Questions

5 free sample questions from the Databricks Machine Learning domain, with answers and explanations. The full Machine Learning Associate bank has 461 questions across 4 domains. Questions are scenario-based and written from the official Databricks exam guide.

1.

A data science team finishes training a model and registers it in the Unity Catalog-backed MLflow Model Registry under prod_catalog.ml_models.churn_predictor. They want to promote version 5 to be the canonical 'production' version while keeping older versions accessible for rollback. What is the recommended approach in the Unity Catalog-backed registry?

  • A. Move version 5 to the 'Production' stage using MlflowClient.transition_model_version_stage().
  • B. Copy version 5 to a separate registered model named churn_predictor_prod to distinguish it from development versions.
  • C. Delete all previous versions and re-register the model so that the only version available is the production one.
  • D. Assign a named alias such as champion to version 5 using MlflowClient.set_registered_model_alias().✓ Correct
Explanation

Correct: Unity Catalog-backed MLflow Model Registry uses mutable named aliases (e.g., champion, challenger) instead of fixed stages. Setting an alias like champion on version 5 allows inference code to reference models:/prod_catalog.ml_models.churn_predictor@champion, while all older versions remain accessible for rollback. Wrong - A: Stage transitions (Staging, Production, Archived) are a feature of the legacy workspace-level Model Registry and are NOT supported in the Unity Catalog-backed registry. Wrong - B: Deleting prior versions removes rollback capability and is not a recommended practice. Wrong - D: Copying to a separate model name is an anti-pattern that creates governance and lineage complexity; aliases solve this problem cleanly within the same registered model.

2.

A data scientist wants to run a hyperparameter search where an outer MLflow run represents the overall search and each hyperparameter combination gets its own run that MLflow visually groups under the outer one. What MLflow feature supports this structure?

  • A. Autologging, which automatically creates the nesting structure with no code changes
  • B. MLflow experiments, since starting a new experiment for each combination is the only way to group runs
  • C. MLflow Model Registry stages, since 'Staging' groups related runs together
  • D. Nested runs, created by starting an inner mlflow.start_run(nested=True) inside an active parent run✓ Correct
Explanation

MLflow explicitly supports nested runs: starting a child run with nested=True while a parent run is active groups them together in the tracking UI, which is the standard pattern for representing a hyperparameter search and its individual trials. Creating a brand-new experiment per combination would scatter, not group, the trials. Model Registry stages describe deployment lifecycle for registered models, unrelated to grouping tracking runs, and autologging captures params/metrics automatically but does not by itself create a nested run hierarchy.

3.

A data scientist wants to score a large batch of records using a model that was logged with Feature Store feature lookups, without manually re-joining each feature table. What should they use?

  • A. Manually join the batch of primary keys to the feature table with a plain DataFrame join on the matching key columns, then pass the joined DataFrame to the model
  • B. Call the Feature Store client's read_table() function to load the entire feature table and pass it directly to the model instead of using score_batch
  • C. The Feature Store batch scoring utility (e.g. score_batch), providing only the primary keys and letting it join in the needed features automatically✓ Correct
  • D. Register the model again as a brand-new model before every batch scoring run
Explanation

Because the model was logged with its feature lookups, the Feature Store's batch scoring utility can accept just the primary keys and automatically replay the exact joins used during training, which is the point of logging lookups with the model. A plain DataFrame join on the matching key columns can produce the same values for a simple, single-table case, but it bypasses the lookup metadata carried by the logged model, so for anything more complex (multiple feature tables, point-in-time joins) a hand-rolled join can silently drift from what training actually used, reintroducing train/serve skew. Re-registering the model is unnecessary and unrelated to scoring. Loading the whole feature table with read_table() and passing it straight to the model skips the keyed join to the specific batch entirely, so it doesn't isolate the right rows or guarantee the same feature columns the model expects, unlike score_batch, which reuses the lookups defined at logging time.

4.

A data scientist creates a FeatureLookup that must join feature values to training labels based on both an entity key and a timestamp, so that only historically valid feature values are used. Which FeatureLookup argument supports the timestamp-based join?

  • A. table_name only, since timestamps are inferred automatically without configuration
  • B. feature_names, by listing the timestamp column as if it were a feature
  • C. There is no way to join on a timestamp; this must be done manually before calling FeatureLookup
  • D. timestamp_lookup_key✓ Correct
Explanation

FeatureLookup accepts a timestamp_lookup_key argument specifically to support point-in-time correct joins alongside the entity key(s). Table name alone does not encode timestamp-join logic, listing a timestamp column inside feature_names would treat it as a feature value rather than a join key, and this capability is a supported, built-in part of FeatureLookup rather than something that must be hand-rolled beforehand.

5.

A data scientist wants to log a matplotlib figure they created (a residuals plot) directly to the active MLflow run without first manually saving it to a file on disk. Which MLflow function is designed for this?

  • A. mlflow.log_figure()✓ Correct
  • B. mlflow.set_experiment()
  • C. mlflow.log_metric()
  • D. mlflow.log_param()
Explanation

mlflow.log_figure() accepts a matplotlib (or plotly) figure object directly and handles saving it as an artifact on the run, avoiding a manual save-to-disk step. log_metric is for scalar numeric measurements, not images. log_param is for fixed configuration values, and set_experiment only selects which experiment subsequent runs belong to; neither logs a figure.

Test yourself across every Machine Learning Associate domain

The free Machine Learning Associate practice test mixes about 20 questions weighted like the exam. The full 461-question bank adds instant grading, flashcards and a timed mock exam.

Take the free Machine Learning Associate practice testPractice the full bank

Study this domain

Databricks Machine Learning study guide (Machine Learning Associate) →

Other Machine Learning Associate domains

← All Databricks Machine Learning Associate study resources