SOA-C02 Monitoring, Logging, and Remediation 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.

• ✓

  Create a CloudWatch Events rule for 'AWS Console Sign-In' events and set the target to an SNS topic.

  Why this is correct

  A CloudTrail record of every console sign-in is emitted as an AWS Console Sign-In event, and CloudWatch Events (EventBridge) can match those events using a rule that filters on eventName=ConsoleLogin and userIdentity.type=Root. Setting the rule's target to an SNS topic delivers a near-real-time notification to the administrator's endpoint (email, SMS, etc.). This is the standard event-driven approach because it consumes the actual audit trail event rather than relying on periodic scans or metrics that don't exist.

• ✗

  Enable CloudTrail Insights to detect root login anomalies.

  Why it's wrong here

  CloudTrail Insights is designed to detect anomalous API activity, such as unusual patterns in write management events, not to flag a specific root user's console login. Insights establishes a baseline and generates findings for things like unusual resource deletions or access patterns, but a root sign-in is a discrete authentication event, not an anomaly in API call patterns. Additionally, Insights findings are delivered to the CloudTrail console or streamed to S3, but they are not intended as a real-time notification mechanism for a single, deterministic event like a root login.

• ✗

  Create a CloudWatch alarm on the RootAccountUsage metric.

  Why it's wrong here

  There is no CloudWatch metric named 'RootAccountUsage' — CloudWatch does not expose per-IAM-user sign-in metrics, so an alarm on that metric cannot be created. While CloudWatch has IAM-related global metrics under the AWS/GLOBAL namespace (e.g., for Access Analyzer or S3), it does not provide a root-specific login counter. To receive root login alerts, you must consume the event source (CloudTrail/CloudWatch Events) rather than a metric, because the sign-in is an event, not a numeric metric stream.

• ✗

  Use AWS Config to track IAM password policy changes.

  Why it's wrong here

  AWS Config records configuration changes to resources such as the IAM password policy and tracks compliance against rules, but it does not ingest or evaluate CloudTrail sign-in events. Monitoring the password policy would only tell the administrator if password rules changed, not whether the root user signed in. Since the requirement is specifically about root user sign-ins, AWS Config is irrelevant here; it is designed for configuration drift and compliance, not for real-time authentication event notification.

Go deeper

Related to this question