A media company has 400 editors across brands using one portal role, needs brand-level access to S3 prefixes, must avoid creating 40 IAM roles, and wants access to follow project tags automatically. Which authorization strategy enforces scalable brand-level access with tags?
Select an answer to reveal the explanation.
Short Explanation
You can replace forty separate roles with one smart badge that reads the brand label. ABAC matches your principal’s brand tag to the S3 prefix path, so access follows you as project assignments change.
Full Explanation
Attribute-based access control lets one portal role scale across hundreds of editors: the identity provider passes each editor’s brand as a session tag, and the policy uses the aws:PrincipalTag/brand variable in the S3 resource path (for example, bucket/${aws:PrincipalTag/brand}/*). Editors can then reach only their brand’s prefix, without creating roles for each brand, and access changes when the tag changes. Maintaining a separate S3 prefix policy for each brand fails to provide tag-driven automation because administrators must update the static lists when brand access changes. Matching principal tags to project-team resource tags fails to enforce brand boundaries: team membership is not necessarily aligned with brand ownership, so teams spanning brands could allow cross-brand access. Matching principal tags to S3 object tags fails to establish prefix-level access: tags apply to individual objects, must be set correctly on each object, and do not scope listing of a brand prefix or provide a path-based boundary. Exam caveat: ABAC questions hinge on matching the principal attribute to the relevant resource attribute; for S3 prefixes, that is the key path. As a practical check, confirm the identity provider passes brand as a session tag, the trust policy allows sts:TagSession, and validate access with the policy simulator and CloudTrail for each brand.