MLflow Tracking: free practice questions

Option A is correct: in MLflow's search_runs() filter syntax, parameter values must be compared as strings (quoted), even if they represent numbers, while metric values are compared as numeric literals. The filter string "metrics.val_auc > 0.90 and params.max_depth = '6'" correctly uses the string comparison for the param and numeric comparison for the metric. The order_by list with 'metrics.val_auc DESC' correctly sorts results. Option B is incorrect because params.max_depth = 6 uses a numeric literal for a parameter, but all parameter values in MLflow are stored as strings; this will raise a query parsing error. Option C is incorrect because MlflowClient has no list_runs() method with those arguments; the correct method is search_runs(). Option D is incorrect; MlflowClient does not expose a Django ORM-style queryset API — it does not have .filter() or .order_by() chaining methods on experiment objects.

In MLflow, an experiment is the top-level organizational unit — a named container (with a unique ID and optional artifact location) used to group related runs. A run is a single execution of ML code captured within an experiment, storing parameters, metrics, tags, and artifact references. Option A reverses the hierarchy. Option C also reverses the hierarchy, describing a run as the container and an experiment as the execution unit, which is backwards. Option D is incorrect because experiments and runs are distinct concepts with a strict parent-child relationship.

MLflow supports nested runs through the `nested=True` parameter of mlflow.start_run(). The correct pattern is: (1) open a parent run using `with mlflow.start_run() as parent_run:`, then (2) inside that context, open each child run with `with mlflow.start_run(nested=True):`. This establishes an explicit parent-child relationship visible in the MLflow UI. Option A is wrong because sequentially starting runs in the same experiment does NOT create a hierarchy — they appear as sibling runs. Option B is wrong because using nested=True without an enclosing active parent run will cause an error or treat the run as a top-level run, not a child. Option D is wrong because mlflow.set_experiment_tag() sets tags at the experiment level, not on individual runs, and does not create a run hierarchy.

In MLflow 2.x, the recommended way to designate a model version for a role (such as production) is through **aliases** using client.set_registered_model_alias(). This assigns a human-readable alias (e.g., 'Champion') to a specific version number, allowing code to reference the model by alias rather than hard-coded version number. Option A uses the older stage-based API (Staging/Production/Archived) which is deprecated in MLflow 2.x in favor of aliases. Option C is incorrect because set_model_version_tag() adds a key-value metadata tag to a version — it does not create a functional alias that can be used to load the model by name. Option D is incorrect because update_model_version() is used to update the description field of a model version, not to assign an alias.

mlflow.sklearn.autolog() is the correct framework-specific autologging call for scikit-learn. It automatically logs hyperparameters, metrics (e.g., training score), and the fitted model artifact when a scikit-learn estimator's fit() method is called. Option B is wrong because mlflow.autolog() (the global shortcut) does not accept a 'framework' keyword argument in its standard API. Option C is wrong because mlflow.enable_autologging() does not exist as an MLflow function. Option D is wrong because mlflow.log_model() is used to manually log an already-trained model artifact, not to enable autologging.