A fintech has 400 developers across payments and lending projects who assume one Developer role to access S3 buckets and DynamoDB tables. Access must auto-adjust when engineers change projects, tags carry project and clearance, and no policy update is needed for joins. Which authorization strategy should the architect implement to enforce project-based access?
Select an answer to reveal the explanation.
Short Explanation
When developers switch projects, you can let their tags determine which resources they may access instead of rewriting policies. ABAC matches the project and clearance on their session to the tags on each bucket and table, so access adjusts automatically.
Full Explanation
ABAC fits because the shared Developer role can compare principal tags supplied at sts:AssumeRole through sts:TagSession with resource tags on S3 buckets and DynamoDB tables. A policy using StringEquals for project and clearance can authorize payments or lending access without edits when engineers change projects, meeting the single-role, automatic-adjustment, and tag-driven requirements at 400-developer scale. Federating developers through separate payments and lending roles fails the single-role design and introduces role sprawl; future projects may also require new roles and trust updates. Using tag matching for S3 but broad DynamoDB access fails to enforce project isolation across both services, permitting cross-project DynamoDB access. Restricting both services by project ARNs in the shared role but manually editing its policy for each team change fails the no-policy-update requirement and does not scale. As an exam caveat, session tags must be permitted and reliably supplied, and matching must cover both project and clearance rather than relying on project tags alone. In practice, assume the role with different Project tags, inspect CloudTrail, and verify expected Allow and Deny results for a tagged bucket and table; use the policy simulator to check enforcement before onboarding.