A SaaS company with 200 engineers runs 50 projects tagged Project=Alpha, Beta, and more, with developers federated via Okta constantly joining teams. Static per-project IAM roles cause delays and privilege sprawl. Which ABAC and role strategy grants project access dynamically based on tags?

The correct design succeeds because a single reusable developer role combined with aws:PrincipalTag equals aws:ResourceTag on Project decouples permission logic from headcount and project count, while federation with TagSession injects the engineer's current Project membership as session tags at assume-role time so authorization is evaluated dynamically without rewriting policies. The persistent IAM user tag variant fails on identity lifecycle because long-lived users cannot represent Okta-federated engineers who constantly join teams, requiring manual tagging and cleanup and reintroducing the delay the scenario explicitly rejects even though its match logic is tag-based. The ARN-based authorization variant fails on resource dynamism because even with valid Okta session tags, requiring explicit resource names means every new Alpha, Beta or follow-on project resource forces policy edits rather than inheriting access from matching tags. The per-value federated role variant fails on role economy because maintaining fifty parallel roles with identical ABAC conditions preserves the sprawl and trust-policy churn the stem says must be eliminated, even though each role correctly uses session tags and tag matching. For the exam, remember ABAC requires both sides: a permissions policy with tag-equality conditions plus a role trust policy allowing sts:TagSession and sts:AssumeRoleWithSAML with appropriate tag conditions, otherwise session tags are silently dropped. In practice, validate Okta attribute statements map Project correctly, assume the role and inspect CloudTrail and GetCallerIdentity principal tags, then test cross-project deny with an untagged or mismatched Project value.