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 Amazon CloudWatch Events to match S3 API calls from CloudTrail and route to an SQS queue.

  Why it's wrong here

  Amazon CloudWatch Events (now EventBridge) can match S3 API calls logged by CloudTrail, but CloudTrail logs are delivered on an asynchronous, batched basis—typically 5–15 minutes after the API call—so the event stream is not near-real-time. You would also need to build a rule with an event pattern and a target to SQS, which adds unnecessary infrastructure compared to the native S3 event notification. Since S3 already publishes lifecycle events (e.g., s3:ObjectCreated:*) directly to SQS within seconds, relying on CloudTrail as a proxy introduces avoidable latency and operational complexity.

• ✓

  Configure an S3 event notification on the bucket to send events to an SQS queue.

  Why this is correct

  S3 bucket event notifications natively publish a rich event envelope (bucket, object key, size, etag) to a designated SQS queue as soon as the object operation completes, making them the most direct, low-latency mechanism for this requirement. The integration is fully managed: you enable the notification in the bucket configuration, attach an SQS resource policy that allows S3 to send messages, and S3 handles retries and batching automatically. This eliminates the need for custom intermediaries or polling, and supports prefix/suffix filters so the queue only receives relevant object events.

• ✗

  Deploy an application that periodically polls S3 for changes using ListObjects.

  Why it's wrong here

  Polling for changes with ListObjects (or ListObjectsV2) requires continuously comparing snapshots of the bucket to infer what changed, but the API returns only a current listing—it does not produce an event or identify which object changed between calls. Each comparison cycle needs to store state from the previous scan, and frequent polling of large buckets generates massive request costs, throttling risk, and delayed detection. This approach is inherently non-event-driven and scales poorly compared to S3's push-based notification to SQS.

• ✗

  Use AWS CloudTrail to deliver logs to CloudWatch Logs, then create a metric filter and trigger a Lambda function to send to SQS.

  Why it's wrong here

  This pipeline uses CloudTrail logs, which are delivered to CloudWatch Logs only after a significant delay and for data events can be sparse if not explicitly enabled. A metric filter merely counts log occurrences; it does not extract the full event payload, so you would need a Lambda function to parse the JSON and reconstruct the object key—adding brittle custom code. Even after those hops, the end-to-end latency is dominated by CloudTrail and Logs ingestion, so it cannot match the sub-second to few-second delivery of a direct S3 event notification to SQS.

Go deeper

Related to this question