After logging the customs-compliance agent with MLflow, the team wants to register it in Unity Catalog so that access, lineage and governance apply the same way they do to its source tables. Which identifier correctly reflects Unity Catalog's registration model?
Select an answer to reveal the explanation.
Short Explanation
Unity Catalog models live at the same address as everything else there — catalog dot schema dot name, the same three-level system you already use for tables. Anything flatter than that, and it's not actually registered where governance can see it.
Full Explanation
Unity Catalog models are registered using the same three-level namespace as every other UC object: catalog.schema.model_name. Registering the agent this way is what makes Unity Catalog's permissions, lineage, and access controls apply to the model consistently with the Delta tables and volumes it was built from, which is the entire point of registering to Unity Catalog rather than a workspace-local registry. A flat name like the workspace registry historically used does not carry catalog and schema context, so it cannot participate in UC's governance model or cross-workspace sharing. A raw DBFS file path is a storage location, not a registered, versioned model identity — it has no lineage tracking, no aliasing, and no permission model tied to it. An MLflow experiment ID identifies a collection of runs used for tracking and comparison during development; it is not a model identifier and is never what a Model Serving endpoint references when deploying a specific version. For the exam, remember that 'register to Unity Catalog' specifically means the three-level catalog.schema.model naming convention, and that this is what unlocks governance and lineage over the registered model alongside its source data.