A logistics firm hosts shipment data in a central account and hires an analytics vendor using its own AWS account for quarterly reporting. The vendor must access only the s3://shipments/partner/ prefix for 4 hours at a time, vendor sessions must be confined even if the role policy grows, and confused-deputy access must be blocked. Which temporary-credential design enforces least-privilege cross-account access for this vendor?
Select an answer to reveal the explanation.
Short Explanation
You've got a guest who needs one cabinet for one afternoon, not house keys. Session policies shrink each vendor session to that prefix and time window while boundaries and external ID lock the door.
Full Explanation
The correct approach combines a cross-account role with external ID condition to prevent confused-deputy attacks, ABAC conditions to limit access to the tagged partner prefix, a permissions boundary to cap maximum permissions regardless of future role policy changes, and session policies passed during AssumeRole to further scope down each short-lived session. ABAC plus short session duration satisfies the time and prefix constraint without creating static credentials. Creating a role with only ABAC tags and a managed read-only policy fails because AWS managed read-only is far broader than the required prefix and provides no session scoping or confused-deputy protection without external ID. Creating an IAM user with access keys violates temporary-credential and least-privilege principles by issuing long-term credentials that must be rotated and can be exfiltrated. Granting S3 full access with external ID fixes confused deputy but ignores data minimization and boundary controls, allowing access beyond the partner prefix. For the exam remember external ID is required for third-party cross-account trust, while permissions boundaries and session policies intersect to produce the effective permission. In practice verify with IAM Access Analyzer and test AssumeRole with session tags and duration.