200-201 Network Intrusion Analysis Practice Question
An analyst reviews an IDS alert indicating a TCP SYN scan against a web server. The analyst wants to confirm the scan by examining packet-level evidence in the PCAP. Which TWO characteristics would confirm a SYN scan rather than legitimate client behavior? (Choose two.)
⚠ Common exam trap
The trap here is selecting the target's RST and SYN-ACK responses as evidence, when those are ordinary TCP behavior that any connection attempt would elicit.
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
✓
The source sends SYN packets with varying TCP window sizes and random source ports across the scan
A SYN scan is proven by the combination of incomplete handshakes across many destination ports and deliberate header variation. The scanner never finishes the three-way handshake, and it randomizes source ports and window sizes to evade detection. Target responses such as RST or SYN-ACK merely reflect normal TCP behavior, a completed handshake indicates legitimate client activity, and historical firewall blocks are reputation context rather than packet-level confirmation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The source sends a single SYN and then completes the handshake before sending an HTTP GET
Why it's wrong here
This is the pattern of a legitimate web client establishing a session. A completed handshake followed by an application request indicates normal browsing or API traffic, not reconnaissance. If anything, this evidence argues against a scan, because scanners deliberately avoid completing handshakes to stay stealthy and conserve resources. So it cannot confirm the SYN scan alert.
- ✗
The target's firewall logs show the source IP was previously blocked for port scanning
Why it's wrong here
A prior block is contextual reputation data, not packet-level evidence of the current scan, and it could reflect a false positive or a different host behind NAT. The question asks for characteristics observable in the PCAP that confirm the scan behavior itself. Historical blocking records do not show handshake state, port breadth, or header manipulation, so they cannot independently confirm the current alert.
- ✓
The source sends SYN packets with varying TCP window sizes and random source ports across the scan
Why this is correct
Scanning tools randomize source ports and vary window size and other header fields to evade simple signature matching and to avoid exhausting local ephemeral ports. Combined with the absence of completed handshakes, this header variation supports an automated scanner rather than a browser or API client, which would use one consistent source port per connection and a stable window size negotiated once per session.
- ✗
The destination responds with RST packets for closed ports and SYN-ACK for open ports
Why it's wrong here
This describes the target's correct, expected TCP behavior for any incoming SYN, whether from a scanner or a legitimate client. It confirms the target is reachable and standards-compliant, but it does not distinguish malicious scanning from normal connection attempts. Treating normal TCP responses as proof of scanning conflates the target's reaction with the attacker's intent, so this is not confirmatory evidence.
- ✓
A single source sends SYN packets to many sequential destination ports with no completed three-way handshakes
Why this is correct
A SYN scan's defining trait is incomplete handshakes: the scanner sends SYN and either receives SYN-ACK or RST, then immediately tears down without sending the final ACK. Legitimate clients complete the handshake before exchanging data. When one source touches many sequential ports this way, the only plausible explanation is service enumeration, because no application would repeatedly start and abandon connections across a wide port range.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-201 question from scratch — 968 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-201 practice question is part of Courseiva's free Cisco 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 200-201 exam.