Question 3
Domain 1: Databricks Machine LearningWhat is typically required before calling `mlflow.register_model` for Unity Catalog-backed registration?
Correct answer: A
Explanation
`mlflow.register_model` uses the active model registry, so Unity Catalog-backed registration requires the registry URI to point to Unity Catalog. Setting the registry URI to something like `"databricks-uc"` tells MLflow to register the model in Unity Catalog rather than the workspace registry.
Why each option is right or wrong
A. The registry URI should target Unity Catalog, such as `databricks-uc`
MLflow resolves model registration against the active registry configured by `mlflow.set_registry_uri()` / `MLFLOW_REGISTRY_URI`; for Unity Catalog-backed model registration, that URI must be set to the Unity Catalog registry endpoint, commonly `databricks-uc`. In Databricks, Unity Catalog model registry is separate from the legacy workspace registry, so if the registry URI is not pointed at UC, `mlflow.register_model` will attempt to use the wrong backend and the model will not be created in Unity Catalog.
B. The model must already have a Champion alias
Aliases are assigned after registration for version management; they are not a prerequisite to create the model entry.
C. The endpoint must already exist
Model registration creates registry metadata; serving endpoints are deployment concerns that generally come later.
D. The feature table must be online only
Feature table online status relates to feature serving, not the registry backend needed for model registration.