A multinational needs to centralize CloudTrail, VPC flow, and Route 53 logs from 60 accounts into OCSF format for Splunk analysis with 7-year retention and least operational overhead. Which log lake design should the team deploy to integrate third-party tools?
Select an answer to reveal the explanation.
Short Explanation
You're pouring messy log streams into one clean reservoir. OCSF normalization means Splunk reads everything without custom parsing headaches.
Full Explanation
The correct design uses Amazon Security Lake because it automatically aggregates CloudTrail, VPC flow logs, and Route 53 Resolver query logs across 60 accounts via Organizations from a delegated administrator, normalizes them to OCSF schema in partitioned S3 storage that supports 7-year Lifecycle retention, and provides a native HTTPS custom subscriber for Splunk that removes parser maintenance for least operational overhead while enabling third-party analytics. The centralized S3 archive with SQS ingestion to Splunk centralizes storage and enables durable retention and Splunk polling but retains native JSON without OCSF normalization, forcing Splunk-side parsing and breaking the format requirement. The Security Lake with Athena analysis satisfies multi-account aggregation, OCSF, and long-term S3 retention with serverless SQL, yet without a subscriber it provides no automated third-party feed and keeps analysis outside Splunk, breaking the integration requirement. The CloudTrail Lake aggregation is now closed to new customers and provides SQL over event data stores, but its ingestion scope is CloudTrail-style events only and it cannot natively collect VPC flow and Route 53 logs, breaking the multi-source coverage requirement. On exams, when OCSF plus Splunk plus multi-log centralization appear together, Security Lake is almost always intended over CloudTrail Lake or raw S3; practically, confirm subscriber endpoint authentication, enable all required Regions and log sources, and validate S3 Lifecycle and Lake Formation access before cutover.