SCS-C02 Threat Detection and Incident Response Practice Question
Your company has a serverless application using AWS Lambda, Amazon API Gateway, and Amazon DynamoDB. The security team enabled AWS CloudTrail and Amazon GuardDuty. GuardDuty generates a finding 'Recon:EC2/PortProbeUnprotectedPort' for an EC2 instance that does not exist in the account. Upon investigation, you realize that the finding is triggered by a misconfigured Network Load Balancer (NLB) that is exposing a port to the internet. The NLB is used by the API Gateway. You need to reduce false positives for this specific finding. What should you do?
⚠ Common exam trap
It's easy for candidates to think changing the load balancer type or adding DDoS protection will stop the probes, but GuardDuty detects the probe activity itself, not the vulnerability—so only suppression rules can prevent the false positive without disabling the service.
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
✓
Create a suppression rule in GuardDuty to filter out findings for the NLB's public IP and port.
GuardDuty suppression rules allow you to filter out findings that are known false positives based on specific criteria, such as the public IP and port of the NLB. Since the NLB is intentionally exposing a port for API Gateway, the port probe finding is expected behavior, not a real threat. Suppressing findings for that specific combination reduces noise without disabling GuardDuty for the entire account.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Change the NLB to an Application Load Balancer.
Why it's wrong here
Replacing the NLB with an Application Load Balancer does not change the root cause of the GuardDuty false positive. GuardDuty evaluates network traffic and generates findings based on the observed public IP and port regardless of which load balancer type fronts the application, and an ALB would still appear as a public endpoint with a similar finding profile. This move also introduces downtime and migration effort, yet it does nothing to suppress the existing or future findings.
- ✗
Enable AWS Shield Advanced to block the probes.
Why it's wrong here
AWS Shield Advanced is a DDoS mitigation service that only defends against volumetric and state-exhaustion attacks; it does not act as an intrusion detection or prevention system and cannot suppress GuardDuty findings. GuardDuty analyzes VPC Flow Logs, DNS logs, and CloudTrail independently of Shield, so even if Shield blocked the probe traffic, GuardDuty would still ingest historical flow data and may produce the same finding. Moreover, blocking the probes does not retract findings that have already been generated in the GuardDuty console.
- ✗
Disable GuardDuty for the account.
Why it's wrong here
Disabling GuardDuty for the account is a disproportionate and damaging remedy because it stops all threat detection on every supported resource, not just the single NLB false positive. This would eliminate future detections of compromised credentials, crypto mining, port scanning, and other malicious activity, while historical findings would remain visible for up to 90 days without automated alerts or context. It does not isolate the problem and leaves the account without a critical security monitoring layer.
- ✓
Create a suppression rule in GuardDuty to filter out findings for the NLB's public IP and port.
Why this is correct
Create a GuardDuty suppression rule that filters findings based on the NLB's public IP address and port, which automatically excludes those matching findings from the Active findings view and from CloudWatch Events delivery. Suppression rules evaluate regex-based criteria on finding fields, so you can scope the rule to exactly this endpoint while all other GuardDuty detections remain fully active and visible. This is GuardDuty's intended mechanism for whitelisting known false positives and involves no infrastructure changes, additional cost, or loss of detection coverage.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 1,205 original SCS-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.