LPI 102-500 Practice Test 53
Question 520
During an LPIC-1 practice lab, the operator encounters this condition: An application resolves hostnames through DNS despite an intended local mapping because the hosts lookup order was changed in /etc/nsswitch.conf. Which TWO complementary steps provide the best corrective action and its most direct diagnostic verification? Select TWO answers.
- Inspect `ip -6 addr`, `ip -6 route`, router advertisements and a scoped ping6 to the link-local destination.
- Inspect and configure the appropriate `nmcli device wifi` and connection profile settings with approved authentication, secrets and autoconnect preferences.
- Review hosts lookup precedence in nsswitch.conf and maintain the correct /etc/hosts and resolver settings for each source.
- Compare `getent hosts name`, /etc/nsswitch.conf hosts line, /etc/hosts entry and DNS-only `dig` output.
- Assume editing /etc/resolv.conf always overrides a conflicting /etc/hosts entry regardless of NSS hosts order.
Explanation
Correct Answers
C:Recommended administrative action: Review hosts lookup precedence in nsswitch.conf and maintain the correct /etc/hosts and resolver settings for each source. conf. Linux principle: Name Service Switch controls whether hosts files and DNS are queried and in what order, while resolv.conf primarily identifies recursive resolver configuration.
D:Most direct verification evidence: Compare `getent hosts name`, /etc/nsswitch.conf hosts line, /etc/hosts entry and DNS-only `dig` output. conf. Linux principle: Name Service Switch controls whether hosts files and DNS are queried and in what order, while resolv.conf primarily identifies recursive resolver configuration.
Incorrect Answers
A:That option would inspect `ip -6 addr`, `ip -6 route`, router advertisements and a scoped ping6 to the link-local destination, but it addresses a different concern. Name Service Switch controls whether hosts files and DNS are queried and in what order, while resolv.conf primarily identifies recursive resolver configuration.
B:This alternative addresses NetworkManager Wi-Fi authentication and saved profiles, not the specific issue of Local hosts resolution versus DNS settings: Inspect and configure the appropriate `nmcli device wifi` and connection profile settings with approved authentication, secrets and autoconnect preferences. conf.
E:This shortcut is unsafe for the present Linux issue: Assume editing /etc/resolv.conf always overrides a conflicting /etc/hosts entry regardless of NSS hosts order. conf. Name Service Switch controls whether hosts files and DNS are queried and in what order, while resolv.conf primarily identifies recursive resolver configuration.
Question 521
A helpdesk escalation describes this Linux behavior: A host's interface comes up with unexpected settings because both NetworkManager and systemd-networkd attempt to manage the same link. Which administrative step is the MOST appropriate way to resolve this issue? Select ONE best answer.
- Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers.
- Inspect `ip route` and selected `ip route get`, then set or repair the appropriate default route in the active manager or with `ip route` for a controlled temporary change.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
- Map required common services to their correct transport and port, including SSH 22/TCP, HTTP 80/TCP, HTTPS 443/TCP and DNS 53/UDP or TCP where used.
Explanation
Correct Answer
A:Recommended administrative action: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers.
Incorrect Answers
B:This alternative addresses Linux routing tables and default gateway selection, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Inspect `ip route` and selected `ip route get`, then set or repair the appropriate default route in the active manager or with `ip route` for a controlled temporary change. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
C:That option would assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device, but it addresses a different concern. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
D:That option would map required common services to their correct transport and port, including SSH 22/TCP, HTTP 80/TCP, HTTPS 443/TCP and DNS 53/UDP or TCP where used, but it addresses a different concern. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
Question 522
An operations handoff identifies this problem: A host's interface comes up with unexpected settings because both NetworkManager and systemd-networkd attempt to manage the same link. Which Linux behavior or technical principle BEST explains why the issue occurs? Select ONE best answer.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
- A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
- Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
- TCP, UDP and ICMP have different roles; UDP does not inherently acknowledge or reorder delivery and ICMP ping behavior does not establish application TCP availability.
Explanation
Correct Answer
C:Relevant Linux operating principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
Incorrect Answers
A:That option would assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device, but it addresses a different concern. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers.
B:This alternative addresses Resolver precedence, search domains and systemd-resolved, not the specific issue of NetworkManager and systemd-networkd configuration ownership: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
D:This alternative addresses TCP versus UDP versus ICMP diagnostics, not the specific issue of NetworkManager and systemd-networkd configuration ownership: TCP, UDP and ICMP have different roles; UDP does not inherently acknowledge or reorder delivery and ICMP ping behavior does not establish application TCP availability. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
Question 523
A team maintaining a Linux host reports: A host's interface comes up with unexpected settings because both NetworkManager and systemd-networkd attempt to manage the same link. Which evidence or command result MOST directly tests the suspected root cause? Select ONE best answer.
- Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state.
- Check `ip -4 addr`, compute bitwise network address and broadcast boundary, and inspect `ip route get` for representative peers.
- Inspect interface addresses and routing, compare to the exact RFC1918 CIDR ranges, and test external source visibility where permitted.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
Explanation
Correct Answer
A:Most direct verification evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state.
Incorrect Answers
B:That option would check `ip -4 addr`, compute bitwise network address and broadcast boundary, and inspect `ip route get` for representative peers, but it addresses a different concern. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
C:That option would inspect interface addresses and routing, compare to the exact RFC1918 CIDR ranges, and test external source visibility where permitted, but it addresses a different concern. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
D:This shortcut is unsafe for the present Linux issue: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. It cannot establish a safe correction.
Question 524
While verifying a Linux change request, an engineer finds: A host's interface comes up with unexpected settings because both NetworkManager and systemd-networkd attempt to manage the same link. Which observed outcome BEST confirms a successful and properly scoped correction? Select ONE best answer.
- Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
- The device associates to the approved wireless network, authenticates successfully and receives the expected network configuration.
- Local IPv6 neighbors communicate on the correct interface and routed destinations use a valid global or otherwise routed address with appropriate route.
Explanation
Correct Answer
A:Observable acceptance criterion: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
Incorrect Answers
B:This shortcut is unsafe for the present Linux issue: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
C:This alternative addresses NetworkManager Wi-Fi authentication and saved profiles, not the specific issue of NetworkManager and systemd-networkd configuration ownership: The device associates to the approved wireless network, authenticates successfully and receives the expected network configuration. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
D:This alternative addresses IPv6 addressing link-local scope and prefix rules, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Local IPv6 neighbors communicate on the correct interface and routed destinations use a valid global or otherwise routed address with appropriate route. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
Question 525
A Linux administrator investigates the following system incident: A host's interface comes up with unexpected settings because both NetworkManager and systemd-networkd attempt to manage the same link. Which misleading assumption MOST directly contributes to this failure and should be rejected? Select ONE best answer.
- Assume editing /etc/resolv.conf always overrides a conflicting /etc/hosts entry regardless of NSS hosts order.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
- Assume the command `hostname newname` persistently changes every host identification file and DNS record automatically.
- Assume having any IPv4 address automatically creates a correct default gateway and that multiple default routes always provide harmless equal-cost failover.
Explanation
Correct Answer
B:Reject this specific misconception: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. It incorrectly assumes behavior that conflicts with the observed Linux conditions.
Incorrect Answers
A:This alternative addresses Local hosts resolution versus DNS settings, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Assume editing /etc/resolv.conf always overrides a conflicting /etc/hosts entry regardless of NSS hosts order.
C:This alternative addresses Hostnamectl and durable host identification, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Assume the command `hostname newname` persistently changes every host identification file and DNS record automatically.
D:That option would assume having any IPv4 address automatically creates a correct default gateway and that multiple default routes always provide harmless equal-cost failover, but it addresses a different concern. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
Question 526
On a production Linux workstation or server, a technician observes: A migration from an old ifup/down setup creates new .network files, but active management remains with another service and those files are ignored. Which administrative step is the MOST appropriate way to resolve this issue? Select ONE best answer.
- Choose TCP when reliable ordered byte streams are needed, UDP for connectionless datagrams with application-level reliability as required, and ICMP for appropriate network control and diagnostics.
- Use `ip link` and `ip addr` to examine and adjust temporary interface state and repair the persistent manager configuration where required.
- Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
Explanation
Correct Answer
C:Recommended administrative action: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. network files, but active management remains with another service and those files are ignored.
Incorrect Answers
A:This alternative addresses TCP versus UDP versus ICMP diagnostics, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Choose TCP when reliable ordered byte streams are needed, UDP for connectionless datagrams with application-level reliability as required, and ICMP for appropriate network control and diagnostics. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
B:That option would use `ip link` and `ip addr` to examine and adjust temporary interface state and repair the persistent manager configuration where required, but it addresses a different concern. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
D:This shortcut is unsafe for the present Linux issue: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. network files, but active management remains with another service and those files are ignored.
Question 527
During an LPIC-1 practice lab, the operator encounters this condition: A migration from an old ifup/down setup creates new .network files, but active management remains with another service and those files are ignored. Which Linux behavior or technical principle BEST explains why the issue occurs? Select ONE best answer.
- The iproute2 command changes and reports kernel interface state, while durable settings are managed by the host's networking service.
- Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
- A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Explanation
Correct Answer
B:Relevant Linux operating principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. network files, but active management remains with another service and those files are ignored.
Incorrect Answers
A:This alternative addresses Ip command address and link troubleshooting, not the specific issue of NetworkManager and systemd-networkd configuration ownership: The iproute2 command changes and reports kernel interface state, while durable settings are managed by the host's networking service. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
C:This shortcut is unsafe for the present Linux issue: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. It cannot establish a safe correction. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
D:This alternative addresses Resolver precedence, search domains and systemd-resolved, not the specific issue of NetworkManager and systemd-networkd configuration ownership: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
Question 528
A helpdesk escalation describes this Linux behavior: A migration from an old ifup/down setup creates new .network files, but active management remains with another service and those files are ignored. Which evidence or command result MOST directly tests the suspected root cause? Select ONE best answer.
- Compare `getent hosts name`, /etc/nsswitch.conf hosts line, /etc/hosts entry and DNS-only `dig` output.
- Inspect `hostnamectl status`, /etc/hostname, /etc/hosts and `getent hosts` output before and after reboot.
- Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
Explanation
Correct Answer
C:Most direct verification evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. network files, but active management remains with another service and those files are ignored.
Incorrect Answers
A:This alternative addresses Local hosts resolution versus DNS settings, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Compare `getent hosts name`, /etc/nsswitch.conf hosts line, /etc/hosts entry and DNS-only `dig` output.
B:This alternative addresses Hostnamectl and durable host identification, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Inspect `hostnamectl status`, /etc/hostname, /etc/hosts and `getent hosts` output before and after reboot.
D:This shortcut is unsafe for the present Linux issue: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. It cannot establish a safe correction. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
Question 529
An operations handoff identifies this problem: A migration from an old ifup/down setup creates new .network files, but active management remains with another service and those files are ignored. Which observed outcome BEST confirms a successful and properly scoped correction? Select ONE best answer.
- Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
- Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
- The host reports the approved name consistently and local resolution returns the correct intended addresses.
Explanation
Correct Answer
A:Observable acceptance criterion: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides. network files, but active management remains with another service and those files are ignored.
Incorrect Answers
B:This alternative addresses Resolver precedence, search domains and systemd-resolved, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Appropriate response: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. Root-cause evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. Independent acceptance: Only the chosen manager owns the interface and configuration survives a controlled network-service restart without unexpected overrides.
C:This shortcut is unsafe for the present Linux issue: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
D:This alternative addresses Hostnamectl and durable host identification, not the specific issue of NetworkManager and systemd-networkd configuration ownership: The host reports the approved name consistently and local resolution returns the correct intended addresses.
Question 530
A team maintaining a Linux host reports: A migration from an old ifup/down setup creates new .network files, but active management remains with another service and those files are ignored. Which TWO complementary steps provide the best corrective action and its most direct diagnostic verification? Select TWO answers.
- Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers.
- Inspect `ip -br link`, `ip address show`, carrier state and manager logs before and after a controlled interface activation.
- Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state.
- Choose TCP when reliable ordered byte streams are needed, UDP for connectionless datagrams with application-level reliability as required, and ICMP for appropriate network control and diagnostics.
- Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device.
Explanation
Correct Answers
A:Recommended administrative action: Identify the active network configuration manager and express persistent settings in its supported profiles or .network files without competing managers. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
C:Most direct verification evidence: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state. network files, but active management remains with another service and those files are ignored. Linux principle: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
Incorrect Answers
B:That option would inspect `ip -br link`, `ip address show`, carrier state and manager logs before and after a controlled interface activation, but it addresses a different concern. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
D:This alternative addresses TCP versus UDP versus ICMP diagnostics, not the specific issue of NetworkManager and systemd-networkd configuration ownership: Choose TCP when reliable ordered byte streams are needed, UDP for connectionless datagrams with application-level reliability as required, and ICMP for appropriate network control and diagnostics. network files, but active management remains with another service and those files are ignored.
E:This shortcut is unsafe for the present Linux issue: Assume any file under /etc/systemd/network will control an interface regardless of which network manager actually owns the device. network files, but active management remains with another service and those files are ignored. Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.