What should the security engineer do to meet these requirements?
In the CloudTrail console, under CloudTrail event history, search by access key for the compromised key, with the correlated events, and identify which IAM user the key belongs to. In the IAM console, revoke all active sessions for that IAM user.
Create a new CloudTrail trail. In the CloudTrail console, under CloudTrail event history, search by access key for the compromised key, view the correlated events, and identify which IAM user the key belongs to. In the IAM console, revoke all active sessions for that IAM user.
Create a new CloudTrail trail. In the CloudTrail console, under CloudTrail event history, search by access key for the compromised key, view the correlated events, and identify which IAM role the key belongs to. In the IAM console, delete that IAM role.
In the CloudTrail console, under CloudTrail event history, search by access key for the compromised key, view the correlated events, and identify which IAM role the key belongs to. In the IAM console, revoke all active sessions for that IAM role.
Explanations:
CloudTrail event history requires a trail to be enabled to capture events, but the account does not have CloudTrail configured. The IAM user might not be directly correlated with the IAM access key, and revoking sessions for the user wouldn’t stop the compromised access key immediately.
A new CloudTrail trail is needed to track activities, but the compromised key is from AWS STS, which issues temporary credentials, not an IAM user. Revoking sessions for an IAM user doesn’t affect the compromised access key in AWS STS.
A new CloudTrail trail would allow searching for events, but the compromised access key is issued by AWS STS, which grants temporary credentials tied to a session, not an IAM role. Deleting the IAM role wouldn’t stop the access key from being compromised.
A new CloudTrail trail should be created since CloudTrail wasn’t previously configured. Searching by the compromised access key in CloudTrail event history will help identify the activities performed. AWS STS uses temporary credentials tied to a session, not an IAM role, so revoking active sessions related to the key is the correct action.
It seems to me that the answer is:
In the CloudTrail console, under CloudTrail event history, search by access key for the compromised key, view the correlated events, and identify which IAM role the key belongs to. In the IAM console, revoke all active sessions for that IAM role.