How to Fix Incorrect /etc/hosts Entry Blocking Website Access
A Linux administrator is troubleshooting an issue in which users are not able to access https://portal.comptia.org from a specific workstation. The administrator runs a few commands and receives the following output: # cat /etc/hosts 10.10.10.55 portal.comptia.org # host portal.comptia.org portal.comptia.org has address 192.168.1.55 #cat /etc/resolv.conf nameserver 10.10.10.5 Which of the following tasks should the administrator perform to resolve this issue?
Community Votes
67% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests understanding of the Linux name-resolution order (hosts file before DNS) and the trap of assuming DNS cache or routing is the root cause.
When a local /etc/hosts entry maps a domain to the wrong IP, it overrides DNS resolution and prevents users from reaching the correct site. Removing the stale or incorrect hosts entry restores proper DNS-based resolution.
Many candidates choose D (clear DNS cache) because they focus on the host command output, forgetting that /etc/hosts is consulted before any DNS query or cache.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The/etc/hosts file is consulted before DNS by default on Linux systems (glibc nsswitch.conf order files dns). The entry 10.10.10.55 portal.comptia.org forces the workstation to use the wrong IP, so HTTPS to the real portal fails. Removing that line lets the resolver fall through to the DNS server, which correctly returns 192.168.1.55. As community member [3] notes, the conflict between the hosts file and DNS is the exact cause of the outage.Why the Other Options Are Wrong
Option A (change nameserver) is irrelevant because the hosts file overrides DNS regardless of which nameserver is configured. Option C (add a route) is a distractor; routing is not the issue since the wrong IP is being selected before any packet leaves the host. Option D (clear DNS cache) is tempting but ineffective — thehost command already bypasses the cache and still shows the correct DNS answer, proving the problem is the local hosts override, as commenter [2] implicitly acknowledges.Community Comment Notes
Commenter [1] correctly states the resolution order: "your system checks host file first then pings the dns." Commenter [4] reinforces that removing the conflicting entry lets the workstation rely on DNS. Commenter [2] raises a valid point about thehost output differing from the hosts file, but ultimately the fix is still to remove the overriding hosts entry so DNS can take over. Official Reference
Exam Strategy
Whenever a Linux troubleshooting question shows both /etc/hosts and DNS output, first check the name-resolution order. If the hosts file contains an entry for the target domain, assume it is overriding DNS and look for the option that removes or corrects that entry.
hostcommand, is different, portal.comptia.org -> 192.168.1.55. Something is taking priority over the local DNS in /etc/hosts. If we delete the entry in /etc/hosts, I doubt it will resolve our connection problem, because the system is getting its DNS resolution from something else, possibly a cache. I think we should flush the local DNS cache and try again. We should also verify what is the correct IP it should resolve to. Perhaps we SHOULD also remove the entry from /etc/hosts, but for the reason that the private DNS server (at 10.10.10.5) should be responsible for resolving DNS, not workstations.