How to Detect EKS Audit Log and Runtime Risks with Email Alerts?

Answer Correct answer: C — Enable GuardDuty EKS Protection for audit logs and Runtime Monitoring for OS, network, and file events, then route findings to SNS email via EventBridge.

A company runs several applications on Amazon Elastic Kubernetes Service (Amazon EKS). The company needs a solution to detect any Kubernetes security risks by monitoring Amazon EKS audit logs in addition to operating system, networking, and file events. The solution must send email alerts for any identified risks to a mailing list that is associated with a security team. Which solution will meet these requirements?

  1. Deploy AWS Security Hub and enable security standards that contain EKS controls. Create an Amazon Simple Notification Service (Amazon SNS) topic and set the security team's mailiing list as a subscriber. Use an Amazon EventBridge rule to send relevant Security Hub events to the SNS topic.
  2. Enable Amazon Inspector container image scanning. Configure Amazon Detective to analyze EKS security logs. Create Amazon CloudWatch log groups for EKS audit logs. Use an AWS Lambda function to process the logs and to send email alerts to the security team.
  3. Enable Amazon GuardDuty Enable EKS Protection and Runtime Monitoring for Amazon EKS in GuardDuty. Create an Amazon Simple Notification Service (Amazon SNS) topic and set the security team's mailing list as a subscriber. Use an Amazon EventBridge rule to send relevant GuardDuty events to the SNS topic. Correct Answer
  4. Install the AWS Systems Manager Agent (SSM Agent) on all EKS nodes. Configure Amazon CloudWatch Logs lo collect EKS audit logs. Create an Amazon Simple Notification Service (Amazon SNS) topic and set the security team's mailing list as a subscriber. Configure a CloudWatch alarm to publish a message to the SNS topic when now audit logs are generated.

Community Insight

The question tests mapping EKS audit logs to GuardDuty EKS Protection and OS, network, and file events to Runtime Monitoring, and the trap is assuming one detection feature covers both telemetry sets.

The question tests GuardDuty EKS Protection and Runtime Monitoring for detecting Kubernetes risks from EKS audit logs plus OS, network, and file events, with email alerts to a security mailing list. This page confirms C and explains the EventBridge-to-SNS alerting pattern.

The most common wrong pick is A: Security Hub EKS controls and EventBridge-to-SNS look plausible, but they assess configuration compliance rather than monitor EKS audit logs or runtime OS, network, and file activity.

Community Discussion (2 comments)

7f6aef3 👍 1 Selected: C
Detecta riesgos de Kubernetes vía EKS Protection (audit logs) y eventos de SO/red/archivos vía Runtime Monitoring. Envía las alertas por email mediante EventBridge → SNS → mailing list.
bigdata2ml 👍 1 Selected: C
EKS Runtime Monitoring provides runtime threat detection coverage for Amazon Elastic Kubernetes Service (Amazon EKS) nodes and containers within your AWS environment. EKS Runtime Monitoring uses a GuardDuty security agent that adds runtime visibility into individual EKS workloads, for example, file access, process execution, and network connections. The GuardDuty security agent helps GuardDuty identify specific containers within your EKS clusters that are potentially compromised. It can also detect attempts to escalate privileges from an individual container to the underlying EC2 host, and the broader AWS environment.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

GuardDuty EKS Protection is designed to analyze Amazon EKS audit logs and surface Kubernetes-specific security risks, including suspicious control-plane activity. GuardDuty EKS Runtime Monitoring adds workload-level visibility by using a security agent to observe file access, process execution, and network connections on EKS nodes and containers. The question explicitly requires audit logs in addition to OS, networking, and file events, so both GuardDuty capabilities are needed. EventBridge can route GuardDuty findings to an SNS topic whose subscription is the security team's mailing list, satisfying the email alert requirement without custom Lambda processing.

Why the Other Options Are Wrong

A is tempting because Security Hub has EKS controls and EventBridge can send events to SNS, but Security Hub standards evaluate configuration posture and do not analyze EKS audit logs or runtime file, process, and network activity. B combines Inspector image scanning with Detective investigation and a custom Lambda path, which does not provide the required GuardDuty-style EKS audit log and runtime threat detection. D installs the SSM Agent and alarms only when no audit logs are generated, so it neither analyzes Kubernetes risks nor detects OS, network, and file events. None of these alternatives match the two GuardDuty detection layers that the scenario requires.

Community Comment Notes

As 7f6aef3 noted, the answer detects Kubernetes risks through "EKS Protection (audit logs)" and OS, network, and file events through Runtime Monitoring, then sends email via "EventBridge → SNS → mailing list." bigdata2ml added that Runtime Monitoring provides runtime visibility into EKS workloads, including "file access, process execution, and network connections." These comments align with the GuardDuty feature split that makes C the correct choice.

Official Reference

Exam Strategy

Look for the requirement pair: EKS audit logs plus OS, network, and file events. That pairing points to GuardDuty EKS Protection plus Runtime Monitoring, and the email requirement is satisfied by EventBridge routing GuardDuty findings to an SNS topic.

Frequently Asked Questions

Why does GuardDuty EKS Protection need Runtime Monitoring as well?

EKS Protection analyzes Kubernetes audit logs for control-plane risks, while Runtime Monitoring observes container and node activity such as file access, process execution, and network connections.

Why can't Security Hub EKS controls replace GuardDuty here?

Security Hub standards check configuration posture against EKS controls; they do not analyze EKS audit logs or generate runtime findings for OS, network, and file events.

More SCS-C03 FAQ →

Related Analysis

Practice All SCS-C03 Questions

Access 86 questions with complete answers and detailed explanations.

View Full SCS-C03 Practice Test →

← Back to SCS-C03 Study Guide