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.

• ✗

  AWS Identity and Access Management (IAM)

  Why it's wrong here

  AWS Identity and Access Management (IAM) is the service that governs authentication and authorization by managing users, groups, roles, and policies. It does not natively process or interpret API activity logs, nor does it provide CloudWatch alarm integration for real-time event detection. While the IAM Credential Report can show the last use of the root user, it is a manual, point-in-time report and cannot proactively alert you the moment root credentials are used. Therefore, IAM alone is too passive and lacks the event-driven monitoring required to meet this alerting requirement.

• ✗

  Amazon CloudWatch Metrics

  Why it's wrong here

  Amazon CloudWatch Metrics stores numeric time-series data points (for example, CPU utilization or RequestCount) and can trigger alarms based on threshold breaches on those metrics. It cannot parse or interrogate CloudTrail log files, because CloudTrail events are delivered as structured JSON logs to CloudWatch Logs, not as metric data points. Even if you created a custom metric from a log filter, CloudWatch Metrics itself provides no native mechanism to scan for a specific API call like 'ConsoleLogin' and then alarm on that event. Thus, CloudWatch Metrics alone is structurally incapable of detecting root sign-in activity without CloudWatch Logs and a metric filter in the middle.

• ✗

  AWS Config

  Why it's wrong here

  AWS Config is designed to record and evaluate configurations of AWS resources—such as EC2 instances, security groups, and S3 buckets—and to assess them against managed or custom rules. It does not provide visibility into transient API actions, authentication events, or long-lived identity-driven activities like a root user signing in as the root user. A root-level 'ConsoleLogin' is an IAM authentication event that produces no corresponding resource configuration change, so AWS Config would have nothing to record or evaluate. Consequently, AWS Config is the wrong mechanism for triggering alerts on root API activity or logon events.

• ✓

  AWS CloudTrail and Amazon CloudWatch Logs

  Why this is correct

  AWS CloudTrail captures a full history of API activity and management events, including the root user's sign-in attempt, which is recorded as a 'ConsoleLogin' event with a 'userIdentity.type' of 'Root'. Sending that CloudTrail trail to Amazon CloudWatch Logs allows you to create a CloudWatch Logs metric filter that matches the JSON pattern for root-level sign-in events, and then attach a CloudWatch alarm to that metric with a threshold of one or more events. When the metric filter sees a matching root sign-in, the alarm transitions to ALARM and sends a notification to the SNS topic you configured. Together, CloudTrail supplies the detailed event data and CloudWatch Logs/alarms provide the real-time detection and alerting, making this the correct and recommended AWS solution.

Go deeper

Related to this question