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.

• ✓

  Enable Amazon GuardDuty and review the findings.

  Why this is correct

  Amazon GuardDuty is a managed threat detection service that continuously analyzes AWS account activity from VPC Flow Logs, DNS logs, CloudTrail management events, and S3 data events. It uses threat intelligence feeds and machine learning to automatically identify reconnaissance behavior such as port scans, SSH brute-force attempts, or unusual API calls from a suspicious IP range. Enabling GuardDuty and reviewing its severity-ranked findings gives a startup immediate, operational visibility into the attack without deploying agents or writing detection queries, and the findings can be integrated with AWS Security Hub or EventBridge for automated response.

• ✗

  Install a third-party intrusion detection system on each EC2 instance.

  Why it's wrong here

  Deploying a third-party intrusion detection system on every EC2 instance is operationally heavy, expensive, and incomplete. Host-based agents must be installed, licensed, patched, and managed on each instance, and they inspect only traffic that reaches the host's network stack—they cannot see VPC-level scanning against unused IP addresses, DNS-layer threats, or CloudTrail API reconnaissance. In a single-account development environment, this approach adds significant cost and complexity while leaving the AWS control plane and network perimeter unmonitored, whereas GuardDuty provides account-wide coverage with no agents required.

• ✗

  Use Amazon CloudWatch Logs Insights to query VPC Flow Logs for rejected traffic patterns.

  Why it's wrong here

  Using CloudWatch Logs Insights to query VPC Flow Logs for rejected traffic is a manual, reactive approach that requires an analyst to know exact query syntax and which patterns constitute an attack. Flow Logs contain only IP traffic metadata, not DNS queries, CloudTrail events, or threat-intelligence context, so simply looking for rejected packets will miss reconnaissance techniques where the attacker accepts a connection and performs a banner grab or sends a low-volume, distributed scan. This method also produces no automated alerts unless you separately build metric filters and alarms, making it slow and unscalable for a development account that needs prompt detection, whereas GuardDuty automatically analyzes the same flow logs plus additional sources and generates findings.

• ✗

  Use AWS Config rules to check for security group changes.

  Why it's wrong here

  AWS Config rules are designed to evaluate resource configuration compliance, not to detect real-time network or account behavior. A Config rule could alert you when a security group is modified or when it contains an overly permissive ingress rule, but it cannot observe the actual attack traffic—for example, a host attempting to connect to many ports or a series of failed SSH logins does not change any configuration. Checking for security group changes might reveal a misconfiguration that enabled an attack, but it provides no signal about ongoing reconnaissance, which is the activity the startup is seeing. GuardDuty, by contrast, monitors the observed activity itself, making it the appropriate service for this scenario.

Go deeper

Related to this question