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 Systems Manager Automation service role with a least-privilege policy that includes ec2:ModifySecurityGroupRules and use that role in the automation.

  Why this is correct

  The correct approach is to create a dedicated Systems Manager Automation service role with a least-privilege IAM policy that grants only ec2:ModifySecurityGroupRules (ideally scoped to specific security group resource ARNs). During execution, the Automation document assumes this service role to call EC2 APIs directly via aws:executeAwsApi, so the user who triggers the run only needs ssm:StartAutomationExecution and iam:PassRole. This keeps the blast radius minimal and follows the principle of least privilege, as the service role exists solely for the automation's intended actions.

• ✗

  Create an AWS Lambda function with permissions to modify the security group and call it from the automation.

  Why it's wrong here

  This introduces unnecessary complexity and an extra trust boundary. Systems Manager Automation documents can invoke EC2 APIs directly, such as ec2:ModifySecurityGroupRules, using the Automation service role; a Lambda function is only needed for custom logic that cannot be expressed with native Automation steps. Adding Lambda requires you to manage two separate IAM roles—the Automation service role and the Lambda execution role—plus grant lambda:InvokeFunction to the Automation document. This also adds cold-start latency and expands the attack surface, contrary to the least-privilege design goal.

• ✗

  Use the IAM user's permissions that trigger the automation.

  Why it's wrong here

  When an Automation document runs, it does not use the permissions of the IAM user who starts the execution unless you explicitly set that as the execution mode. Granting the triggering IAM user ec2:ModifySecurityGroupRules means a support engineer or a monitoring service with only trigger rights is given long-term, direct API access to alter security group rules. This is a privilege escalation risk—the user may unintentionally or maliciously open ports outside the automation workflow, and they cannot be granted narrow permissions just for the automation. Instead, the user should have iam:PassRole to a dedicated service role, so the user stays read-only or low-privileged while the automation assumes only the required permissions.

• ✗

  Attach an IAM policy to the EC2 instance's instance profile that allows ec2:ModifySecurityGroupRules.

  Why it's wrong here

  Attaching an ec2:ModifySecurityGroupRules policy to an EC2 instance profile grants the instance itself—and any process running on it—the ability to alter security group rules. If the instance is compromised, the attacker can use this permission to open inbound ports, disable quarantine rules, or bypass network access controls, defeating the purpose of incident-response automation. The instance profile is meant for actions the instance's applications take (e.g., reading S3 objects, sending logs); it should never be used to grant permissions that the Automation service should run with. Furthermore, the Automation document's API calls are made under the service role, not the instance role, except for scripts that run locally on the instance, so this policy would only introduce a dangerous side path.

Go deeper

Related to this question