A transit ridership pipeline runs as a service principal that must write silver tables without broader administrative power. How should Unity Catalog privileges be assigned?

Scheduled transit ridership ETL should run as a service principal granted only the Unity Catalog privileges required to write the silver ridership tables—typically USE CATALOG/SCHEMA plus MODIFY (and related) on those securables, nothing more. Least privilege keeps the night-shift badge limited to the silver ridership room instead of handing out metastore master keys. That pattern separates human interactive admins from non-interactive pipeline identities used in jobs.

Using an interactive engineer account with workspace admin rights for every scheduled job ties automation to a person, complicates MFA/leave/rotation, and over-scopes admin power. Granting the service principal metastore admin lets it alter any civic catalog overnight—far beyond silver write needs. Storing an engineer's personal PAT in the job and skipping service principal privileges recreates secret sprawl and personal-credential dependency.

Exam caveat: workspace admin is not a substitute for carefully scoped UC table privileges; conversely, UC grants do not require metastore admin for ordinary ETL. Rotate client secrets or use federated credentials, and monitor job runs under the SP's identity. Operational check: register the SP, grant minimal write on silver ridership tables only, run the job, confirm writes succeed, attempt an out-of-scope DDL as the SP and expect failure, and ensure human admins retain separate break-glass paths.