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.

• ✓

  Use EventBridge to trigger a Lambda function in the delegated administrator account, which assumes an IAM role in the affected account to isolate the instance.

  Why this is correct

  This is the AWS-recommended architecture for automated, cross-account GuardDuty response. GuardDuty publishes findings as EventBridge events, and because you are using a delegated administrator, you can centralize an EventBridge rule in that administrator account to capture findings from all member accounts. The triggered Lambda then assumes an IAM role in the specific affected member account (via the role's trust policy) to make the EC2 'isolate' API calls (e.g., stopping the instance or applying a security group) without requiring credentials stored in the Lambda. This pattern keep the response logic centralized, avoids per-account Lambda copies, and follows the secure cross-account role assumption model.

• ✗

  Configure GuardDuty to invoke a Lambda function in the affected account directly.

  Why it's wrong here

  GuardDuty does not have a native integration that directly invokes a Lambda function; it emits findings to Amazon EventBridge, and only through an EventBridge rule can a Lambda target be triggered. Even if you configured EventBridge in the affected account, you would need a Lambda function deployed in each of hundreds of accounts, plus cross-account IAM roles and per-account event bus rules, which is operationally complex and less secure. Direct invocation from GuardDuty would also violate the recommended delegated-administrator pattern for centrally managing findings, and GuardDuty itself has no 'invoke Lambda' action in its finding creation process.

• ✗

  Use EventBridge to send the finding to a Step Functions workflow that isolates the instance.

  Why it's wrong here

  A Step Functions workflow can be triggered by an EventBridge rule and can coordinate isolation, but it is unnecessarily complex for a single remediation step: Step Functions requires an AWS Lambda task to actually call the EC2 isolation API, adding state-machine definitions, IAM permissions, and execution overhead. It also does not inherently solve the cross-account problem; the workflow still needs a Lambda function or an account-assumption mechanism to operate in the affected account. Because the correct solution only needs Lambda + an assumed role, Step Functions adds latency, cost, and debugging complexity without providing any benefit for this narrowly-scoped isolation action.

• ✗

  Use AWS Systems Manager Automation to isolate the instance across accounts.

  Why it's wrong here

  Systems Manager Automation runbooks operate within a single account by default and lack native cross-account orchestration for isolating an EC2 instance across hundreds of accounts. This option is tempting because Automation is a powerful tool for remediating incidents within a single account, and it would be the correct choice if the isolation needed to occur only within the account where the GuardDuty finding originated, without requiring centralised multi-account response.

Go deeper

Related to this question