A SaaS company has 40 product teams deploying EC2 and S3 resources tagged Project=Alpha or Beta. Engineers switch projects often, and operators want single roles with access scoped automatically by project without creating new policies per team. Which ABAC and RBAC authorization strategy should the architect design?
Select an answer to reveal the explanation.
Short Explanation
You’re tired of cutting new keys for every door, so let badges do the work with ABAC. When you assume the role with a project session tag that matches a resource tag, access clicks open automatically without policy sprawl.
Full Explanation
The session-tag design works because one IAM role configured for sts:TagSession lets you pass a Project tag when you assume the role; that tag becomes aws:PrincipalTag, and one reusable policy compares it with aws:ResourceTag/Project for both EC2 and S3. This scopes each request dynamically to Alpha or Beta without new policies as teams scale. Shared RBAC job-function roles with separate project managed policies can use resource-tag conditions, but they require additional policies to be authored and attached for each project, recreating the policy sprawl the scenario rules out. Persistent IAM user Project tags can also match identity tags to resource tags, but administrator-updated tags cannot change per session, so they do not support engineers switching projects or isolate concurrent Alpha and Beta access as session tags do. A single role with session Project tags that scopes EC2 but allows broad S3 access fails because S3 requests are not checked against the Project resource tag, permitting cross-project data access. As an exam caveat, permission boundaries and SCPs limit maximum privilege or organizational-unit capability; they do not provide scalable principal-to-resource tag authorization. As a practical check, assume the role with Project=Alpha and then Project=Beta, and use the policy simulator and CloudTrail to verify that EC2 and S3 allows and denies align with matching resource tags.