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.

• ✓

  Use AWS CloudTrail to log IAM changes, and create a CloudWatch Events rule that triggers an SNS notification when specific API calls are made.

  Why this is correct

  CloudTrail records all IAM management events as API calls, including high-risk actions like `PutUserPolicy` or `DeleteUser`. An EventBridge/CloudWatch Events rule can match on event source and event name, then invoke an SNS topic within seconds. This gives a near-real-time, event-driven alert without polling or manual inspection, making it the only fully purpose-built combination.

• ✗

  Use AWS Config rules to detect changes and send notifications via SNS.

  Why it's wrong here

  AWS Config is a resource-compliance service that evaluates recorded configurations against rules and can publish notifications to SNS, but it is not an API-call logging service. Its evaluations run periodically (for example, every 15 minutes or hourly) or on detected configuration changes, and delivery can lag several minutes. That delay means a policy change could go unnoticed until the next evaluation cycle, so it cannot satisfy a strict near-real-time monitoring requirement.

• ✗

  Use CloudWatch Logs to monitor IAM activity and create a metric filter to trigger an alarm.

  Why it's wrong here

  CloudWatch Logs has no native way to ingest IAM API calls; you would first need to configure CloudTrail to export trails to CloudWatch Logs and then create a metric filter to count occurrences of the specific event names. Log delivery from CloudTrail to CloudWatch Logs is asynchronous and can take up to several minutes, and metric alarms also poll on one-minute or coarser periods. The added setup and latency makes this an indirect, harder-to-maintain alternative rather than the recommended solution.

• ✗

  Use a Lambda function that periodically checks IAM policies and sends an SNS message if changes are detected.

  Why it's wrong here

  A scheduled Lambda function that snapshots and compares IAM policies is a polling mechanic rather than an event-driven one. It can miss changes that are made and reverted between invocations, leaving no record of the unauthorized attempt, and its detection delay equals the chosen cron interval. It also duplicates functionality that CloudTrail already provides, creating extra custom code and cost without improving timeliness.

Go deeper

Related to this question