Company A runs an internal app in account A. The app needs to upload objects to an S3 bucket in account B. When the app calls S3, it receives AccessDenied for s3:PutObject. The team already created an IAM role in account B named UploadRole with a policy allowing s3:PutObject. They did not yet set up any trust relationship. Which change most directly fixes the access problem with least privilege?

Create IAM user access keys in account A and attach the UploadRole policy directly to those keys.

Using static access keys increases risk and bypasses role-based trust controls. It also does not leverage the existing role in account B. Attaching account B permissions directly to account A identities is typically not least-privilege for cross-account access.

Add s3:PutObject permissions to the bucket policy in account B for all principals in account A.

Bucket policies can grant access, but granting broadly to account A principals is harder to keep least-privileged. It also does not address that sts:AssumeRole must be authorized for the app to use the intended role. This option ignores the missing trust relationship root cause.

Attach an SCP (service control policy) in AWS Organizations to deny sts:AssumeRole unless the caller uses an MFA device.

An SCP can restrict actions at the organization level, but it won’t fix the current AccessDenied stemming from missing trust. If MFA enforcement is needed, it should be reflected in an appropriate condition in the trust policy, not as the primary missing permission.

What does this SAA-C03 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Update the trust policy on UploadRole (account B) to allow sts:AssumeRole from the app’s IAM role or principal in account A. — For cross-account S3 access using a role in account B, you need two pieces: (1) a permissions policy on UploadRole that allows s3:PutObject, and (2) a trust policy on UploadRole that permits a specific principal in account A to call sts:AssumeRole. Your scenario states the permissions are already present and trust relationships were not configured. Adding the trust policy for only the app’s role/principal enables temporary credentials and resolves the AccessDenied while keeping access scoped. Why others are wrong: Options A and C misunderstand cross-account authorization. Static access keys or broad bucket-policy grants avoid least-privilege and do not directly address the missing sts:AssumeRole trust. Option D introduces an org-level restriction unrelated to the described missing trust configuration; SCPs can deny access but cannot create the required trust to assume the role.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.