MLflow for the Databricks Machine Learning Associate Exam, Explained

What the exam actually asks about MLflow

The exam guide lists exactly 48 objectives against 48 scored questions, so each objective is worth about one question. The MLflow objectives sit in Section 1, Databricks Machine Learning, and they are specific:

• Manually log metrics, artifacts, and models in an MLflow Run
• Identify the information available in the MLflow UI
• Identify the best run using the MLflow Client API
• Register a model using the MLflow Client API in the Unity Catalog registry
• Identify the benefits of registering models in Unity Catalog over the workspace registry
• Set or remove a tag for a model
• Promote a challenger model to a champion model using aliases

Notice what is absent: nothing about self-hosting an MLflow tracking server, model flavors internals, or the old workspace-registry stage transitions. The exam tests MLflow as Databricks ships it, managed and integrated with Unity Catalog.

Objectives from the official exam guide PDF (1 Mar 2025 edition) linked from the Databricks ML Associate certification page.

Tracking: manual logging versus autologging

An MLflow run is one execution of training code, grouped under an experiment. The exam expects you to know both ways a run gets its contents:

• Autologging captures parameters, metrics, and the model automatically for supported libraries, and Databricks enables it in the ML runtime.
• Manual logging is the objective the guide names explicitly: mlflow.log_param() for hyperparameters, mlflow.log_metric() for numbers you compute yourself, mlflow.log_artifact() for files such as plots, and the flavor-specific log_model() calls for the model itself.

The distinction questions test is param versus metric versus artifact: a learning rate is a param, a validation RMSE is a metric, a confusion-matrix PNG is an artifact. The MLflow UI shows all of them per run, side by side across runs, which is the substance of the "information available in the UI" objective: parameters, metrics, artifacts, source, and run comparison.

Finding the best run with the Client API

The scenario the exam likes: a tuning job produced dozens of runs, and you need the best one programmatically, not by eyeballing the UI. The pattern is search_runs with an ordering:

• order_by sorts runs by a metric, for example ["metrics.val_rmse ASC"] for a loss-like metric or DESC for accuracy-like ones.
• max_results=1 returns just the top run, whose model URI you can then register.

The trap answer in these questions is sorting in the wrong direction for the metric named. Lower is better for RMSE and log loss; higher is better for accuracy, F1, and R-squared. Read which metric the scenario optimises before picking the ordering.

The registry lives in Unity Catalog, and promotion means aliases

Registering a model turns the best run's artifact into a versioned, governed object: each registration under the same three-level name (catalog.schema.model) creates a new version. Two exam objectives sit right here:

• Why Unity Catalog over the workspace registry: centralised governance and access control, models shared across workspaces rather than trapped in one, and lineage alongside the data and features the model was built from.
• Promotion by alias: an alias like @champion is a named pointer to one version. Promoting a challenger means calling set_registered_model_alias() to move the alias to the new version, and consumers that load models:/catalog.schema.model@champion pick up the change without editing code. Tags, set and removed through the Client API, carry annotations such as validation status.

FAQ