After a credential leak, a media firm sees suspicious AssumeRole and S3 data access across CloudTrail, GuardDuty, and app logs in CloudWatch, and analysts must link the IAM principal to API calls and WAF blocks in one timeline without exporting CSVs manually. Which search and correlation method builds a unified incident timeline?

The incident requires linking an IAM principal to AssumeRole calls, S3 data access, GuardDuty threat context, WAF block decisions, and application behavior in one queryable timeline, without manually handling CSVs. Amazon Security Lake supports this by collecting CloudTrail management and data events, AWS WAF logs, and Security Hub findings that carry GuardDuty findings, normalizing them to OCSF in one S3 data lake, and accepting CloudWatch application logs as a custom source. You can then use Athena to join the sources by principal, source IP, and time. Querying centralized S3 archives with Athena over CloudTrail and WAF logs can tie API calls to edge blocks, but it omits GuardDuty findings and application logs, leaving threat severity and application impact off the principal timeline. Correlating Security Hub findings with CloudWatch Logs Insights can support triage, but it lacks the CloudTrail AssumeRole chain, S3 data events, and WAF dispositions needed for complete API-level attribution. Using Logs Insights on a CloudTrail log group can show who assumed a role and accessed objects, and from which IP, but leaves GuardDuty, WAF, and application evidence on separate timelines. An exam caveat is that collecting findings through Security Hub does not itself make unrelated log sources part of one query; the sources must be brought into the lake. In practice, verify that each source is enabled with aligned retention, custom-source data is mapped to OCSF, and timestamps are normalized before finalizing the Athena query.