Deactivate the keys immediately → review CloudTrail → rotate → remediate is the correct sequence. Deactivating (not deleting) the keys stops any ongoing unauthorized activity immediately while preserving the key ID for CloudTrail investigation. Deleting the keys immediately would remove the key ID from your CloudTrail query. After reviewing CloudTrail for unauthorized API calls in the 2-hour window, remediate any unauthorized changes (delete unauthorized resources, revoke unauthorized roles, etc.), then create new keys.

Why A is wrong: Deleting the IAM user immediately is too aggressive. It may break dependent services using those credentials and doesn't give you time to review what was done with the compromised keys. Deactivating is safer and faster for containment while preserving investigative capability.

Why C is wrong: Changing the IAM user's password has no effect on access keys. Access keys are independent credentials that work with or without a console password. IAM users can have both console access (password) and programmatic access (access keys) independently.

Why D is wrong: MFA for console access does not disable programmatic API access using access keys. Even if MFA is required for console login, the access keys bypass this requirement entirely unless STS sessions require MFA via condition keys in policies.

Compromised credential response: (1) DEACTIVATE keys (not delete — preserve for investigation), (2) CloudTrail investigation, (3) Remediate unauthorized changes, (4) Delete old keys, (5) Issue new keys. Also use AWS Trusted Advisor and IAM Access Advisor to identify what permissions were used.