A SaaS vendor needs temporary cross-account access to a client's audit bucket scoped to project Atlas, with MFA, no static keys, automatic expiry, and per-project isolation enforced by tags. Which least-privilege design using roles and conditions best meets these constraints?

The correct design succeeds because it combines STS-based cross-account assumption with external ID to prevent confused-deputy reuse, ABAC tag matching to enforce per-project isolation for Atlas, inline session policies to dynamically down-scope vendor permissions, short-lived credentials for automatic expiry without static keys, and an MFA condition to satisfy strong authentication under least privilege. The design using short session expiry but omitting the MFA condition fails authentication assurance because STS will still issue credentials without proof of second-factor presence, violating an explicit constraint even though isolation and temporariness remain intact. The design relying on resource ARN scoping with MFA and short expiry fails governance scalability because hard-coded bucket ARNs provide isolation without tag-enforced ABAC, so new Atlas resources require policy rewrites and tag policy drift is not centrally denied. The design allowing durable long-lived trust with correct tags and MFA fails temporariness because persistent assumption without maximum session duration leaves standing access that outlives the audit window and widens blast radius. As an exam caveat, distinguish resource-based scoping from tag-based ABAC and remember that external ID alone does not replace MFA or expiry, with distractors often pairing three correct controls with one omission. As a practical check, test with distinct Atlas and non-Atlas tags, attempt assumption without MFA and without external ID, and verify CloudTrail shows denied events and STS credentials expiring as expected.