A security team is building an Amazon EventBridge-based alerting solution to detect new Amazon S3 objects with public access and any S3 bucket policy or setting changes that make data public. EventBridge listens for specific AWS CloudTrail API events and immediately sends details to the team via Amazon Simple Notification Service (Amazon SNS). The team configured EventBridge to match s3:PutObjectAcl, s3:DeleteBucketPolicy, and s3:PutBucketPolicy events. In testing (with CloudTrail management events enabled in the same Region and a verified event pattern), EventBridge triggers for s3:DeleteBucketPolicy and s3:PutBucketPolicy but not for s3:PutObjectAcl. The team must ensure s3:PutObjectAcl generates an EventBridge event without causing false notifications. What should they do?

The correct option is to enable CloudTrail data event logging for S3 object read and write operations. s3:PutObjectAcl is a data event, not a management event. CloudTrail, by default, logs management events. To capture API calls that involve S3 objects themselves, such as PutObjectAcl, GetObject, or PutObject, you must explicitly enable data event logging for S3 buckets. Once enabled, these events will be delivered to CloudTrail and subsequently to EventBridge if configured with the appropriate event pattern. Updating the EventBridge rule to use the Amazon S3 event source and selecting "All Events" or "Bucket Level Operations" as the event type is incorrect because EventBridge still relies on CloudTrail for these specific API calls. CloudTrail Insights detects unusual API activity, but it doesn't log the underlying data events necessary for this specific alert.