220-1101 Question 64
Single answer80 – Hypertext Transfer Protocol (HTTP)A technician is troubleshooting a workstation that cannot open an internal company web application. The user reports that entering http://intranet.company.local in the browser returns a connection error, but the same PC can still access shared folders on the file server and can successfully ping the intranet server by name. The web server administrator confirms the site is online for other users. Which step should the technician take NEXT to most directly verify whether standard HTTP traffic is being blocked between the workstation and the server?
- A
Use Telnet or PowerShell to test a connection to intranet.company.local on port 80
- B
Run ipconfig /release and ipconfig /renew on the workstation
- C
Disable HTTPS in the browser settings so the site will fall back to HTTP
- D
Change the workstation's DNS server to 8.8.8.8 and retest the site
Show answer and explanation
Correct answer: A
Explanation
The best next step is to test direct connectivity to TCP port 80 on the target host. In this scenario, several layers have already been validated: the workstation has network access to internal resources, and DNS/name resolution appears functional because the server responds to pings by name. That narrows the issue to the web service path, including host firewall rules, network ACLs, or the HTTP service listener itself. Standard HTTP uses TCP port 80, while HTTPS uses TCP port 443. A targeted port test with Telnet, Test-NetConnection, or a similar utility is a common and practical way to verify whether HTTP traffic is reachable. This aligns with standard troubleshooting methodology: verify the specific service and port involved rather than repeating broad network steps when lower-layer connectivity has already been confirmed. References: IANA service name and port number registry identifies HTTP on TCP port 80, and Microsoft documentation for Test-NetConnection supports testing TCP port reachability as part of Windows network troubleshooting.
- A. Correct.
Correct. HTTP uses TCP port 80 by default. Since name resolution appears to work already because the server can be pinged by name, and general network connectivity exists because file shares are accessible, testing connectivity directly to port 80 is the most targeted next step. Using a tool such as Telnet or PowerShell's Test-NetConnection can confirm whether the workstation can establish a TCP session to the web server's HTTP service.
- B. Incorrect.
Incorrect. Releasing and renewing the IP configuration is a general network troubleshooting step, but the scenario already shows the workstation has working network connectivity to internal resources. This action is less direct and is unlikely to isolate whether TCP port 80 specifically is blocked.
- C. Incorrect.
Incorrect. HTTPS is a separate protocol that typically uses TCP port 443, not a browser feature that can simply be disabled to make HTTP work. The issue described is with an explicit http:// URL, so disabling HTTPS would not meaningfully test whether HTTP on port 80 is reachable.
- D. Incorrect.
Incorrect. Changing DNS to a public resolver such as 8.8.8.8 would likely make resolution of an internal hostname like intranet.company.local fail, not improve it. In addition, the workstation can already ping the server by name, so DNS is not the most likely issue.