A logistics company runs ALB, CloudFront, WAF, Route 53, and EKS microservices across two Regions, and the SOC needs centralized request, DNS, and Kubernetes audit trails for threat hunting with 1-year retention and low operational overhead. Which log source and storage combination provides complete coverage with minimal management?
Select an answer to reveal the explanation.
Short Explanation
You've got clues scattered everywhere, so you'll want them all tucked into one detective's case file for the year. With centralized S3 ingestion, your edge, DNS, and EKS audit trails stay searchable without extra busywork.
Full Explanation
The correct combination is right because it maps each telemetry need to its native source and lands it in a single governed store with ALB and CloudFront access logs plus WAF logs covering edge and application requests, Route 53 Resolver query logs covering DNS, and EKS control-plane audit logs (enabled in EKS, delivered to CloudWatch Logs and streamed to S3 with a subscription filter and Firehose) covering Kubernetes API activity, while Organizations CloudTrail adds management-plane context, all in centralized S3 where Lifecycle easily enforces one-year retention and Lake Formation with Athena enables low-maintenance SQL threat hunting across accounts and Regions. The alternative that centralizes only ALB, CloudFront, WAF and Resolver logs with Athena fails by completeness because without EKS audit logs analysts cannot trace exec, role binding, or API abuse inside clusters despite otherwise sound storage and retention. The alternative that ingests the full set but expires data after 90 days with OpenSearch dashboards fails by retention and efficiency because hot search optimizes real-time visualization at high cost and violates the explicit one-year hunting window. The regional CloudWatch alternative fails by centralization and overhead because per-Region groups preserve data for a year but force cross-Region correlation and higher ingestion management compared to S3 aggregation. Exam caveat is to distinguish request and audit logs from findings and metrics services and confirm whether DNS means Resolver query logging versus other network context. Practical check is to verify ALB, CloudFront, WAF, Resolver, and EKS delivery all point to the central bucket with a 365-day Lifecycle policy and run a sample Athena query across Regions for a known test request.