Databricks-ML-Assoc ML Workflows Practice Question
A data scientist trains a scikit-learn model in a Databricks notebook and calls mlflow.sklearn.log_model with the registered_model_name argument set to 'churn_model'. Later, a colleague needs to know which source notebook and Git commit produced run ID 3f8a1c. Where can this information be retrieved?
⚠ Common exam trap
The trap here is assuming the Model Registry stores full source provenance, when that metadata actually belongs to the MLflow run tags in the experiment.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
In the MLflow Experiment page, open the run and inspect the run's tags, including mlflow.source.name and mlflow.source.git.commit.
MLflow automatically attaches metadata tags to each run, including the source notebook path, Git commit, and user. These tags are visible on the run detail page in the experiment UI, making it the authoritative place to trace a run back to its originating notebook and revision. Registry entries and artifact files like conda.yaml do not carry this provenance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
In the MLflow run's artifact directory, open the conda.yaml file, which records the source notebook path and Git commit used during training.
Why it's wrong here
conda.yaml captures the Python and library dependencies of the training environment, not the notebook path or Git revision. While it is stored in the run's artifacts, it contains package specifications only, so it cannot identify which notebook or commit produced run 3f8a1c.
- ✗
In the Databricks Model Registry, open version 1 of churn_model and read the 'Source' field, which stores the originating notebook path and Git commit.
Why it's wrong here
The Model Registry records the run ID and artifact location that produced a model version, but it does not surface the originating notebook path or Git commit as a first-class source field. Those provenance details live on the MLflow run itself, so the registry page cannot answer the colleague's question directly.
- ✓
In the MLflow Experiment page, open the run and inspect the run's tags, including mlflow.source.name and mlflow.source.git.commit.
Why this is correct
MLflow automatically records the source notebook path, Git commit, and other environment metadata as tags on every run. Opening the run in the experiment UI and viewing its tags reveals exactly which notebook and Git revision generated run 3f8a1c, satisfying the colleague's need without any extra instrumentation.
- ✗
In the Databricks Jobs UI, locate the task that ran the notebook and read its run history, which stores the MLflow run ID and its source metadata.
Why it's wrong here
The Jobs UI tracks task execution status, duration, and parameters, but it does not maintain a mapping from MLflow run IDs to source notebook or Git commit. Unless the notebook was run as a job, no entry exists at all, and even then the Jobs UI does not expose MLflow run provenance tags.
About these practice questions
Courseiva writes every Databricks-ML-Assoc question from scratch — 319 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-ML-Assoc practice question is part of Courseiva's free Databricks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the Databricks-ML-Assoc exam.