The correct answer is: Create an IAM role in the company's account that trusts the vendors AWS account. Attach the required IAM policies to the role to define the vendors permissions.

This solution uses cross-account IAM roles, a best practice for granting access between AWS accounts. The vendors tool can assume the role from their own account if the trust policy permits it. This avoids the need for IAM users, credentials, or manual access, and gives the company full control over what permissions are granted and for how long. It also enables auditing and logging via AWS CloudTrail.

Why the other options are incorrect:

Creating an IAM user in the companys account introduces credential management issues and violates least privilege principles. It also makes tracking access more difficult and is not scalable or secure for automated tools across accounts.

Creating an IAM group and attempting to add a user from another AWS account is not technically possible. IAM groups cannot include users from external AWS accounts.

Creating an identity provider with type 'AWS account' is a misunderstanding of identity federation. That option is used for integrating identity providers like SAML or OIDC-based systems, not for cross-account AWS-to-AWS access.

Why this question is important: It tests your knowledge of secure cross-account access in AWS, especially in B2B contexts where one organization needs to give scoped, auditable access to anothers AWS resources.

Tip: When you need to allow services in another AWS account to access your resources, consider using IAM roles with trust policies targeting that account. Avoid IAM users in shared accounts.

Full AWS Practitioner Certification Question