SOA-C02 Monitoring, Logging, and Remediation Practice Question

A company has a centralized logging solution where CloudTrail logs from multiple accounts are delivered to a single S3 bucket. The security team needs to be alerted when an IAM user is created in any of the accounts. Which steps should be taken? (Choose THREE.)

⚠ Common exam trap

Watch out — candidates often confuse AWS Config rules (which assess resource compliance) with CloudWatch metric filters (which monitor log events), leading them to select Config for event detection instead of the correct CloudWatch-based approach.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a CloudWatch Logs metric filter for 'CreateUser' event.

A CloudWatch Logs metric filter can parse CloudTrail logs delivered to CloudWatch Logs and match the 'CreateUser' event pattern. This filter creates a metric that can be used to trigger an alarm. Option B is correct because CloudTrail must be configured to deliver logs to CloudWatch Logs in each account so that the metric filter can be applied to the log group. Option E is correct because a CloudWatch alarm on the metric filter can publish to an SNS topic, which sends notifications (e.g., email, SMS) to the security team when an IAM user is created.

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 Logs metric filter for 'CreateUser' event.
Why this is correct
CloudWatch Logs metric filters scan incoming log events for a specific pattern—here, the 'CreateUser' API call as recorded by CloudTrail—and increment a custom metric for each match. This is the core detection mechanism because it parses the log content in real time as logs are delivered, rather than reacting to file-level events. The metric filter must be defined on the log group where CloudTrail delivers its logs, and it translates the occurrence of the API call into a numeric value that an alarm can evaluate.
✓
Configure CloudTrail to deliver logs to CloudWatch Logs.
Why this is correct
CloudTrail must be configured with a trail that has 'Send to CloudWatch Logs' enabled, which streams JSON log records to a log group in near real time. Without this integration, the log files sit only in S3, and CloudWatch Logs has no access to parse them for metric filters or alarms. This configuration is a prerequisite for the metric filter to see the CreateUser events, as CloudWatch Logs can only evaluate data that actually arrives in its log streams.
✗
Create an AWS Config rule to detect IAM user creation.
Why it's wrong here
AWS Config is designed to track configuration changes to resources, such as when an IAM user is created, but it operates by periodically recording the state of resources and evaluating rules against those recorded configurations—this is not real-time and does not consume CloudTrail API logs. A Config rule might eventually flag the new user, but it cannot trigger an immediate response to the API call itself, and it lacks the granular, event-driven nature of a CloudWatch Logs metric filter and alarm. Moreover, Config focuses on compliance and resource configuration drift, not on reacting to single API events with low latency.
✗
Configure S3 event notification on the central bucket to trigger a Lambda function.
Why it's wrong here
S3 event notifications trigger on object-level operations, such as an object being created or deleted, rather than parsing the content *within* an object. While a CloudTrail log file arriving in S3 *is* an object creation, this mechanism would alert on *any* new log file, not specifically when an IAM user creation event is recorded inside it. This option is tempting because S3 event notifications are ideal for initiating workflows, such as data processing or indexing, immediately upon new object arrival in a bucket.
✓
Create a CloudWatch alarm on the metric filter that publishes to an SNS topic.
Why this is correct
Once the metric filter defines the 'CreateUser' event as a metric, a CloudWatch alarm can watch that metric and transition to ALARM state when the count exceeds a threshold (e.g., >0 in 1 minute). The alarm then publishes a message to an SNS topic, which can email, SMS, or trigger a Lambda function for immediate remediation. This completes the detection pipeline, turning a parsed log event into a proactive alert—something that the raw filter alone would not provide.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question