A registered MLflow model for Meridian Line's charter-desk assistant lives at catalog charters, schema prod, model clause_assistant in Unity Catalog. The platform team wants only the Model Serving service principal to be able to deploy it, while charter-desk analysts can view its metadata but not serve it themselves. How should this be enforced?
Select an answer to reveal the explanation.
Short Explanation
Unity Catalog governs models the same way it governs tables: grants on the object. EXECUTE is what lets a principal actually serve or invoke the model, so hand that to the service principal and leave analysts with read/browse access only.
Full Explanation
Because models registered to Unity Catalog live in the same three-level namespace as tables and volumes, they take the same grant-based access model. EXECUTE is the privilege that allows a principal to invoke or deploy the model, so granting EXECUTE specifically to the Model Serving service principal, while giving analysts a lesser privilege that lets them see metadata, versions, and lineage without deploying, is exactly the intended pattern. Using the legacy workspace Model Registry instead of Unity Catalog throws away the unified governance model this exam is built around, and it does not grant single-principal restriction by default; it is also the deprecated registry, not the current recommended path. Renaming the schema is not access control at all, it is obscurity, and anyone who can list the catalog will still find it. Making every analyst an owner is the opposite of least privilege: owner is the most powerful role on an object and would let any analyst re-grant or deploy the model themselves, defeating the stated requirement. Exam framing: governance over a registered GenAI model is Unity Catalog object-level grants, the same mental model as tables and volumes, not a workspace-level or registry-level setting.