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.

• ✓

  Use the CloudWatch Logs agent to send /var/log/auth.log to CloudWatch Logs

  Why this is correct

  The unified CloudWatch Logs agent (or legacy logs agent) installed on the EC2 instance tails /var/log/auth.log and streams each new line to a CloudWatch Logs log group. Once the log data is in CloudWatch Logs, you can create a metric filter that matches patterns such as 'Failed password for' or 'authentication failure' and then alarm on that metric. The agent needs an IAM role with logs:PutLogEvents permissions, but no other AWS service can natively reach into the guest OS to read auth logs.

• ✗

  Enable AWS CloudTrail for EC2 instances

  Why it's wrong here

  CloudTrail records API activity made on the AWS control plane, such as RunInstances, TerminateInstances, or CreateSecurityGroup; it does not capture what happens inside an EC2 instance's operating system. A failed SSH login is an OS-level authentication event that takes place in sshd and is written to /var/log/auth.log, not an AWS API call. Even with management and data events enabled, CloudTrail never sees usernames, passwords, or SSH handshake results from within the guest OS.

• ✗

  Enable VPC Flow Logs

  Why it's wrong here

  VPC Flow Logs capture metadata about IP traffic reaching an ENI, including source/destination IP, source/destination port, protocol, and whether the packet was accepted or rejected. A failed SSH login is an application-layer authentication failure that occurs after a TCP connection on port 22 is successfully established, so Flow Logs would show only 'ACCEPT' for the connection without any indication that the login attempt failed. Flow Logs do not inspect packet payloads, so they cannot reveal auth.log content, usernames, or the outcome of the SSH authentication exchange.

• ✗

  Use AWS Config to detect SSH access

  Why it's wrong here

  AWS Config is a resource configuration tracking and compliance service that evaluates managed and custom rules against things like security group changes, instance types, or EBS encryption settings. It has no visibility into the guest OS, cannot read /var/log/auth.log, and cannot determine whether an SSH login failed or succeeded. Config records configuration changes to AWS resources and can trigger remediation, but it is not an operating-system log collection or intrusion-detection mechanism.

Go deeper

Related to this question