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.

• ✗

  AWS Config rules with an SNS topic

  Why it's wrong here

  AWS Config rules operate by evaluating the configuration state of AWS resources against managed or custom rules, such as checking whether an S3 bucket is publicly accessible or an IAM role is overly permissive. They do not capture or analyze the API call stream itself, so they cannot directly detect a specific action like 'DeleteBucket' or 'PutBucketPolicy' unless a custom rule is configured to query CloudTrail logs. Merely subscribing an SNS topic to AWS Config notifications provides compliance status changes, not real-time alerts about a particular API call.

• ✗

  Amazon GuardDuty with an SNS topic

  Why it's wrong here

  Amazon GuardDuty is a threat detection service that ingests and analyzes CloudTrail management events, VPC flow logs, and DNS logs to identify suspicious behavior such as unusual geolocations, cryptomining activity, or compromised credentials. It can publish findings to an SNS topic, but its detections are based on machine learning and threat intelligence rather than exact API names or deterministic event matching. Therefore, it cannot be configured to alert when a specific API call is made by a specific IAM user or at a precise frequency; it is designed for broader anomaly detection, not precise API-level alerting.

• ✓

  CloudTrail with CloudWatch Logs, metric filter, alarm, and SNS topic

  Why this is correct

  This is the correct end-to-end solution: AWS CloudTrail records every management API call and delivers those logs to a CloudWatch Logs log group. A CloudWatch Logs metric filter is then created with a pattern that matches the specific event, for example the eventName or a user identity, and the filter publishes a metric value each time a matching event occurs. A CloudWatch alarm can then monitor that metric with a defined threshold, and when triggered, it sends a notification to an SNS topic, enabling real-time alerting for the exact API call of interest.

• ✗

  CloudTrail with Lambda function invocation

  Why it's wrong here

  CloudTrail cannot directly invoke a Lambda function when an API call is made; the CloudTrail event stream is not a native event source for Lambda. To trigger a Lambda on a CloudTrail event, you must relay the logs through CloudWatch Logs and use a subscription filter, or use an Amazon EventBridge rule that matches the API call and targets the Lambda function. The proposed option, without such a middleware layer, is incomplete and will not function, whereas the correct design uses CloudWatch Logs as the delivery and filtering engine.

Go deeper

Related to this question