A county payments Lambda in Account A must write audit objects into a logs bucket owned by Account B. Which approach correctly grants temporary, scoped access?
Select an answer to reveal the explanation.
Short Explanation
Picture Account A knocking on Account B’s records room with a visitor badge, not the master key. STS AssumeRole hands the Lambda short-lived credentials for just that audit prefix. Public buckets and root keys are how cities end up on the news.
Full Explanation
Cross-account writes are typically implemented with STS AssumeRole: Account B defines a role that trusts Account A’s principal and grants least-privilege S3 permissions, and the Lambda assumes that role before PutObject. Embedding another account’s long-term keys or opening the bucket publicly violates least privilege. Broad AdministratorAccess in Account A cannot by itself authorize writes into Account B’s bucket without Account B’s resource or role trust configuration.