A partner county role in another AWS account must read objects under a shared GIS export prefix in the city’s S3 bucket. Which policy placement is the clean cross-account pattern?
Select an answer to reveal the explanation.
Short Explanation
Put the welcome mat on the bucket itself: a resource-based policy naming the partner role and the GIS prefix. That beats mailing city access keys or opening the whole bucket to the internet. Partner IAM users inside your account are the messy hallway.
Full Explanation
Cross-account read access for a partner county role to a shared GIS export prefix is cleanest with an S3 bucket resource policy that allows that partner role (or account principal) s3:GetObject on the specific prefix. The partner continues to authenticate in their own account; the city grants access on the resource without creating local IAM users for every partner engineer.
Creating IAM users in the city’s account for every partner engineer and emailing passwords does not scale and mixes workforce admin into a partner integration. Making the entire bucket public and sharing a URL removes authentication and exposes non-export data if the bucket holds more than the GIS prefix. Copying the city’s access keys into the partner CI secrets shares long-term credentials across trust boundaries.
Exam caveat: the partner’s identity policy must also allow the GetObject action; resource policy alone is necessary but not always sufficient depending on the principal type—both sides should align. Operational check: from the partner role, GetObject an object under the shared prefix successfully, attempt a key outside the prefix, and confirm denial; review CloudTrail in the city account for the cross-account principal.