After a credential-stuffing alert, a retailer sees failed logins in its ecommerce app logs, suspicious AssumeRole calls in CloudTrail, and anomalous egress in VPC Flow Logs across three accounts. Analysts need one timeline correlating application events with AWS API and network telemetry for the same identities and IPs. Which log search and correlation approach builds that unified timeline?

Centralizing logs in Amazon Security Lake and querying them with Athena is correct because Security Lake can ingest CloudTrail, VPC Flow Logs, and custom ecommerce application logs as normalized OCSF data in a single S3-backed lake. Athena can query those sources together, letting you build a timeline that joins timestamps by principal identity and source IP across three accounts. CloudTrail Lake does not provide the needed coverage: it stores CloudTrail and similar audit events, but not VPC Flow Logs or general application logs, so it cannot join failed logins to AssumeRole calls and network egress; it is also closed to new customers. Centralizing GuardDuty findings in Security Hub supports correlated detections, severity scoring, and prioritization, but findings are not the raw event-level evidence needed to establish the same identity and IP across application, API, and network activity. Centralized CloudWatch Logs Insights can search ecommerce application logs across accounts, but does not bring CloudTrail management events and VPC telemetry into the same join. For exams, distinguish centralized raw-log analytics with a normalized schema and SQL joins from findings management, which helps triage but does not replace forensic timeline reconstruction. As a practical check, verify that the lake contains all three sources with mapped identity and IP fields, then run an Athena query to return matching login failures, AssumeRole events, and flow records ordered by time for the suspect principals and addresses.