SCS-C02 Threat Detection and Incident Response Practice Question

A security engineer discovers an Amazon GuardDuty finding of type 'UnauthorizedAccess:EC2/SSHBruteForce' for an EC2 instance. The instance is part of an Auto Scaling group and has a public IP address. What is the MOST effective immediate step to mitigate the threat?

⚠ Common exam trap

Candidates often assume terminating the instance directly (Option B) is sufficient, failing to recognize that Auto Scaling groups automatically replace terminated instances, which can immediately re-expose the environment to the same threat.

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

✓

Detach the instance from the Auto Scaling group and terminate it.

The instance is compromised and part of an Auto Scaling group. Detaching it first prevents the Auto Scaling group from immediately replacing it with a new instance that might inherit the same vulnerability, allowing for forensic analysis. Terminating it after detachment stops the SSH brute force attack at its source without risking automatic re-provisioning of a similarly exposed instance.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Modify the network ACL to block SSH traffic from the attacker's IP.
Why it's wrong here
Modifying the subnet's network ACL to block the attacker's IP is an incomplete response: NACLs are stateless, so you must explicitly deny both inbound SSH and outbound return traffic, and the ACL only filters at the subnet boundary—it does not stop an already-established session or remediate the EC2 instance itself. GuardDuty's finding often indicates the instance may be compromised, and leaving it powered on risks data exfiltration or lateral movement even after the specific bad IP is blocked, since the attacker can simply rotate IPs.
✗
Terminate the instance without detaching it from the Auto Scaling group.
Why it's wrong here
Simply terminating the instance without detaching it from the Auto Scaling group causes the group's desired capacity to trigger an immediate replacement launch. This replacement is built from the same launch template or AMI, so it will likely retain the same SSH exposure or vulnerability that drew the brute-force attack in the first place; you also lose the forensic evidence that GuardDuty pointed to, without actually addressing the root cause.
✗
Update the security group to restrict SSH access to known IP addresses.
Why it's wrong here
While restricting SSH to known IPs in the security group is a sensible hardening step for the future, it will not interrupt an in-flight brute-force or an already-established attacker session because security group rule changes do not terminate existing connections. The compromised instance stays powered on, and GuardDuty findings such as this usually signal that the instance can no longer be trusted; the correct response must isolate and inspect, not just tighten access.
✓
Detach the instance from the Auto Scaling group and terminate it.
Why this is correct
Detaching the instance from the Auto Scaling group before termination marks it as a manual removal from the group's lifecycle, so the scaling policy does not immediately spin up a replacement. After detaching, you can terminate it to stop the attack or preserve it for forensic analysis, while maintaining the group's desired capacity if you intentionally adjust it. This is the correct immediate response because it eliminates the compromised resource and prevents the same vulnerable workload from being automatically reintroduced.

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question