A company has hired an external vendor to work in the company’s AWS account.

The most secure way to grant an external vendor’s AWS-hosted automation tool access into a company AWS account is to use cross-account IAM role assumption. Option A follows the standard AWS pattern: the company creates an IAM role in its own account that has only the permissions the vendor needs, and the role’s trust policy allows the vendor’s IAM role (in the vendor’s AWS account) to assume it. This approach avoids creating long-lived credentials in the company account and supports least privilege, auditing, and easy revocation.

With role assumption, the vendor continues to authenticate in its own AWS account and uses AWS STS to obtain temporary credentials when accessing the company account. Temporary credentials reduce exposure compared to access keys because they expire automatically and can be constrained with session duration, external IDs (where appropriate), and conditions. The company retains full control over permissions through the role policy, and CloudTrail can record AssumeRole events and subsequent API activity for auditing.

Option B is less secure because it creates an IAM user in the company account and would typically require managing long-lived credentials for the vendor tool, increasing the risk of leakage and ongoing operational overhead. Option C is not valid because IAM users are not shared across accounts; you cannot “add” a user from another account into an IAM group in your account. Option D is incorrect because “AWS account” is not a typical IAM identity provider type for this purpose; cross-account access is done through role trust policies, not by creating an IdP with an AWS account ID and username.

Therefore, A is the most secure solution because it uses short-lived credentials, enforces least privilege, centralizes control in the company account, and provides strong auditability without issuing permanent access keys.