A GuardDuty finding flags an EC2 instance communicating with a known malicious IP, followed by unusual IAM calls. The responder must reconstruct the timeline, lateral movement, and affected users quickly without manually joining CloudTrail and VPC logs. Which root cause analysis method should the responder use?

Amazon Detective is correct because it automatically ingests GuardDuty findings, CloudTrail management events, and VPC Flow Logs into a unified entity model that links IP, EC2 instance, IAM principal, and API calls on an interactive timeline, which directly satisfies the need to reconstruct sequence, lateral movement, and blast radius without manual joins. Querying CloudTrail Lake for related principal activity (now closed to new customers) is a legitimate audit-trail technique for existing users, but it remains API-centric and requires additional correlation to connect network indicators to identity spread, so it cannot automatically reveal lateral movement across entities. Correlating findings in Security Hub is standard for prioritization and deduplication by severity and resource, yet aggregation is not root cause analysis because it lacks behavioral graph linkage showing how the instance, users, and roles interacted over time. Analyzing VPC Flow Logs in Athena is powerful for network forensics and connection profiling, but it provides source-destination telemetry without IAM and CloudTrail API context, so affected users and privilege use stay invisible. For exams, distinguish triage and storage analytics from entity-centric investigation when the stem emphasizes timeline plus relationships without manual joining. As a practical check, open Detective for the finding identifier, pivot on the EC2 instance profile to review linked principals and time-ordered API calls, then confirm scope before containment.