Cross-account credential validation failing (MALFORMED_REQUEST) with correctly-configured IAM role

Sonian — Tue, 30 Jun 2026 12:49:20 GMT

Unable to create a credential configuration via the Account Console (and originally via the AWS Quick Start CloudFormation template). Both the automated CloudFormation createCredentials custom resource and manual credential configuration attempts fail with the same generic error, despite thorough verification of all standard prerequisites.

Error received: MALFORMED_REQUEST: Failed credential validation checks: please use a valid cross account IAM role with permissions setup correctly.

Troubleshooting performed (full verification checklist):

Role ARN format verified correct (no typos, correct account ID, no trailing whitespace) — tested with two independently created roles
External ID verified to exactly match Databricks account ID, confirmed directly from Account Console
Trust policy principal verified
Region availability confirmed: us-west-2 is enabled by default, STS endpoint active
Permissions policy verified against documented cross-account policy for Databricks-managed VPC (EC2 actions + Spot service-linked role statement)
SCP review completed at AWS Organization level — only FullAWSAccess applied, no restrictions
IAM propagation delay ruled out (several minutes elapsed between role creation and retry)
Confirmed credential validation fails identically on both a pre-existing IAM role and a freshly created, dedicated role — ruling out role-specific history/corruption as a cause
Storage configuration step succeeded independently (storage_configuration_id: XXXXXXXX), confirming Account API connectivity/auth is otherwise functional

Re: Cross-account credential validation failing (MALFORMED_REQUEST) with correctly-configured IAM ro

aliyasingh — Tue, 30 Jun 2026 13:29:21 GMT

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.

topic Cross-account credential validation failing (MALFORMED_REQUEST) with correctly-configured IAM role in Get Started Discussions

Cross-account credential validation failing (MALFORMED_REQUEST) with correctly-configured IAM role

Re: Cross-account credential validation failing (MALFORMED_REQUEST) with correctly-configured IAM ro