Which solution will meet these requirements?
Delete the IAM user’s access key Immediately. Create a new access key to update in the legacy application.
Create a new access key for the IAM user. Update the latest application version to use the new access key. Deactivate the compromised access key.
Attach an IAM policy to revoke all sessions from before the time of the AWS Abuse notification.
Update the legacy application to use an IAM role that has the same permissions as the IAM user.
Explanations:
Deleting the IAM user’s access key immediately would cause downtime for the legacy application until a new key is created and updated in the application.
Creating a new access key, updating the legacy application, and deactivating the compromised key minimizes downtime by allowing the application to continue using the new key while the compromised key is disabled.
Revoking sessions would not stop the compromised access key from being used again and doesn’t address the key being actively used in the legacy application.
While using IAM roles is a good practice, it would require a modification to the application to switch from an IAM user to an IAM role, which could introduce more downtime.
I map out that the answer is:
Create a new access key for the IAM user. Update the latest application version to use the new access key. Deactivate the compromised access key.
From my perspective, the answer is:
Create a new access key for the IAM user. Update the latest application version to use the new access key. Deactivate the compromised access key.