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.

• ✗

  Create a Lambda function in each member account that is triggered by GuardDuty findings and modifies the security group.

  Why it's wrong here

  Deploying a Lambda function in every member account means you must replicate code, IAM roles, event sources, and error handling per account, which creates significant operational overhead and configuration drift. Any change to the isolation logic requires updating each function individually, and there is no central point of visibility to audit actions across the organization. StackSets with a cross-account role is far more scalable because the role is deployed consistently from a management account, while the automation logic remains centralized in Systems Manager.

• ✗

  Create a single IAM role in the security account that has permissions to modify security groups in all member accounts.

  Why it's wrong here

  An IAM role is an entity created in a single account, and its policies grant permissions only within that account's scope. Even if you attach a policy that lists security group ARNs from member accounts, the role cannot directly modify those resources because the member account's own IAM authorization does not recognize the security account as a trusted principal. Cross-account access requires the member account to create a separate role with a trust policy for the security account, which the automation then assumes via sts:AssumeRole.

• ✓

  Use AWS CloudFormation StackSets to deploy an IAM role in each member account with permissions to modify security groups. Then, in the security account, configure the Systems Manager Automation document to assume that role when running the isolation step.

  Why this is correct

  AWS CloudFormation StackSets deploys the same IAM role template to every member account, and the role is configured with a trust policy that allows the Systems Manager Automation execution role in the security account to assume it. The automation document uses the 'assumeRole' parameter in a step such as aws:executeScript to switch to that member account role, then runs the EC2 ModifySecurityGroup API against local resources. Because StackSets is integrated with AWS Organizations, the role is automatically provisioned when new accounts are added, centralizing governance while keeping permissions scoped per account.

• ✗

  Modify the IAM role used by Systems Manager Automation in the security account to include permissions to modify security groups in all member accounts.

  Why it's wrong here

  Modifying the automation role's IAM policy in the security account only affects permissions in the security account; AWS evaluates resource access in the account where the resource lives, so the member account denies the API call because the security account principal is not allowed there. To make this work, you would need to establish a trust relationship from each member account to the automation role and then have the role assume a target role—which is exactly the StackSets approach. Simply adding member-account resource ARNs to the policy does not create the required reverse trust.

Go deeper

Related to this question