Uploads to a municipal evidence bucket should succeed only when the object key prefix matches the caller’s department tag. Which IAM technique enforces that attribute-based rule?
Select an answer to reveal the explanation.
Short Explanation
Think of the evidence room stamping each badge with a department code before anyone shelves a box. IAM conditions bind that PrincipalTag to the object prefix so uploads cannot wander into another department’s aisle. Trusting the client alone is wishful thinking.
Full Explanation
Municipal evidence uploads should succeed only when the object key prefix matches the caller’s department. Attribute-based access control via IAM condition keys—tying a principal tag such as department to s3:prefix or related condition keys—enforces that rule in the authorization layer so PublicWorks cannot plant objects under Police/ without a policy change. The client still supplies a key, but IAM rejects mismatches instead of trusting honor-system path selection.
Storing department names in a public S3 inventory file and trusting the client to pick the right prefix is not enforcement. Allowing s3:PutObject on "*" with no conditions invites cross-department writes. Turning off versioning so “incorrect prefixes overwrite each other safely” neither authorizes correctly nor protects evidence integrity; versioning is unrelated to ABAC prefix binding.
Exam caveat: tags must be present and trustworthy on the principal (and sometimes the resource); missing tags often fail closed depending on how conditions are written—test both match and mismatch paths. Operational check: assume a role tagged Department=Parks, PutObject under parks/ successfully, attempt PutObject under finance/, and confirm AccessDenied while CloudTrail shows the denied call with the tagged session.