Service Principal Cannot Create an Endpoint From a Unity Catalog Model
Unity Catalog is enabled. Models are registered as prod.ml.churn. Development happens in workspace A; production scoring runs in workspace B under service principal sp-serving. A data scientist with USE CATALOG on prod and USE SCHEMA on ml registers version 12 and can create a serving endpoint in workspace A. In workspace B, sp-serving gets PERMISSION_DENIED: User does not have EXECUTE on MODEL prod.ml.churn when creating an endpoint. The service principal has workspace access and CAN MANAGE on the target endpoint. The model artifacts are stored in the prod.ml schema. Separately, the data scientist's Shared access mode cluster fails when %pip installs an internal wheel from dbfs:/mnt/wheels/featurelib-1.4.whl.
1. Diagnose the permission failure and list the minimum grants needed for `sp-serving` to create the endpoint.
Read the worked answer
Unity Catalog model permissions are hierarchical. sp-serving needs USE CATALOG on prod, USE SCHEMA on prod.ml, and EXECUTE on the model prod.ml.churn. Model privileges apply to the model and its versions, so a grant on version 12 alone is not the right pattern. The endpoint-level CAN MANAGE privilege is already present but does not substitute for model access.
The data scientist succeeds because object ownership or explicit grants give them access in workspace A; permissions do not automatically follow the service principal into workspace B. Grant the three privileges to the service principal, then verify by reading the model version metadata and creating a test endpoint in workspace B. If the endpoint still fails, check that both workspaces are attached to the same metastore and that the service principal can access the workspace-level serving resources.
2. Why does the wheel install fail, and what are two compliant alternatives?
Read the worked answer
Shared access mode clusters are designed for Unity Catalog-governed data and do not allow arbitrary access to the DBFS root or DBFS mount paths. dbfs:/mnt/wheels/... is therefore not a valid library source for that cluster, even though the same path may work on a single-user cluster.
Two compliant alternatives: upload the wheel to a Unity Catalog volume and install it with %pip install /Volumes/prod/ml/wheels/featurelib-1.4.whl, or place it in a workspace file and install from that path. Both are governed and work with Shared access mode. If the library requires cluster-level configuration that Shared access mode blocks, use a single-user cluster for that training workload, subject to the compute policy. The preferred long-term fix is to publish the internal wheel to a private package index and install by package name and version.