LPIC-1 Essential System Services and Networking Practice Question
A server runs systemd-resolved and uses a VPN. DNS queries fail intermittently. The administrator checks /etc/resolv.conf and finds it is a symlink to /run/systemd/resolve/stub-resolv.conf. Which command should be used to view the effective DNS servers and debug the issue?
⚠ Common exam trap
Watch out — candidates often assume `cat /etc/resolv.conf` shows the real DNS servers, but because it is a symlink to the stub resolver's configuration, it only shows 127.0.0.53, masking the actual upstream servers that systemd-resolved uses.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
resolvectl status
B is correct because `resolvectl status` is the native command for querying systemd-resolved's internal state, showing the per-link DNS servers, search domains, and current resolver configuration. Since `/etc/resolv.conf` is a symlink to the stub resolver, `cat /etc/resolv.conf` only shows the stub listener address (127.0.0.53), not the actual upstream DNS servers used by systemd-resolved. `resolvectl status` reveals the effective DNS servers for each network interface, including VPN interfaces, which is essential for debugging intermittent failures.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
cat /etc/resolv.conf
Why it's wrong here
Reading the stub file shows only the loopback stub address 127.0.0.53, not the per-link upstream servers systemd-resolved actually uses, so VPN-supplied DNS stays hidden. It is tempting because resolv.conf traditionally listed real nameservers, and on systems without systemd-resolved it would be the correct file to inspect.
- ✓
resolvectl status
Why this is correct
`resolvectl status` queries systemd-resolved directly over D-Bus, exposing per-link DNS servers, current DNS server, and DNSSEC settings for each interface. Because /etc/resolv.conf only points at the 127.0.0.53 stub, it hides the VPN link's actual upstream servers, so this command reveals the split-DNS configuration causing the intermittent failures.
- ✗
systemctl restart systemd-resolved
Why it's wrong here
Restarting systemd-resolved clears the cache and reloads configuration but displays no DNS servers, so it cannot reveal which upstream resolvers the VPN pushed. Tempting because restarting often fixes transient resolution faults, yet diagnosis requires resolvectl status, which prints per-link DNS servers and current settings.
- ✗
dig @localhost
Why it's wrong here
Querying localhost hits the stub listener, which forwards to whichever upstream is currently selected; it reveals resolution results but not the effective per-link DNS server list or routing decisions needed to debug intermittent VPN failures. It is tempting because dig is the standard DNS troubleshooting tool, and against a specific nameserver it would be the right choice.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every LPIC-1 question from scratch — 402 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-1 practice question is part of Courseiva's free LPI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LPIC-1 exam.