200-901 Network Fundamentals Practice Question
A developer's application opens a TCP connection to a REST API, sends a request, and receives a response. The developer then wants to reuse the same connection for several subsequent requests to the same host instead of opening a new socket each time. Which HTTP behavior makes this reuse possible?
⚠ Common exam trap
Many candidates confuse application-layer session state, such as cookies, with transport-layer connection reuse, when only persistent connections keep the TCP socket open across requests.
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
✓
Persistent connections keep the TCP socket open for multiple request/response exchanges.
Persistent connections, the default in HTTP/1.1, let a client send multiple requests over one TCP socket. This avoids re-establishing the connection and re-entering TCP slow start for every call, which is the reuse the developer wants. Cookies, protocol upgrades, and HTTP/1.0 behavior do not provide this transport-level efficiency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Persistent connections keep the TCP socket open for multiple request/response exchanges.
Why this is correct
HTTP keep-alive, the default in HTTP/1.1, allows a single TCP connection to carry multiple sequential request/response pairs. Reusing the established socket avoids repeating the three-way handshake and TCP slow start for each call, which lowers latency and resource consumption when a client makes several requests to the same server.
- ✗
The server sends a 101 Switching Protocols response to upgrade the socket.
Why it's wrong here
A 101 response confirms an upgrade such as WebSocket or HTTP/2 over cleartext, changing the protocol on the connection. It is not what enables ordinary request reuse on HTTP/1.1. Persistent connections are the default there and require no upgrade handshake, so this status code is unrelated to the described behavior.
- ✗
The client multiplexes requests by interleaving them in a single HTTP/1.0 stream.
Why it's wrong here
HTTP/1.0 defaults to closing the connection after each response unless keep-alive is explicitly negotiated, and HTTP/1.0 has no stream multiplexing. Interleaving independent requests within one stream is a feature of HTTP/2, not HTTP/1.0, so this description does not match the version or the mechanism involved.
- ✗
HTTP cookies are exchanged so the server can correlate successive sockets.
Why it's wrong here
Cookies carry application-level session state and travel inside HTTP headers; they do not merge separate TCP connections into one. Even with cookies, each new socket still requires its own handshake. Cookies solve session identity, not transport reuse, so they are not the mechanism that lets one connection serve multiple requests.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 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-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.