LFCS Networking Practice Question
A server must resolve internal hostnames using a DNS server at 10.0.0.53 before falling back to public resolvers. The administrator edits /etc/systemd/resolved.conf and sets DNS=10.0.0.53 and FallbackDNS=8.8.8.8. After restarting systemd-resolved, queries for internal names still fail. Which additional step is most likely required?
⚠ Common exam trap
The trap here is assuming that editing resolved.conf is sufficient, when the /etc/resolv.conf symlink determines whether systemd-resolved is actually used.
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
✓
Ensure /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf.
systemd-resolved reads DNS server settings from resolved.conf, but applications reach it through /etc/resolv.conf. If that file is not symlinked to the stub or full resolv.conf generated by systemd-resolved, the configured servers are ignored. Recreating the symlink ensures queries go through systemd-resolved and reach 10.0.0.53.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Ensure /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf.
Why this is correct
systemd-resolved only serves queries through its stub listener if /etc/resolv.conf points to the stub resolver file. If it still points to a static file or a different target, applications bypass systemd-resolved and the configured DNS servers are never used. Correcting the symlink makes the configuration effective.
- ✗
Add the search domain to /etc/hosts so internal names resolve locally.
Why it's wrong here
Editing /etc/hosts only provides static mappings for the specific names listed and does not integrate with systemd-resolved's DNS configuration. It would not make the internal DNS server at 10.0.0.53 be queried, so it does not address the failure to resolve arbitrary internal hostnames.
- ✗
Run resolvectl flush-caches to clear stale entries.
Why it's wrong here
Flushing the cache can help with stale records but does not change which DNS servers are queried. If /etc/resolv.conf does not point to systemd-resolved, the configured DNS server is never contacted, so flushing the cache alone will not resolve the problem.
- ✗
Set DNSSEC=no in resolved.conf because DNSSEC validation is blocking internal responses.
Why it's wrong here
DNSSEC validation failures would typically produce SERVFAIL responses for signed domains, not a complete inability to reach the internal server. Disabling DNSSEC does not fix a resolv.conf that bypasses systemd-resolved, so it is not the most likely required step.
Visual reference
Go deeper
Related to this question
About these practice questions
This LFCS question is part of Courseiva's 406-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Linux Foundation exam blueprint
This LFCS practice question is part of Courseiva's free Linux Foundation 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 LFCS exam.