Send CloudTrail management events to CloudWatch Logs, filter failed ConsoleLogin, and alarm to SNS

Why the Answer Is Correct

Console sign-in activity is recorded by CloudTrail as a management event, so the first requirement is to deliver management events to a CloudWatch Logs log group (A). A CloudWatch Logs metric filter with a pattern matching failed ConsoleLogin events then converts those log records into a metric, which is what makes the count of failures observable and alarmable (A). A CloudWatch alarm based on that metric filter fires when the number of failures crosses the configured threshold, which is what the requirement for multiple failed login attempts calls for, and an alarm action sends messages to the Amazon SNS topic the security team is already subscribed to (A). Every component is a managed service operating event-driven, so there is nothing to poll, schedule, or code, which is what the least-operational-effort requirement points to. Srikantha described this as leveraging CloudTrail for logging, CloudWatch Logs for capturing the log data, CloudWatch Alarms for monitoring, and SNS for notification, and teo2157 confirmed that CloudTrail events can be sent to CloudWatch log groups. A is the correct answer.

Why the Other Options Are Wrong

C configures CloudTrail to send data events to CloudWatch Logs and creates a metric filter matching failed ConsoleLogin events on that log group. Data events record resource-level operations such as S3 object-level access, Lambda function invocations, and DynamoDB item-level changes; console sign-ins are management events, so a log group receiving only data events would contain no ConsoleLogin records, the metric filter would match nothing, and the alarm would never fire. On9son made the complementary observation that management events are what carry the login information. B sends management events to an S3 bucket, creates an Athena query that fails if it finds failed logins, creates an EventBridge rule to run that query periodically, and creates a second rule to notify SNS when the query fails. As eugene2owl observed, this might function but is dramatically more overcomplicated, since it requires a query, a scheduled invocation, and a second rule to detect the failure, versus a metric filter and an alarm. D sends data events to S3 and configures an S3 event notification for s3:ObjectCreated filtered on ConsoleLogin failures. S3 event notifications fire on object creation and cannot filter on the contents of a log record, so the ConsoleLogin condition could never be applied. A is correct.

Community Comment Notes

Community voted A (91). Srikantha described the four-service chain and stated it provides the required notification efficiently. eugene2owl identified A as the most elegant and obvious solution and noted that B might work but seems far more overcomplicated, which is the decisive operational point. teo2157 confirmed A on the basis that CloudTrail events can be sent to CloudWatch log groups. On9son was the sole dissenter, favouring B on the grounds that CloudTrail publishes logs to S3 and that management events contain login information, which is true but does not outweigh the operational overhead of scheduled Athena queries and a second rule. No alternative received support.