A library consortium attaches an S3 bucket policy that allows public GetObject for open catalogs while denying deletes except to a dedicated backup role. What does this illustrate about secure access design?
Select an answer to reveal the explanation.
Short Explanation
The bucket itself can wear a name tag that says “anyone may read the catalog, but only BackupRole may delete.” That is a resource policy working with identity policies, not instead of them. S3 access is often both who you are and what the bucket allows.
Full Explanation
An S3 bucket policy that allows public GetObject for open library catalogs while denying deletes except to a dedicated backup role illustrates resource-based access control working together with identity-based policies. The bucket itself declares who may act on it: anonymous or public principals may read objects, but DeleteObject is denied unless the caller is the backup role. Identity policies on that role still need delete permission; both evaluations must allow the action (with explicit Deny winning). This complementarity is central to secure S3 design for municipal open data.
Claiming only identity-based IAM policies can allow or deny S3 actions is false—bucket policies are first-class resource policies. Asserting that public GetObject requires disabling encryption and MFA Delete confuses independent controls; encryption and MFA Delete address different risks and are not prerequisites for public read of non-sensitive catalogs. Saying bucket policies replace the need for any IAM roles or principals is also wrong: privileged operations still need authenticated principals with identity permissions, and many patterns use both policy types.
Exam caveat: public access also interacts with the S3 Block Public Access account and bucket settings—those must allow the intended public policy or the GetObject grant will not take effect. Prefer CloudFront for public distribution when you need edge controls. Operational check: anonymously GET a catalog object successfully; attempt DeleteObject without the backup role and expect denial; assume the backup role and delete only where intended; confirm Block Public Access configuration matches the open-catalog design.