A platform team lets three vendor accounts deploy to a central production account, but auditors found long-lived access keys and overly broad PowerUser access with no scoping by project. Vendors must get short-lived project-scoped access with a controllable maximum. Which least-privilege cross-account design enforces temporary project-scoped vendor access?

The correct design succeeds because STS role assumption provides short-lived credentials that remove long-lived keys, per-project roles isolate each workload, ABAC session tags enforce dynamic project scoping at request time, external IDs block confused-deputy reuse across the three third-party vendor accounts, and permissions boundaries set a controllable maximum that caps effective permissions even if identity policies broaden, fully meeting temporary, scoped least privilege. The managed-policy federation approach fails the maximum concept because managed policies only grant permissions and cannot define an upper bound, so privilege can still expand to the full policy scope. The OIDC federation approach fails because the vendors are AWS accounts assuming roles cross-account, and OIDC trust offers no external ID protection against confused-deputy assumption despite correct tagging and boundaries. The per-vendor broad-access approach fails scoping because granting full production access by vendor ignores the required project boundary and retains excessive reach. For exams, do not equate short session duration with least privilege, and expect external ID plus ABAC plus boundaries together for vendor patterns. As a practical check, test AssumeRole with missing or wrong project tags and external IDs and validate denials in CloudTrail plus effective permissions in IAM Access Analyzer.