District file uploads land under s3://bucket/{tenantId}/... and IAM policies must ensure a principal can only access its own tenant prefix. Which pattern supports enforceable isolation?
Select an answer to reveal the explanation.
Short Explanation
Folders named by tenantId are only as strong as the IAM bouncer checking the path. Put objects under /{tenantId}/ and condition policies so principals cannot wander into a neighbor's prefix.
Full Explanation
District file uploads under s3://bucket/{tenantId}/... support enforceable isolation when IAM or session policies constrain s3:prefix (or related path conditions) so a principal can only access its own tenant prefix. Layout plus IAM conditions is the classic multi-tenant S3 pattern for municipal district separations: folders named by tenantId become a real boundary only when the bouncer checks the path on every request.
Using a single shared prefix with object ACL public-read fails because public ACLs and shared prefixes do not enforce per-tenant server-side isolation. Disabling all bucket policies and depending on CloudFront signed cookies alone fails conceptually for API uploads that hit S3 with IAM principals—cookies are not a substitute for prefix conditions on those identities. Storing tenantId only in overwritable object metadata tags fails because anonymous or malicious writers can change tags after upload.
Exam caveat: condition keys must match how the SDK requests are signed (prefix vs full key); misaligned conditions create false confidence. Operational check: attempt List/Get on another tenant's prefix with a district role, confirm AccessDenied, and review session policies minted at login that inject the caller's tenantId.