A Lambda function in Account A must upload reports to an S3 bucket in Account B. Security does not want long-lived access keys anywhere, and the access should be easy to revoke from Account B. Which approach is best?

Create an IAM user in Account B and store its access keys in Lambda environment variables.

Static access keys are long-lived credentials and create unnecessary operational and security risk.

Attach a security group to the Lambda function that allows outbound traffic to the bucket.

Security groups do not grant S3 permissions, and Lambda does not use security groups as an authorization mechanism for S3 access.

Use AWS Organizations SCPs to grant the Lambda function permission to write to the bucket.

SCPs can only restrict permissions, not grant access to a specific workload or resource.

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: Create an IAM role in Account B that Account A can assume through STS, then grant the role S3 permissions. — The best design is to use STS role assumption across accounts. Account B owns the role and its permissions, so it remains in control of who can access the bucket and can revoke access centrally at any time. Lambda in Account A uses its execution role to assume the cross-account role and receives temporary credentials, which eliminates long-lived secrets and supports least privilege. Why others are wrong: Embedding access keys creates static credentials that are harder to secure and revoke. Security groups are not an authorization tool for S3 access. SCPs are guardrails, not permission grants, so they cannot be used to hand a workload access to a bucket in another account.

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.