SCS-C02 Security Logging and Monitoring 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.

• ✗

  Configure Amazon GuardDuty to monitor for trail modifications

  Why it's wrong here

  Amazon GuardDuty consumes CloudTrail management and S3 data events to detect threats like credential exfiltration or malicious API activity, but it does not inspect or alert on the configuration state of the CloudTrail service itself. An attacker who disables a trail via StopLogging would not generate a GuardDuty finding, because GuardDuty treats CloudTrail's own control-plane calls as data rather than as a signal to act on. Consequently, this approach leaves the trail modification unnoticed.

• ✗

  Enable CloudTrail Insights to detect unusual activity

  Why it's wrong here

  CloudTrail Insights uses machine learning to detect anomalous write API activity by establishing baseline patterns of your account's normal behavior, not to react to administrative configuration changes. A single StopLogging or UpdateTrail call is an expected, low-volume management event that would not be flagged as an anomaly, and Insights must be enabled on the trail itself, so if the trail is stopped, insight monitoring also stops. Thus, it fails to provide the immediate, deterministic alert required for trail integrity.

• ✓

  Create a CloudWatch Events rule that matches the StopLogging or UpdateTrail API calls and sends an alert

  Why this is correct

  The correct solution is a CloudWatch Events rule (now Amazon EventBridge) that matches the management events CloudTrail emits for the StopLogging, UpdateTrail, or DeleteTrail API calls, using an event pattern with source 'aws.cloudtrail' and eventName in the list. When such a call occurs, the rule triggers an SNS topic or Lambda function to notify security teams in near real-time. This works because CloudTrail delivers every management event to CloudWatch Events as a default integration, including the very call that disables logging.

• ✗

  Enable S3 event notifications on the trail's S3 bucket

  Why it's wrong here

  S3 event notifications on the trail's bucket are configured for s3:ObjectCreated and similar object-level events, so they only fire when new log files are delivered, not when a trail's configuration is altered. If an attacker calls StopLogging or UpdateTrail, no new object lands in the bucket, so no notification is sent; moreover, such calls are control-plane operations outside S3's data path. This approach also generates substantial noise from normal log delivery and can be bypassed simply by redirecting the trail to another bucket.

Go deeper

Related to this question