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 from a county payments Lambda in Account A into Account B’s logs bucket should use STS AssumeRole. Account B defines a role that trusts Account A’s principal and permits PutObject on the audit prefix; the Lambda assumes that role and uses the returned temporary credentials for the put. Access is scoped, time-bound, and auditable in both accounts—the standard pattern for municipal shared-logging architectures.
Copying Account B’s root access keys into the Lambda environment is catastrophic secret sharing and nearly impossible to rotate safely. Making the logs bucket public-read/write removes authentication and allows anyone to plant or read audit objects. Attaching AdministratorAccess to the Lambda in Account A cannot by itself authorize writes into Account B’s bucket; the resource owner must grant access via a role trust plus permissions or a bucket policy.
Exam caveat: both the trust policy (who may assume) and the permissions/bucket policy (what the role may do on which prefix) must align; missing either side breaks cross-account access. Operational check: assume the Account B role from a test invoke, PutObject under the audit prefix successfully, attempt PutObject outside that prefix, and verify CloudTrail in Account B attributes allowed writes to the assumed role session.