SCS-C02 Threat Detection and Incident Response Practice Question

Exhibit

Refer to the exhibit.
```
{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "resources": ["arn:aws:ec2:us-east-1:123456789012:instance/i-0a1b2c3d4e5f67890"]
}
```

A security engineer creates an Amazon CloudWatch Events rule with this event pattern to trigger an AWS Lambda function for automated response to GuardDuty findings. However, the Lambda function is not triggered for new findings. What is the MOST likely cause?

⚠ Common exam trap

A common mix-up: candidates assume the issue is a missing permission (Option D) or a missing finding type (Option A), but AWS specifically designs this question to test whether you understand that CloudWatch Events pattern matching is strict and case-sensitive, and that GuardDuty findings have a predefined event structure that must be replicated exactly.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The event pattern does not match the actual structure of GuardDuty findings.

The event pattern provided in the CloudWatch Events rule must exactly match the JSON structure of a GuardDuty finding as it is published to the default event bus. GuardDuty findings are delivered with a specific schema that includes a `detail` object containing `type`, `severity`, and other fields. If the event pattern uses incorrect field names, nesting, or missing required elements (e.g., `source` must be `aws.guardduty`), CloudWatch Events will not match the incoming events, and the Lambda function will not be triggered.

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 finding type is not specified in the pattern.
Why it's wrong here
A CloudWatch Events event pattern is a filter, not a schema, so any field you omit, including `detail.type`, is treated as a wildcard. GuardDuty publishes a single event detail-type, `GuardDuty Finding`, for every detection, while the `type` field inside detail varies by finding family. Leaving out `detail.type` simply matches all finding types and does not prevent the rule from firing.
✗
CloudTrail is not enabled in the account.
Why it's wrong here
GuardDuty generates findings from its own telemetry, such as VPC Flow Logs, DNS query logs, and threat intelligence, and it publishes those findings to the default CloudWatch Events/EventBridge bus. CloudTrail records API activity for governance and is not a required dependency for GuardDuty finding generation or for CloudWatch Events to receive those findings. Whether CloudTrail is enabled has no effect on whether a GuardDuty finding event is delivered to a CloudWatch Events rule.
✓
The event pattern does not match the actual structure of GuardDuty findings.
Why this is correct
In a GuardDuty finding event, `detail.resources` is an array of resource objects, each containing properties like `arn`, `type`, `id`, and `partition`, rather than a flat JSON object. If the event pattern is written with `resources` as an object, such as `detail.resources.arn`, it will not match because CloudWatch Events compares the pattern against the actual array structure. An array field must be matched using an array pattern, for example `"resources": [{"arn": []}]`, so the Lambda is never invoked when the pattern has the wrong shape.
✗
The Lambda function does not have permission to be invoked by CloudWatch Events.
Why it's wrong here
A missing Lambda invocation permission would matter only after the event pattern has matched, because EventBridge must successfully resolve the rule and then invoke the target with the appropriate resource-based policy. If the pattern does not match the GuardDuty event, the rule never attempts to invoke the Lambda in the first place, so no permission error is observed. A permission problem would instead surface as an invocation failure in CloudWatch rule metrics, not as a complete absence of triggers while GuardDuty events are being published.

Quick reference

Cloud Service Model Comparison

Model	You Manage	Provider Manages	Examples
IaaS	OS, runtime, apps, data	Hardware, hypervisor, networking	EC2, Azure VMs, GCP Compute Engine
PaaS	Apps and data	OS, runtime, middleware, hardware	Elastic Beanstalk, Azure App Service
SaaS	Data and settings only	Everything else	Microsoft 365, Salesforce, Workday
FaaS / Serverless	Function code only	Infra, scaling, runtime	Lambda, Azure Functions, Cloud Run
CaaS	Containers and apps	Kubernetes, OS, hardware	EKS, AKS, GKE

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Cloud Service Model Comparison

Related to this question