What should the SysOps administrator do to meet these requirements?
Create an IAM role and instance profile that include AWS Systems Manager permissions. Attach the role to the on-premises servers.
Create a managed-instance activation in AWS Systems Manager. Install the Systems Manager Agent (SSM Agent) on the on-premises servers. Register the servers with the activation code and ID from the instance activation.
Create an AWS managed IAM policy that includes the appropriate AWS Systems Manager permissions. Download the IAM policy to the on-premises servers.
Create an IAM user and an access key. Log on to the on-premises servers and install the AWS CLI. Configure the access key in the AWS credentials file after the AWS CLI is successfully installed.
Explanations:
Creating an IAM role and instance profile is correct for EC2 instances in AWS, but this option is not suitable for on-premises servers because it involves attaching a role to instances, which is not possible for on-premises servers.
This is the correct option. By creating a managed-instance activation in AWS Systems Manager and installing the SSM Agent on the on-premises servers, you can securely automate tasks without the need for long-term credentials. The activation code allows the servers to be registered with Systems Manager.
Downloading and installing IAM policies on on-premises servers is not a feasible approach. IAM policies should be attached to roles, not directly to servers. Additionally, this does not eliminate the need for long-term credentials.
Using IAM user credentials and storing them on on-premises servers is not a secure practice, as it involves managing long-term credentials on the servers. This contradicts the requirement to avoid long-term credentials.
I guess:
Create a managed-instance activation in AWS Systems Manager. Install the Systems Manager Agent (SSM Agent) on the on-premises servers. Register the servers with the activation code and ID from the instance activation.