SAA-C03 Practice Question 1: Cross Account Role Access

Cross-account access in AWS is designed around role assumption. You create a role in the trusting (resource-owning) account whose trust policy names the partner's account as a principal, and attach a permissions policy scoped to the bucket. The partner's principals call sts:AssumeRole and receive temporary credentials that expire on their own. Nothing long-lived ever crosses the account boundary, and you revoke access unilaterally by editing the trust policy or deleting the role.

Option A creates exactly what the partner's security policy forbids: long-lived access keys issued by your organization. It also puts you on the hook for rotating and offboarding every individual developer, and IAM users are the pattern AWS explicitly steers you away from for this scenario.

Option B relies on S3 ACLs. Object Ownership defaults to Bucket owner enforced on all newly created buckets, which disables ACLs entirely; you would first have to weaken the bucket's configuration. Even then, ACLs grant coarse account-level access and cannot be scoped to particular IAM principals or conditions the way a role's permissions policy can.

Option D works for handing out a handful of objects, but a presigned URL is a bearer token derived from the signer's own credentials, valid for a fixed lifetime, and generated per object. It does not scale to a bucket, does not cover objects created later, and cannot be revoked individually without invalidating the signing credentials.

Reference: Tutorial: Delegate access across AWS accounts using IAM roles