Remote staff at a SaaS company complete the TCP handshake to a file service, yet the transfers stall and collapse. Which test matches that symptom?
Select an answer to reveal the explanation.
Short Explanation
The door opens, and then the hallway is too narrow for you to walk through. A completed TCP handshake shows the session started, so you measure throughput and loss with a network test on that path. A name check, a call score, or a status-page load does not describe a transfer that stalls after connect.
Full Explanation
Remote staff complete the TCP handshake to the file service and then see transfers stall, so the matching test is a network test aimed at throughput and loss on that path. Connection setup and data transfer stress different conditions, and a handshake can succeed while loss or a constrained path collapses the transfer. A DNS test that checks the name of the file service looks for a resolution fault, and the report already shows sessions that start. A voice test scores call setup and media quality for a call, and the failing service is a file transfer. A web transaction that loads the company status page times an unrelated page and does not measure throughput toward the file service. The exam trap is treating a successful handshake as proof the path can carry the transfer. In production, compare handshake success with a network test that reports loss and throughput toward the same file service, and confirm the stall shows up in those path metrics. Keep the DNS, voice, and status-page tests for a bad name, a failed call, or a page that is itself the complaint.