SCS-C02 Threat Detection and Incident Response 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.

• ✓

  Amazon CloudWatch Events (EventBridge)

  Why this is correct

  Amazon CloudWatch Events (EventBridge) is the correct primary service because GuardDuty natively publishes findings to the EventBridge default event bus as structured events. An EventBridge rule can filter on finding fields (e.g., severity, type, account ID) and route matched findings to targets such as Lambda functions or Step Functions state machines, enabling near-real-time automated remediation without custom polling. This is the standard, serverless integration point for GuardDuty-driven responses.

• ✓

  AWS Lambda

  Why this is correct

  AWS Lambda is the compute service that executes the actual remediation actions, such as modifying a security group rule to restrict access, detaching an instance from the network, or invoking an AWS Systems Manager document. Each Lambda function receives the GuardDuty finding as an event payload, parses relevant metadata (IP, instance ID, port), and makes the necessary AWS API calls. It is serverless and scales automatically, and can be triggered directly by EventBridge or called as a step within a Step Functions workflow.

• ✓

  AWS Step Functions

  Why this is correct

  AWS Step Functions is a workflow orchestration service that coordinates multi-step remediation processes, such as isolate, snapshot, investigate, and terminate. It is appropriate when remediation requires branching logic, retries with timeouts, human approval, or integration across multiple Lambda functions and AWS services. Instead of coding a state machine in a single Lambda, Step Functions provides durable state management and visibility, making it a complementary tool to Lambda but not the service that ingests GuardDuty findings.

• ✗

  Amazon SQS

  Why it's wrong here

  Amazon SQS is a managed message queue service, but it is not a primary service in the GuardDuty automated remediation architecture. EventBridge already delivers GuardDuty findings directly to targets like Lambda or Step Functions, so inserting an SQS queue adds unnecessary latency and operational overhead. SQS could be useful for decoupling or buffering if the remediation workload requires a queue, but it is not the service that receives and filters GuardDuty findings, and using it as the core could be considered overengineering.

• ✗

  AWS Config

  Why it's wrong here

  AWS Config is a configuration compliance and auditing service that records resource configuration changes and evaluates them against rules; it is not designed to consume or act on GuardDuty security findings. While AWS Config supports automatic remediation of noncompliant resources through SSM automation, that applies to configuration drift, not to security findings like suspicious API calls or malicious IP connections. GuardDuty findings are sent to EventBridge, not to AWS Config, so Config cannot be the direct trigger for this remediation workflow.

Go deeper

Related to this question