CCSP Practice Question: A developer configures an AWS S3 bucket to allow…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Mass assignment

  Why it's wrong here

  Mass assignment occurs when an application binds user-supplied input directly to object properties, letting attackers set fields they should not control. Here the exposure comes from a bucket policy's wildcard principal, with no application-layer parameter binding involved; mass assignment would fit a vulnerable API accepting unfiltered JSON.

• ✗

  SSRF vulnerability

  Why it's wrong here

  SSRF arises when a server fetches a user-supplied URL, letting attackers reach internal endpoints. This bucket policy simply grants anonymous s3:GetObject; no request-forwarding component exists. SSRF would be correct if an application accepted a URL parameter and retrieved it server-side, exposing metadata services or internal hosts.

• ✓

  Exposed S3 bucket

  Why this is correct

  Granting `s3:GetObject` to `Principal: *` in a bucket policy authorises anonymous, unauthenticated reads of every object, directly satisfying the stem's public-access configuration. This is the defining mechanism of an exposed S3 bucket: no IAM identity, signed request, or credential is required, so anyone with the object URL retrieves the data.

• ✗

  Over-permissive IAM

  Why it's wrong here

  A wildcard principal granting s3:GetObject is an anonymous, unauthenticated read exposure, not an IAM identity misconfiguration. Over-permissive IAM describes identities holding excessive permissions; it would be the answer if a role or user policy granted broader actions than required, rather than the bucket policy exposing objects publicly.