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.