Yes — this is a solid enterprise baseline. Your pattern matches Databricks guidance to automate UC with Terraform, use service principals for automation, and keep ownership / MANAGE narrowly assigned.

• Single Terraform SP in a Metastore Admin group: Yes, acceptable. Using a service principal for IaC is recommended, and Databricks explicitly allows metastore admin to be assigned to a user, service principal, or group; group-based assignment is strongly recommended.

• Would I keep that SP highly privileged forever? Only for central platform automation. Metastore admin is optional but highly privileged, so use it sparingly and prefer OAuth auth for the SP.

• Storage credentials + external locations owned by Metastore Admin / platform group: Yes, that’s the cleaner pattern. These are top-level metastore objects, and Databricks recommends limiting creation/management of external locations to admins or trusted data engineers because they are broad, high-impact objects.

• Catalog + schema ownership transferred to domain groups: Yes, good practice. Owners of catalogs and schemas can manage grants on child objects, and Databricks says catalog/schema admins should control downstream access while ownership should be assigned sparingly.

• Small improvement: transfer ownership of external locations (and ideally storage credentials) from the creator SP to a platform admin group, not leave them implicitly on the SP.

• RBAC roles: Your set is a good minimum: Metastore Admin, Catalog Owner, Schema Owner, Schema Write, Schema Read.

• For larger enterprises, I’d usually add/clarify one more role: Platform Storage Admin for storage credentials/external locations, even if today it is the same people as Metastore Admin. That gives cleaner separation of duties as you scale.

• Also remember Account Admin and Workspace Admin remain separate required admin layers outside your UC data roles.

Bottom line: Yes, good design. I would tweak: keep the single Terraform SP, but make its power come from a dedicated metastore-admin group, and make platform groups own storage credentials/external locations while domain groups own catalogs/schemas.

There are 2 aspects to this, it really depends on the enterprise architecture and data governance standards that your company needs to follow. 

1. On the enterprise architecture, if your company is following medallion architecture, it is not wise to transfer the ownership back to the business owner, the SPP should still how accountable for the bronze, silver and golden layer. You should only transfer back the ownership on business layer (such as data marts if you have).

2. On the governance side, it really depends on the company context.

For some company such as mine, it is require for the Data Platform to be air-gapped as no privilage data (PII) is allow to be exported from the workspace, hence we are required to use advance feature to meet these requirement:

1. Such as the new feature exclusive group (b4 this it is seperate workspaces for sensitive and non-sensitive data).

2. Consideration of using ABAC.

Please ensure you look on both side before finalizing, as architectural decision doesnt make or break right away, it start breaking in the long run.

I agree with Lu, this is a solid enterprise baseline and the two replies above cover the design mechanics well. One thing worth adding from running this pattern at scale is the evidence layer: a single Terraform SP with ownership transfer is clean to configure, but it only becomes an enterprise design when you can prove it held at any point in time. Three practical additions:

1. Lean into the audit trail the single-SP pattern gives you.
Because one service principal provisions everything, every create/transfer/revoke is attributable to a single identity, that's a strength most designs don't have. Build your evidence queries early from the system tables: system.access.audit with service_name matching your automation, filtered on action_name for ownership changes and grant/revoke events. Standardize them before an auditor asks, not after. Start here:
https://docs.databricks.com/aws/en/admin/system-tables/
https://docs.databricks.com/aws/en/admin/system-tables/audit-logs

2. Map each RBAC role to a control and an evidence query.
For SOC 2 / ISO 27001, auditors don't audit role names, they audit the control: who can invoke what, on which securable, with proof it was enforced. Your role set (Metastore Admin, Catalog Owner, Schema Owner, Schema Write, Schema Read) maps cleanly to that if you keep a mapping doc: role to grant to securable to the system-table query that proves it. The ownership-transfer pattern makes this easy because ownership is visible in the catalog, not buried in grants:
https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/privileges
https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/#grant

3. Watch drift, especially the Terraform SP's standing power.
Your Terraform SP stays in the Metastore Admin group forever. That's a deliberate, defensible choice, but it's also a permanent escalation path, so it needs a review cadence like any other standing privilege, confirm its credentials rotate (OAuth, not personal tokens) and document who can assume it. Separately, ownership transfers and temporary grants accumulate silently: a monthly diff of "who actually owns catalogs/schemas vs. who should" catches exceptions before they become audit findings. Ownership semantics are worth knowing precisely here:
https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/ownership

The design is right. The gap most enterprises hit is proving it, the query set, the control mapping, and the drift review are what turn a good RBAC model into an auditable one.