Alert on root console login via a CloudWatch Logs metric-filter alarm and an EventBridge CloudTrail rule
Short answer
CE A CloudTrail CloudWatch Logs metric-filter alarm plus an EventBridge rule on the root-login CloudTrail event, both to SNS.
Question
Key Takeaways
Root console logins are recorded as CloudTrail ConsoleLogin events with userIdentity ARN root. A CloudWatch Logs metric filter on those events plus an alarm gives a threshold-based alert, while an EventBridge rule on the same CloudTrail event gives event-driven near-real-time delivery to SNS. Both are native, low-complexity paths; the Lambda-parsing option (D) is unnecessarily complex.
CloudTrail already logs to S3; the engineer wants near-real-time email if the root user signs in to the console. Two actions achieve this: send CloudTrail logs to CloudWatch Logs and add a metric filter that counts successful root-account ConsoleLogin events, with a CloudWatch alarm notifying an SNS topic; and create an EventBridge rule that fires on the CloudTrail root-login event and targets an SNS topic directly. Both deliver near-real-time notification without custom parsing code.
Common mistake: Choosing the Lambda-in-the-middle option (D), which adds custom parsing and cost for no benefit over the direct EventBridge (E) or metric-filter (C) approaches. Or using Trusted Advisor (A)/Access Analyzer (B), which do not emit root-login events to EventBridge/SNS in this manner.
Expert Analysis
Why the Answer Is Correct
C sends CloudTrail to CloudWatch Logs and applies a metric filter that increments on successful root-account ConsoleLogin entries; a CloudWatch alarm on that metric notifies an SNS topic, providing near-real-time alerting. E creates an EventBridge rule that matches the CloudTrail root-login event and targets an SNS topic directly, also near-real-time. Together they satisfy the requirement with native services and no custom code.
Why the Other Options Are Wrong
A is wrong because Trusted Advisor does not emit root-login events to EventBridge for SNS delivery. B is wrong because IAM Access Analyzer does not generate root-login log entries to consume. D works but adds a Lambda parsing step that is more complex and costly than the direct E approach, and the community rejected it as unnecessary. The scenario already has CloudTrail, so E's reference to CloudTrail (not CloudWatch) events is correct.
Community Comment Notes
Community favored C,E (83 votes), noting D's Lambda is unnecessary complexity and that C (metric-filter alarm) and E (EventBridge CloudTrail rule) are the direct, cost-effective choices. A minority picked C,D but conceded E is cleaner.
Official Reference
- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-log-group.html
- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-events.html
These links open the official vendor documentation in a new tab.
Community Votes
83% of anonymous learners picked answer CE. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 5 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 5
-
gjurro 👍 2The correct answers are C and E - Option C is correct because using CloudTrail with CloudWatch Logs and setting up a metric filter and alarm will detect and alert for root login events effectively. - E is also correct as EventBridge can capture specific root login events through CloudTrail and trigger an SNS notification, providing near-real-time alerts. Why Other Options Are Incorrect: - A is incorrect because AWS Trusted Advisor does not provide real-time alerts specifically for root login events; it is more of a best practice and configuration monitoring tool. - B is incorrect because IAM Access Analyzer does not monitor root login events. It's primarily for access policy analysis. - D is incorrect because CloudTrail alone does not provide log notifications to SNS without additional steps like CloudWatch Logs and Lambda integration.
-
mzeynalli 👍 2NOT D!!! C & E are correct option CloudTrail to SNS with Lambda function: While this option can work, it involves more complexity than necessary (Lambda to parse and notify SNS). Options C and E are more direct and cost-effective for near-real-time notifications.
-
mikelord 👍 2I think CE should be the answer
-
fcbflo 👍 1This option has an error in its wording. Root user logins are recorded as events in CloudTrail, not as "CloudWatch API calls." The scenario states that CloudTrail is already enabled and sending logs to Amazon S3, but Option E incorrectly refers to CloudWatch API calls instead of CloudTrail events. A correct implementation would use EventBridge to monitor CloudTrail events for root logins, not CloudWatch API calls. This misalignment in terminology is why Option E is not correct, despite EventBridge being a valid service to use for such monitoring. The initial condition "A company has secured the AWS account root user for its AWS account by following AWS best practices. The company also has enabled AWS CloudTrail, which is sending its logs to Amazon S3" is relevant to all options but is correctly leveraged only in options C and D.
-
Pmktechno 👍 1C and E correct
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.