A company integrates a third-party SaaS monitoring product that reads metrics from its AWS account. The vendor will assume an IAM role in the company account using its own AWS account, and the security team must prevent any other vendor tenant from being tricked into assuming the role on the company's behalf while still following least privilege. Which two changes to the role's trust policy together harden this cross-account access? (Select TWO.)
- ASet the trust policy Principal to a wildcard so any AWS account the vendor operates can assume the role as its fleet scales.
- BAdd a Condition on the sts:AssumeRole statement that requires the vendor's unique sts:ExternalId value to be presented. Correct
- CAttach the AdministratorAccess managed policy to the role so the SaaS product is never blocked when new metric sources appear.
- DSet the trust policy Principal to the specific ARN of the vendor's AWS account or role rather than a broad value. Correct
- EAdd an aws:SourceIp condition limiting assume-role calls to the company's own corporate office public IP range.
Why A is wrong: A wildcard principal is tempting because it avoids updating ARNs, but it lets any account assume the role and removes the boundary the requirement depends on.
Why B is correct: The external id ties each assume-role call to a secret the vendor injects, defeating the confused-deputy attack where another tenant is tricked into assuming the role.
Why C is wrong: Broad admin access seems convenient for an evolving integration, but it grants far more than read access and directly violates the least-privilege requirement.
Why D is correct: Naming the exact vendor principal in the trust policy ensures only that identity can assume the role, establishing the cross-account boundary the requirement needs.
Why E is wrong: Source IP restriction sounds protective, but the SaaS calls originate from the vendor's infrastructure, not the company office, so this would simply break the integration.