Based on the documentation here: https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tools#create-service-principal-and-client-secret-using-powershell, the support engineer and myself conclude that the service principal created has full admin rights on the tenant.
[quote] "This PowerShell script helps creating and configuring the service principal to be used with the Microsoft Power Platform Build Tools tasks. It first registers an Application object and corresponding Service Principal Name (SPN) in AAD.
This application is then added as an administrator user to the Microsoft Power Platform tenant itself."
Since our company is both and ISV partner and a customer, the internal IT department will not provide such as service user. That user (for development/testing purposes) will also be able to administrate (and delete!) environments we're using for production purposes.
Comments
While I think I understand why this was done, it isn't inline with Microsoft's current recommendations to utilize Service Principals for deployment. You are basically left to also have a Service Account to make changes that would require the Service Principal to be configured in this way. Which simply doesn't make sense. That should only be required if the action you are performing requires Tenant Level permissions.
In our particular case we want to assign users roles. The S2S user has System Administrator permissions which should be more than enough for this to work. But it is not. It requires you to configure the Service Principal as a Tenant Administrator :(