How should a solutions architect grant this access to the vendor?
Create an IAM role in the company’s account to delegate access to the vendor’s IAM role. Attach the appropriate IAM policies to the role for the permissions that the vendor requires.
Create an IAM user in the company’s account with a password that meets the password complexity requirements. Attach the appropriate IAM policies to the user for the permissions that the vendor requires.
Create an IAM group in the company’s account. Add the tool’s IAM user from the vendor account to the group. Attach the appropriate IAM policies to the group for the permissions that the vendor requires.
Create a new identity provider by choosing “AWS account” as the provider type in the IAM console. Supply the vendor’s AWS account ID and user name. Attach the appropriate IAM policies to the new provider for the permissions that the vendor requires.
Explanations:
Creating an IAM role in the company’s account allows for secure delegation of access to the vendor’s IAM role. This enables the vendor to assume the role and perform necessary actions without directly granting IAM access to their account. The permissions can be controlled and managed via the attached IAM policies.
Creating an IAM user in the company’s account does not align with best practices for granting external access. It requires managing credentials and would give direct access rather than a temporary, role-based access which is more secure and manageable.
IAM groups cannot include users from external AWS accounts; they only manage users within the same account. This approach would not provide the necessary access to the vendor, making it an incorrect choice for this scenario.
Creating a new identity provider for the vendor’s AWS account ID is not a valid method for granting access. IAM identity providers are used for federated access, but this option does not fit the context of allowing a vendor’s IAM role to access resources in the company’s account.