An application running on an Amazon EC2 instance in account A must read objects from an Amazon S3 bucket owned by account B. The security team forbids long-lived access keys and wants the application to obtain temporary credentials scoped only to that bucket. Account B has created an IAM role whose trust policy allows account A to assume it. How should the application obtain credentials to call S3 in account B?
- ACreate an IAM user in account B, generate an access key pair, and store the key and secret in the application configuration so the SDK signs S3 requests directly.
- BAdd the account B bucket to a resource policy on the account A instance role so the SDK automatically uses the instance credentials to reach the cross-account bucket.
- CEnable cross-account access by attaching the account B role directly as a second instance profile so the SDK presents both roles when it calls the S3 bucket.
- DCall AWS STS AssumeRole with the account B role ARN using the instance role credentials, then use the returned temporary credentials to sign the S3 requests. Correct
Why A is wrong: An IAM user access key pair is a long-lived static credential that does not rotate and must be stored, which directly breaks the requirement to avoid long-lived keys.
Why B is wrong: An identity policy in account A cannot by itself authorise calls into account B, and the instance credentials are scoped to account A, so the cross-account read still fails without assuming the role.
Why C is wrong: An EC2 instance can have only one instance profile and roles cannot be stacked that way, so this is not a valid mechanism for reaching the other account at all.
Why D is correct: AssumeRole returns short-lived credentials for the trusted account B role, and signing S3 calls with them gives scoped cross-account access with no stored static keys at all.