Given that you've already ruled out the typical suspects (ARN format, external ID, trust policy, permissions policy, SCPs, propagation delay, role-specific corruption), this is most consistent with a known, somewhat misleadingly-named issue rather than an actual permissions problem.
Most likely cause: race condition in role propagation, not a real validation failure
Databricks support has documented this exact error as occurring due to a timing/race condition between when IAM treats the role as "ready" (creation API returns success) versus when it's actually fully consistent and assumable across AWS's distributed IAM backend. This issue can occur due to a race condition when the cross-account role configuration is applied. If you re-run the operation after getting the Failed credential validation checks error, the operation is successful and does not result in an error message. The fix that's typically recommended is adding an artificial delay (10+ seconds, sometimes people need 30-60s) between role/policy creation and the credential validation call. Since you mentioned testing "several minutes" between creation and retry, this is less likely to be your root cause, but it's worth knowing that the error message itself is generic and fires for several unrelated underlying issues.
Given you've eliminated the obvious causes, here's what I'd check next, roughly in order of likelihood:
1. SCP scope check it was evaluated for the right principal/region, not just "applied"
You said SCP review only shows FullAWSAccess with no restrictions, but it's worth double-checking that specifically: if you are unsure, ask your AWS administrator about SCPs that deny the AssumeRole action or deny EC2/VPC access. SCPs attached at the OU level (not directly to the account) are easy to miss in a quick review, as are SCPs applied to a parent OU above where you checked. Also worth checking: any permission boundaries on the role itself, not just the policy attached to it.
2. The policy document content vs. just "permissions look right"
Since validation explicitly checks against a specific expected policy shape for Databricks-managed VPC, even a structurally valid policy with extra/missing actions, a different `Sid`, or JSON formatting differences from the documented template can trigger this. If the credential configuration validation fails ten or more checks, it's more likely that the trust relationship of the IAM role is incorrectly set up. I'd suggest doing a byte-for-byte diff against the current documented policy (not a cached/older copy), since Databricks does update these periodically.
3. Account API connectivity is confirmed working, but check the exact endpoint/account ID used for credentials
You confirmed storage configuration succeeded, which is good evidence the API path is generally healthy but it's worth confirming you're calling the credentials endpoint against the same Databricks account ID used for storage (a stale or wrong account ID is a known cause of this exact error per a recent SDK bug report).
4. Open a Databricks support case if you haven't
Since this error code is deliberately generic and you've exhausted client-side checks, Databricks support can look at server-side validation logs for your account/region to see the *specific* check that's failing โ this is the only way to get past the generic message at this point.
