How do you track experiments and manage model versions in Azure Machine Learning, and why is MLflow the usual choice?

Use MLflow for both. An Azure ML workspace works as an MLflow tracking server and model registry, so standard MLflow code logs parameters, metrics and models to the workspace with no Azure-specific calls. The same code runs on your laptop, on Azure ML compute or in Databricks, and the models it logs can be registered, versioned and deployed to an endpoint without writing a scoring script.

What gets tracked, and by whom

import mlflow

mlflow.set_experiment("churn")
with mlflow.start_run():
    mlflow.log_params({"max_depth": 6, "n_estimators": 400})
    model.fit(X_train, y_train)
    mlflow.log_metric("auc", roc_auc_score(y_val, model.predict_proba(X_val)[:, 1]))
    mlflow.sklearn.log_model(model, "model", registered_model_name="churn-model")

Inside an Azure ML job the tracking address is already set. From a laptop you point MLflow at the workspace's tracking URI once.

Model versions

Registering under an existing name adds a version: churn-model:1, churn-model:2. Deployments refer to a name and version, so you always know which model an endpoint serves. Register from the run that trained the model, as above, and the version stays tied to that run's parameters, metrics, code and data, so the question "what changed between version 3 and 4?" has an answer.

Why MLflow rather than the Azure ML SDK for logging

• Portable: the training code is not tied to Azure. Teams that train in Databricks and serve from Azure ML log to one workspace.
• No-code deployment: Azure ML deploys an MLflow model to an online or batch endpoint without an environment or scoring script.
• One habit: data scientists already know the API.

Practices that make it useful

• Log the data asset name and version as a parameter, so a run can be repeated on the same data.
• Log the model with a signature and an input example; deployments and later checks rely on them.
• Promote models by evaluation results, not by "latest". Compare a candidate against the current production version on the same test set before registering it for deployment.

What interviewers want: the workspace as an MLflow tracking server, what jobs record on their own and what you must log, registered models by name and version linked to their run, and why MLflow models deploy without a scoring script.