A security engineer is configuring a mechanism to send an alert when three or more failed sign-in attempts to the AWS Management Console occur during a 5-minute period. The security engineer creates a

Question

Options

• AIn CloudTrail, turn on Insights events on the trail. Configure an alarm on the insight with
• BConfigure CloudTrail to send events to Amazon CloudWatch Logs. Create a metric filter for the
• CCreate an Amazon Athena table from the CloudTrail events. Run a query for eventName
• DIn AWS Identity and Access Management Access Analyzer, create a new analyzer. Configure the

• A
  18% (7)
• B
  71% (27)
• C
  5% (2)
• D
  5% (2)

Explanation

Option B is correct because the standard AWS pattern for metric-based alerting on CloudTrail events is: CloudTrail → CloudWatch Logs → metric filter (filtering for ConsoleLogin events where errorMessage = "Failed authentication") → CloudWatch Alarm with a threshold of ≥3 over 5 minutes → SNS notification. This gives you precise, threshold-based alerting with a defined time window.

Why the distractors fail:

• A (CloudTrail Insights) detects unusual API activity patterns using statistical baselines - it's designed for anomaly detection over longer periods, not for triggering on a specific count within a fixed 5-minute window.
• C (Athena) queries are run on-demand or on a schedule against S3-stored logs; there's no real-time alerting capability, making it unsuitable for immediate breach detection.
• D (IAM Access Analyzer) analyzes resource policies for unintended external access - it has nothing to do with monitoring sign-in attempts or generating count-based alerts.

Memory tip: Think of the pipeline as a chain - CloudTrail captures, CloudWatch Logs stores, CloudWatch Metrics filters, CloudWatch Alarms trigger. All four "C"s in sequence. Whenever an exam question asks for count-based alerting within a time window on CloudTrail events, that chain is almost always the answer.

No community discussion yet for this question.