# 1. Detect/scope via the audit trail:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=the-key

# GuardDuty findings often flag it first (unusual API calls, crypto-mining, recon)

# 2. Contain — revoke the credential / isolate the instance:

aws iam delete-access-key / update-access-key --status Inactive # kill the key

# attach a deny-all SG, isolate the instance (don\'t terminate -> preserve evidence)

# 3. Eradicate + recover: rotate ALL secrets, rebuild from clean AMI/IaC

Run the IR loop with AWS tooling. Detect/scope: GuardDuty usually surfaces it (anomalous API calls, mining, credential use from a new geo); CloudTrail is the authoritative audit log to trace exactly what the compromised principal did and when. Contain without destroying evidence: disable/delete the exposed access keys or detach the role policy, and for a compromised instance attach an isolation security group (deny all) and snapshot it for forensics — don\'t terminate (you\'d lose volatile evidence). Eradicate/recover: rotate all potentially exposed secrets, revoke active STS sessions, rebuild the instance from a known-good AMI/IaC (don\'t \'clean\' it), and remove any persistence the attacker added (new IAM users/keys, backdoor roles). Then close the entry vector (the leaked key, the SSRF, the public bucket) and post-mortem.

Interview tip: Map the IR phases to AWS services: GuardDuty (detect) + CloudTrail (scope — what did they do) -> contain (disable keys, isolate instance, snapshot before terminating to preserve evidence, revoke STS sessions) -> eradicate/recover (rotate all secrets, rebuild from clean AMI, hunt for attacker-created IAM persistence) -> close the vector + postmortem. The senior details: revoke active sessions (not just keys), preserve forensic evidence, and rebuild rather than clean. Tie a leaked key back to the IMDSv2/SSRF lesson.