Best Way to Access Resources in Another AWS Account

Answer - A.

The AWS Documentation mentions the following.

For cross-account access, imagine that you own multiple accounts and need to access resources in each account.

You could create long-term credentials in each account to access those resources.

However, managing all those credentials and remembering which one can access which account can be time consuming.

Instead, you can create one set of long-term credentials in one account and then use temporary security credentials to access all the other accounts by assuming roles in those accounts.

All other options are incorrect since the right option is to use cross-account roles.

For more information on Assuming a Role, please refer to the below URL-

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

The best way to access resources in another AWS account as a developer is to create a cross-account role and call the AssumeRole API. This approach enables you to delegate access to resources in the destination account without having to share long-term security credentials such as passwords or access keys.

When you create a cross-account role, you define a trust policy that specifies the accounts and entities that can assume the role. The trust policy must be created in the destination account and must allow the source account to assume the role. Once the trust policy is in place, you can call the AssumeRole API to obtain temporary security credentials that enable you to access the resources in the destination account.

Using this method, you can grant granular permissions to the role, allowing developers to access only the specific resources they need to perform their tasks. Additionally, the temporary security credentials obtained via AssumeRole have a limited lifespan, so you can ensure that access to the resources is granted only when it is needed.

The other options provided are not recommended for several reasons:

• Creating a user in the destination account and sharing the password is not recommended because it violates the AWS security best practices of never sharing long-term security credentials. It also poses a risk of unauthorized access if the password is compromised.
• Creating a user in the destination account and sharing the access keys also violates the best practices of never sharing long-term security credentials. Additionally, it is difficult to revoke access when using shared access keys, as you would need to rotate the keys across all systems that use them.
• Creating an IAM role and attaching it to an EC2 instance is not recommended as it only allows access to the resources from that specific EC2 instance. It is also not an ideal solution if you need to provide access to resources to multiple developers from different locations or systems.