You're a little bit ahead of me in this process, so I haven't tried the solution yet, but it looks like you create a git credential resource for the service principal.  This requires a token, which I think must be generated in the console.  My reference is Terraform integration - Azure Databricks | Microsoft Learn.

So this method seems like defines a whole TF provider to use it as context? Isn't it strange? With infrastructure-as-code, you usually have a single (superuser) identity under which the provider works and which is capable of creating any objects, including other identities.

I expect it to work in this paradigm, because my actual IaC layer is Crossplane, which is Terraform-based, but I don't have all capabilities of Terraform. In particular, a Crossplane equivalent of a provider would be provider configuration, which is defined statically in the cluster. I cannot create a provider configuration "on the fly" (or maybe I don't know how to do that).

No, the module created here is for the service principal which needs to be configured, not the context Terraform runs under.

Yeah, that's what I mean, thanks for confirming.

I expect, that, if I am able to create the service principal under the main Terraform identity, I should be able to configure its parameters as well (workspace privileges, secrets, Git configuration, etc). So if I need to run Terraform under the identity of the created SP, then what's the point? it's not quite the IaC I need.