Databricks-ML-Pro Model Development Practice Question
Which of the following describes the correct usage of the MLflow 'log_param' function in a Databricks environment?
⚠ Common exam trap
Candidates confuse 'log_param' with 'log_metric', incorrectly using parameter logging for runtime outputs or evaluation scores that change iteratively during training.
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
✓
It logs individual hyperparameter values, such as learning rates or tree depth, to the active run.
Logging parameters is a best practice for experiment reproducibility. By calling 'log_param' for every hyperparameter, you ensure that every run is documented with the exact settings used. This allows for rigorous comparison between runs. In a production environment, this metadata is what enables the team to identify which model version is associated with specific hyperparameter configurations, facilitating model auditing and governance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It should be called after the model is trained to log the final weights.
Why it's wrong here
Parameters represent the input configuration settings used during training, not the resulting model weights. Weights are typically saved as artifacts via 'log_model' or 'log_artifact'. Logging weights as parameters is incorrect and inefficient, as parameters are intended to be small, searchable key-value pairs that describe the experiment's setup.
- ✓
It logs individual hyperparameter values, such as learning rates or tree depth, to the active run.
Why this is correct
The 'log_param' function is specifically designed to store configuration settings that influence the model training process. Storing these key-value pairs allows for easy filtering, sorting, and comparison of multiple MLflow runs, which is essential for identifying the best hyperparameters during a grid or random search optimization process.
- ✗
It automatically logs the entire training dataset for lineage tracking.
Why it's wrong here
Datasets are too large to be logged via 'log_param'. 'log_param' is limited to small strings or numeric values. Dataset tracking should be handled via Databricks Unity Catalog or by logging the dataset path as a parameter, rather than trying to store the actual data content within the MLflow run metadata.
- ✗
It is only available for custom models and not for Spark MLlib models.
Why it's wrong here
MLflow is framework-agnostic. The 'log_param' functionality is available for any model type, including Spark MLlib, scikit-learn, TensorFlow, and PyTorch. It provides a consistent interface for tracking experiment metadata, which is critical for maintaining standardized workflows across teams using different libraries within the same Databricks workspace environment.
About these practice questions
Courseiva writes every Databricks-ML-Pro question from scratch — 300 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-Pro 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-Pro exam.