CCNA Network Client Management Questions — Page 2 of 2

MCQmedium

A Linux client is unable to resolve hostnames for external domains but can ping internal hosts by IP. The /etc/resolv.conf file is correctly configured with a valid DNS server. What is the most likely cause?

A.The /etc/hosts file contains an entry that overrides the DNS resolution for external domains.

B.The nmblookup service is not running.

C.The search domain in /etc/resolv.conf is incorrect, causing the resolver to append an inappropriate domain to queries.

D.The /etc/nsswitch.conf file is missing the 'dns' service in the 'hosts' line.

AnswerC

An incorrect search domain can cause the resolver to try invalid fully qualified domain names, leading to resolution failures for external hosts.

Why this answer

Option C is correct because when a search domain is incorrectly configured in /etc/resolv.conf, the resolver appends that domain to single-label hostnames before querying the DNS server. For external fully qualified domain names (FQDNs), this can cause the resolver to send queries like 'externaldomain.com.incorrect.domain' instead of the intended domain, leading to resolution failures. Since internal IPs are reachable (bypassing DNS) and the DNS server itself is valid, the issue is most likely the resolver's domain search behavior.

Exam trap

The trap here is that candidates often assume a misconfigured /etc/resolv.conf means the DNS server is wrong or unreachable, but the question explicitly states it is correctly configured with a valid server, so the issue must be in how the resolver processes queries, specifically the search domain or ndots behavior.

How to eliminate wrong answers

Option A is wrong because /etc/hosts entries override DNS only for the specific hostnames listed; they do not block resolution of other external domains unless explicitly added. Option B is wrong because nmblookup is a NetBIOS name resolution tool for Windows networks, not relevant to standard DNS-based hostname resolution on a Linux client. Option D is wrong because if the 'hosts' line in /etc/nsswitch.conf were missing the 'dns' service, the resolver would not query DNS at all, making it impossible to resolve any external domain; the problem statement confirms external resolution fails but internal IPs work, indicating DNS is partially functional.

Practice this question →

MCQeasy

Which file on a Linux client determines the order in which different name resolution methods (e.g., hosts file, DNS, LDAP) are consulted?

A./etc/host.conf

B./etc/resolv.conf

C./etc/nsswitch.conf

D./etc/named.conf

AnswerC

This file defines the order of name resolution methods for various databases.

Why this answer

Option C is correct because /etc/nsswitch.conf (Name Service Switch) controls the order and sources for system databases like 'hosts', 'passwd', and 'group'. For hostname resolution, the 'hosts' line specifies the lookup order (e.g., 'files dns ldap'), meaning the system checks /etc/hosts first, then DNS, then LDAP. This file is the central configuration for name resolution order on Linux systems.

Exam trap

The trap here is that candidates confuse /etc/resolv.conf (which only sets DNS servers and search domains) with the file that controls the overall resolution order, leading them to pick option B instead of C.

How to eliminate wrong answers

Option A is wrong because /etc/host.conf is a legacy file used by older glibc (before nsswitch) to control resolver behavior, but it is not the primary file for ordering multiple resolution methods like DNS and LDAP. Option B is wrong because /etc/resolv.conf only configures DNS resolver parameters (nameservers, search domains) and does not define the order of resolution methods (e.g., hosts vs. DNS vs.

LDAP). Option D is wrong because /etc/named.conf is the configuration file for the BIND DNS server (named), not a client-side file that determines resolution order on the client machine.

Practice this question →

MCQhard

An LDAP client fails to authenticate users against an LDAP server. The /etc/nsswitch.conf includes 'passwd: files ldap' and the /etc/pam.d/system-auth has appropriate pam_ldap.so entries. However, 'getent passwd' shows only local users. Which command should the administrator run first to diagnose the issue?

A.View the contents of /etc/nsswitch.conf.

B.Run 'ldapsearch -x -H ldap://server -b dc=example,dc=com' to test connectivity.

C.Restart the nslcd service.

D.Check the syntax of /etc/ldap.conf with 'slaptest -f /etc/ldap.conf'.

AnswerB

Directly tests if client can bind to LDAP server.

Why this answer

Option B is correct because the first step in diagnosing an LDAP authentication failure is to verify basic connectivity to the LDAP server. Running 'ldapsearch -x -H ldap://server -b dc=example,dc=com' tests whether the client can reach the server and perform a simple anonymous search. If this fails, no amount of configuration tweaking will resolve the issue, as the root cause is likely network or server availability.

Exam trap

The trap here is that candidates often jump to restarting services or checking configuration files, but the LPIC-2 exam emphasizes a systematic troubleshooting approach where connectivity testing (ldapsearch) is the first logical step before assuming configuration or service issues.

How to eliminate wrong answers

Option A is wrong because viewing /etc/nsswitch.conf again is redundant; the question already states it includes 'passwd: files ldap', so the configuration is correct and rechecking it does not diagnose the connectivity issue. Option C is wrong because restarting nslcd would only help if the service is misconfigured or hung, but the problem is that 'getent passwd' shows only local users, indicating nslcd may not be running or cannot reach the server; however, the first diagnostic step should be a direct connectivity test, not a service restart. Option D is wrong because 'slaptest' is a tool for OpenLDAP's slapd configuration, not for the client-side /etc/ldap.conf file; checking syntax of /etc/ldap.conf is done manually or with other tools, and syntax errors are less likely than connectivity issues.

Practice this question →

MCQeasy

A user reports they cannot obtain an IP address via DHCP. The DHCP server logs show no client activity, but the network cable is connected. Which configuration is most likely missing on the DHCP server?

A.deny unknown-clients

B.default-lease-time

C.option domain-name

D.subnet declaration

AnswerD

A subnet declaration is required to define the pool of addresses.

Why this answer

The DHCP server logs show no client activity, meaning the server is not receiving DHCPDISCOVER packets from the client. The most likely missing configuration is a subnet declaration, which defines the network segment the DHCP server should listen on and allocate addresses from. Without a matching subnet declaration in the DHCP configuration (e.g., /etc/dhcp/dhcpd.conf), the server will ignore requests from that subnet, even if the physical cable is connected.

Exam trap

The trap here is that candidates often focus on client-side issues or access control (like deny unknown-clients) when the logs show no activity, but the real cause is the server not being configured to listen on the client's subnet at all.

How to eliminate wrong answers

Option A is wrong because 'deny unknown-clients' would cause the server to reject clients not in a host declaration, but the server logs would still show client activity (e.g., DHCPDISCOVER received and denied). Option B is wrong because 'default-lease-time' only affects the lease duration offered to clients; its absence does not prevent the server from receiving or responding to DHCP requests. Option C is wrong because 'option domain-name' is an optional parameter that provides a DNS domain suffix; its absence does not block DHCP communication or cause a complete lack of client activity in the logs.

Practice this question →

MCQmedium

An administrator notices that clients are unable to obtain IP addresses from the DHCP server. The server logs show 'no free leases' error. What is the most likely cause?

A.The DHCP server's subnet declaration does not match the client's network.

B.The DHCP server's address range is exhausted.

C.The dhcpd.conf file has invalid syntax.

D.The DHCP relay agent is misconfigured.

AnswerB

Directly matches the error message.

Why this answer

The 'no free leases' error indicates that the DHCP server has exhausted all available IP addresses in its configured pool. This occurs when the address range defined in the dhcpd.conf file has been fully allocated to clients and no leases are available for new requests. The server logs confirm this specific condition, making address exhaustion the most likely cause.

Exam trap

The trap here is that candidates may confuse 'no free leases' with configuration or relay issues, but the error message directly points to address pool exhaustion, not connectivity or syntax problems.

How to eliminate wrong answers

Option A is wrong because a subnet declaration mismatch would typically result in 'no subnet declaration' or 'not authoritative' errors, not 'no free leases'. Option C is wrong because invalid syntax in dhcpd.conf would cause the DHCP daemon to fail to start or report a configuration parse error, not a runtime lease exhaustion error. Option D is wrong because a misconfigured relay agent would prevent DHCP discover packets from reaching the server, resulting in no response or timeout, not a 'no free leases' error from the server.

Practice this question →

MCQhard

An administrator configures an NIS client by running 'ypbind' and updating /etc/nsswitch.conf to include 'nis' for passwd, shadow, and group. However, 'getent passwd' still shows only local users. Which step is most likely missing?

A.Restart the ypserv service on the client.

B.Execute 'yppasswd' to initialize NIS client.

C.Edit /etc/yp.conf to specify the NIS server's domain and address.

D.Run 'make -C /var/yp' on the client.

AnswerC

ypbind needs this to locate the server.

Why this answer

The NIS client must know which NIS server to contact for domain information. This is configured in /etc/yp.conf, which specifies the NIS domain name and the server's hostname or IP address. Without this file, ypbind cannot locate a server, so getent falls back to local sources despite nsswitch.conf listing 'nis'.

Exam trap

The trap here is that candidates assume updating nsswitch.conf alone is sufficient, overlooking the mandatory /etc/yp.conf configuration that ypbind requires to discover and bind to an NIS server.

How to eliminate wrong answers

Option A is wrong because ypserv is the NIS server daemon, not a client service; restarting it on the client is meaningless and would not configure the client to find a server. Option B is wrong because yppasswd is used to change NIS passwords, not to initialize or enable NIS client functionality. Option D is wrong because 'make -C /var/yp' rebuilds the NIS server's maps (typically run on the server), not on the client, and has no effect on client-side resolution.

Practice this question →