SCS-C02 Security Logging and Monitoring Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Install the CloudWatch Logs agent on the EC2 instance to stream /var/log/secure to CloudWatch Logs. Create a metric filter for 'Failed password' and set a CloudWatch alarm.

  Why this is correct

  Streaming /var/log/secure to CloudWatch Logs via the CloudWatch Logs agent enables real-time ingestion of OS-level authentication events. A metric filter with pattern 'Failed password' converts each matching log line into a metric value, and a CloudWatch alarm evaluates the metric over a chosen period to alert on anomalous login failures. This is the standard pattern for Linux SSH login monitoring because the agent is natively supported and the filter operates on the actual log content.

• ✗

  Enable VPC Flow Logs and filter for SSH traffic to detect failed attempts.

  Why it's wrong here

  VPC Flow Logs capture metadata about IP traffic—source/destination, ports, protocol, and packet counts—but they do not inspect application payload or SSH authentication results. A filter for SSH port 22 can show connection attempts, yet it cannot distinguish a successful login from a failed password, so it fails the requirement to alert on authentication failures. Additionally, flow logs are typically sampled or aggregated, and lack the per-event granularity needed for accurate thresholding.

• ✗

  Configure the EC2 instance to write failed attempts to a file in S3 and use S3 events to trigger a Lambda function for alerting.

  Why it's wrong here

  Writing failed attempts to S3 and reacting to S3 object-created events introduces both latency and architectural overhead because the EC2 instance must first upload a log file, the bucket must register the event, and Lambda must parse the file before any alert can fire. S3 event notifications are asynchronous and batch-oriented, so they deliver seconds-to-minute delays, making them unsuitable for real-time security monitoring. Furthermore, no standard agent writes /var/log/secure to S3, so an unmaintained custom solution would be required.

• ✗

  Enable Amazon GuardDuty and create a custom threat list for failed SSH attempts.

  Why it's wrong here

  GuardDuty analyzes network traffic, DNS queries, and AWS CloudTrail events to detect threats like cryptocurrency mining or credential exfiltration; it does not read the /var/log/secure file or any instance OS logs. A custom threat list in GuardDuty is simply a list of IP addresses you want flagged, not a mechanism for counting 'Failed password' lines—it cannot correlate auth failures on your instance. GuardDuty can detect brute force via network patterns, but it lacks the application-level login data needed for precise failed-login alerts.

Go deeper

Related to this question