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.

• ✓

  The CloudWatch Events rule's event pattern does not match the GuardDuty finding event structure.

  Why this is correct

  GuardDuty emits findings to CloudWatch Events as structured events, and the rule's pattern must exactly match their JSON schema. Specifically, the pattern must use "source": ["aws.guardduty"] and "detail-type": ["GuardDuty Finding"]; otherwise the rule is never triggered. If the pattern mismatches, the Lambda function will not be invoked, even though the finding is visible in the GuardDuty console. This is the most common cause of a silent rule failure.

• ✗

  The GuardDuty detector is in a different region than the CloudWatch Events rule.

  Why it's wrong here

  GuardDuty is a regional service, and a detector only sends its findings to the CloudWatch Events bus in the same region. If the CloudWatch Events rule is created in the same region as the detector (as the scenario implies), there is no regional mismatch. Even if the rule were in another region, cross-region delivery would require an explicit EventBridge bus setup, not something that would fail silently. Thus, a region mismatch is not the cause described.

• ✗

  The Lambda function invoked by CloudWatch Events does not have an IAM role assigned.

  Why it's wrong here

  The Lambda function's IAM execution role is required only for the function's runtime operations, such as accessing other AWS services or writing logs. CloudWatch Events uses the function's resource-based policy to invoke it, not the execution role, so the rule still triggers even if the role is missing. A missing role would cause the invocation to fail during execution, producing errors in CloudWatch Logs, but it would not prevent the event rule from firing. Therefore, this option explains function failure, not the lack of a trigger.

• ✗

  VPC Flow Logs are not enabled.

  Why it's wrong here

  VPC Flow Logs are just one of the data sources GuardDuty analyzes; it can also generate findings from CloudTrail and DNS logs without them. Enabling or disabling VPC Flow Logs does not change the event structure that GuardDuty publishes to CloudWatch Events. The event rule matches on the finding's metadata, not on the underlying network data, so it would fire regardless of Flow Logs status. Hence, this is unrelated to the Lambda function never being invoked.

Go deeper

Related to this question