A gaming application lets people play immediately and only later sign in with their Google account, which is an OpenID Connect provider. After a Google sign-in the client must call Amazon DynamoDB directly using the AWS SDK with temporary credentials scoped to that user. The team does not run its own user directory and does not want a Cognito user pool in the path. Which approach lets the client obtain temporary AWS credentials from the Google sign-in?
- ASend the Google OpenID Connect token straight to AWS STS AssumeRoleWithWebIdentity from the client, because STS trusts any well-formed Google token and returns DynamoDB credentials without further setup.
- BConfigure an Amazon Cognito identity pool with Google registered as an OpenID Connect provider, then exchange the Google token through the identity pool for temporary credentials from an assumed IAM role. Correct
- CCreate a Cognito user pool with Google as a federated provider so the user pool issues AWS access keys after the Google sign-in completes for the client.
- DEmbed a single shared IAM access key inside the application bundle and let the validated Google token decide when the client is allowed to read that key and sign DynamoDB calls with it.
Why A is wrong: AssumeRoleWithWebIdentity needs an IAM role whose trust policy is configured for the specific provider audience, so calling STS with no role and no provider registration would be rejected.
Why B is correct: An identity pool accepts external OpenID Connect providers such as Google, validates the token, and calls STS to return short-lived role credentials that the SDK uses to sign DynamoDB calls with no stored keys.
Why C is wrong: A user pool issues JWT identity and access tokens rather than AWS access keys, and the requirement explicitly excludes a user pool from the credential path for these calls.
Why D is wrong: A shared long-lived access key in a distributed client can be extracted and never rotates, and the token cannot scope credentials per user, so least privilege is not met.