How to manage or negate scopes in the OIDC process? It should not be
up to the user to authorize appropriate access; this should be set by
the org IT admins that created the user

Permissions for IAM members (users, groups, service accounts, etc) are managed in Google Cloud IAM. Scopes are used with OAuth to limit permissions already assigned by IAM. Best practices mean assigning the required permissions (and no more) and not combing IAM with scopes.

Can G Suite IT admins apply params to users (custom &/or not) which
automatically allocate predefined “Google Identity/IAM” policy
groups/roles?

G Suite and Google Cloud are separate services. Google Cloud supports G Suite as an Identity provider (IDP). Permissions are controlled in Google Cloud IAM and not in G Suite. You can combine G Suite with Google Groups to put IAM members into groups for easier IAM management.

Will the G Suite users signed JWT’s/Google ID be directly compatible
with Endpoints + IAP (not requiring any processing/re-encoding)?

Google Accounts (G Suite) do not provide private keys to its member accounts. Therefore you cannot use Signed JWTs. Signed JWT is an older authorization mechanism and is used with service accounts. The correct method for user credentials is OAuth 2.0 Access and Identity tokens. For administrators, service accounts with Domain Wide Delegation can be used.

Will this approach accomodate external users via a federated identity
approach, in future, without major refactors to the existing process
(e.g. Firebase auth)?

This is a difficult question to answer. Google Cloud does support external identity providers but I have found this to be problematic at best. You can also use identity synchronization but this is also not well implemented. If you are going the Google Cloud route use G Suite as your identity provider and Google Cloud IAM for authorization.

An important point that I think your question lacks is understanding how authorization works in Google Cloud and Google APIs. These services primarily use OAuth 2 Access Tokens and Identity Tokens. This varies by service and with the type of access required. This means that your application will need to understand the services that it is accessing and how to provide authorization. I have a feeling that you are expecting Firebase/Endpoints to do this for you.

Another item is that Firebase is part of Google Cloud and is only a subset of Google Cloud. Firebase is a great product/service but if you are planning to use Google Cloud features outside of Firebase, then stay with G Suite and Cloud IAM for identity and authorization.

Angular SPA will be the single GUI for the application, hosted on the
same domain registered for the organisation on GCP/G Suite

I am assuming by domain you mean DNS Zone (website DNS names). This will make CORS and cookie management easier but is not a requirement.

SPA will use GCP’s api gateway (Endpoints) to make requests to GKE
micro-services (likely all within the one VPC) & other G Suite
services (Drive, etc)

OK – I don’t see any problems using Endpoints. However, a good answer requires details on how everything is actually implemented. Another item is that you are mentioning Endpoints and G Suite services. These are very different items. Endpoints protect your HTTP endpoints not other Google services where it would just get in the way.

Org IT G Suite admin’s can create users & assign various (predefined)
IAM policy groups/scopes via the G Suite UI, to give users least
privilege access to org resources (G Suite services & GCP hosted
custom api’s/apps)

Google Cloud IAM and G Suite authorization are separate authorization systems. In order for G Suite members to manage Google Cloud IAM, they will need roles assigned in Google Cloud IAM via either their member ID or group membership. There is no shared authorization permissions.

Users are ONLY able to “sign in with Google” to the SPA, using their
orgs G Suite account

Unless you configure SSO, Google Account members are the only ones that can authenticate. Authorization is managed by Google Cloud IAM.

If the User is already signed into their org google account, they
should not need to sign in again to the SPA

That is up to your application code to provide the correct Authorization header in requests.

While logged into the SPA, the users credentials should be sent with
each request, which micro-services will use for authorization of
custom business logic, as well as passing those credentials to G Suite
services like Google Drive (leverage api scopes authorization as
additional layer of security if custom business logic fails)

I am not sure what you mean by “User Credentials”. You should never have access to a user’s credentials (username/password). Instead, your application should be managing OAuth Access and Identity Tokens and sending them to the backend for authorization.

In the distant future, there is potential to allow customers/users,
external to the org, to utilize various federated identity providers
(Facebook, Twitter, etc) to access a SPA & resources hosted by the org
(this is not a current requirement, but it is a long term strategic
goal)

I covered this previously in my answer. However, let me suggest clearly thinking about what needs to be authorized. Authorization to your app is different that authorization to your app that also authorizes Google Cloud services. For example, you could use Twitter for authentication and a single service account for Google Cloud authorization. It just depends on what you need to accomplish and how you want to manage authorization.

[UPDATE]

One term that you use in your question is SPA. In the traditional use case, all processing is being done by your application in the browser. This is a security nightmare. The browser will have access to the OAuth tokens used for authorization and identity which is not secure. This also limits your application’s ability to generate Refresh Tokens which means the user will need to reauthenticate once the existing tokens expire (every 3,600 seconds). For the scope of this question, I recommend rethinking your app into a more traditional client/server design. Authentication is handled by your servers and not directly by (inside) the client application. In the sections where I mention service accounts, I am assuming that backend systems are in place so that the client only have an encrypted session cookie.