Option C is the best fit because Amazon GuardDuty provides managed threat detection forEKSby analyzingEKS control plane audit logs(EKS Protection) and correlating those signals withruntime telemetry(Runtime Monitoring) that includesprocess/OS activity, network connections, and file activityon the worker nodes. This directly matches the requirement to monitor EKS audit logsin addition tooperating system, networking, and file events to detect Kubernetes security risks.

GuardDuty produces securityfindingsfor suspicious Kubernetes behavior and runtime indicators (for example, unexpected API calls, anomalous container activity, or known malicious behaviors). To notify the security team, anAmazon EventBridgerule can match GuardDuty findings and forward them to anSNS topic. SNS supportsemail subscriptions, so the team’s mailing list can receive near-real-time alerts without building a custom log parsing pipeline.

Option A (Security Hub) aggregates findings and maps to controls/standards but does not itself provide the combined audit-log + runtime event detection described. Option B combines unrelated services and still requires custom processing. Option D only alarms on “new audit logs generated,” which does not detect “security risks” and does not include OS/network/file threat detections.