200-901 Network Fundamentals Practice Question
A developer runs a Python script that calls a REST API on a remote server. The script hangs indefinitely with no response. The developer opens a terminal and runs `curl -v https://api.example.com/status`. The output shows that the TCP three-way handshake completes, but the TLS handshake never starts. Which of the following is the most likely cause?
⚠ Common exam trap
The trap here is assuming that a successful TCP handshake guarantees the application-layer protocol will proceed, when an inline device can intercept and terminate the connection after TCP establishment.
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
✓
A network device is intercepting the connection and terminating it before TLS negotiation.
The key symptom is that the TCP three-way handshake succeeds but the TLS handshake never initiates. This indicates that something between the client and server is completing the TCP connection and then preventing the TLS negotiation from starting. A transparent proxy or firewall that terminates TCP connections without forwarding them can cause this exact behavior. The other options either contradict the observed TCP success or describe failures that would occur after TLS begins.
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 server is not listening on port 443, so the TCP handshake should have failed.
Why it's wrong here
If the server were not listening on port 443, the TCP three-way handshake would not complete. The scenario explicitly states the TCP handshake completes successfully, which means a process is accepting connections on that port. The issue is therefore at a higher layer, not at the TCP connection establishment phase.
- ✓
A network device is intercepting the connection and terminating it before TLS negotiation.
Why this is correct
When the TCP handshake completes but the TLS handshake never begins, an inline device such as a firewall, proxy, or intrusion prevention system may be accepting the TCP connection on behalf of the server and then dropping or resetting it before TLS negotiation. This behavior is typical of a device performing TCP proxy or deep packet inspection without proper TLS passthrough.
- ✗
A firewall is blocking outbound TCP port 80.
Why it's wrong here
Port 80 is used for plain HTTP, not HTTPS. The scenario shows the TCP handshake completing on the target port, so a block on port 80 would not explain the failure. Additionally, the API endpoint is HTTPS, meaning the connection is being attempted on port 443. This distractor tests confusion between HTTP and HTTPS default ports.
- ✗
The client is using an outdated version of TLS that the server does not support.
Why it's wrong here
A TLS version mismatch would still produce a TLS handshake attempt, typically resulting in a TLS alert message such as protocol_version. The scenario states the TLS handshake never starts, meaning no ClientHello is sent or received. This points to a lower-layer interception rather than a TLS protocol negotiation failure.
Visual reference
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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-901 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-901 exam.