Networking practice questions

A server has two network interfaces: eth0 (10.0.1.10/24, gateway 10.0.1.1) and eth1 (192.168.1.10/24, no gateway). Both are up. The default gateway is set to 10.0.1.1. A ping to 8.8.8.8 fails, but ping to 10.0.1.1 succeeds. What is the most likely cause?

Trap 1: eth1 has no gateway configured

eth1 carries no default route and is not used for internet-bound traffic, so its missing gateway is irrelevant; the default route already points via eth0's 10.0.1.1. A second interface lacking a gateway is correct design when it serves only its local 192.168.1.0/24 subnet.

Trap 2: DNS resolution is failing

Ping to 8.8.8.8 is a raw ICMP echo to a literal IP address, so no name resolution occurs; DNS cannot cause this failure. DNS would be the culprit if pinging a hostname such as google.com failed while the numeric IP succeeded.

Trap 3: eth0 is down

The successful ping to 10.0.1.1 proves eth0 is up and forwarding, since that gateway is reachable only through eth0. A down eth0 would break that ping too. This option would fit if the local gateway were unreachable while remote hosts still responded.

A
eth1 has no gateway configured
Why it fails: eth1 carries no default route and is not used for internet-bound traffic, so its missing gateway is irrelevant; the default route already points via eth0's 10.0.1.1. A second interface lacking a gateway is correct design when it serves only its local 192.168.1.0/24 subnet.
B
The default route is missing or pointing to an incorrect gateway
Even though the gateway is reachable, the default route may be missing or misconfigured.
C
DNS resolution is failing
Why it fails: Ping to 8.8.8.8 is a raw ICMP echo to a literal IP address, so no name resolution occurs; DNS cannot cause this failure. DNS would be the culprit if pinging a hostname such as google.com failed while the numeric IP succeeded.
D
eth0 is down
Why it fails: The successful ping to 10.0.1.1 proves eth0 is up and forwarding, since that gateway is reachable only through eth0. A down eth0 would break that ping too. This option would fit if the local gateway were unreachable while remote hosts still responded.

Question 2hardmultiple choice

A host with this routing table can ping 10.0.2.1 but cannot ping 8.8.8.8. What is the most likely cause?

Exhibit

Refer to the exhibit.

# ip route show
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.10
10.0.2.0/24 dev eth1 proto kernel scope link src 10.0.2.10
default via 10.0.1.1 dev eth0

Trap 1: The default route is missing

The table shows a default route via 10.0.1.1.

Trap 2: The host has no route to 10.0.2.0/24

The table shows a direct route to 10.0.2.0/24 via eth1.

Trap 3: The host has no route to 10.0.1.1

The host has a direct route to 10.0.1.0/24, so it can reach 10.0.1.1.

A
The default route is missing
Why it fails: The table shows a default route via 10.0.1.1.
B
The default gateway 10.0.1.1 does not have internet connectivity
Even though the host can reach the gateway, the gateway itself may not have a path to the internet.
C
The host has no route to 10.0.2.0/24
Why it fails: The table shows a direct route to 10.0.2.0/24 via eth1.
D
The host has no route to 10.0.1.1
Why it fails: The host has a direct route to 10.0.1.0/24, so it can reach 10.0.1.1.

Question 3mediummultiple choice

You are troubleshooting a Linux server that acts as a router between two networks: 10.0.1.0/24 (eth0) and 10.0.2.0/24 (eth1). IP forwarding is enabled. Hosts on 10.0.1.0/24 can ping the server's eth0 IP (10.0.1.1), but cannot ping hosts on 10.0.2.0/24 (e.g., 10.0.2.10). The server can ping both 10.0.2.10 and 10.0.1.10. The iptables FORWARD chain policy is ACCEPT. What is the most likely cause?

Trap 1: The server cannot reach 10.0.2.10

The stem states the server can already ping 10.0.2.10, so this is factually contradicted by the scenario. It tempts candidates who assume a routing failure on the far side, but reachability is proven; the fault lies in the return path or forwarding of transit traffic, not the server's own connectivity.

Trap 2: IP forwarding is not enabled

The stem explicitly states IP forwarding is enabled, so this contradicts the given facts. It tempts because disabled forwarding is the classic cause of failed transit routing, and would be correct if /proc/sys/net/ipv4/ip_forward returned 0 — but here the server itself routes fine.

Trap 3: The iptables FORWARD chain has a DROP policy

The stem states the FORWARD chain policy is ACCEPT, so a DROP policy cannot be the cause. It tempts because a restrictive FORWARD policy is a common reason transit packets are discarded, and would be correct if the policy were DROP or a rule matched those packets.

A
The hosts on 10.0.1.0/24 do not have a route to 10.0.2.0/24
The server forwards fine because FORWARD is ACCEPT and it can reach both subnets, so the fault lies with the clients. Hosts on 10.0.1.0/24 lack a route pointing to 10.0.2.0/24 via 10.0.1.1, so their replies never reach the destination.
B
The server cannot reach 10.0.2.10
Why it fails: The stem states the server can already ping 10.0.2.10, so this is factually contradicted by the scenario. It tempts candidates who assume a routing failure on the far side, but reachability is proven; the fault lies in the return path or forwarding of transit traffic, not the server's own connectivity.
C
IP forwarding is not enabled
Why it fails: The stem explicitly states IP forwarding is enabled, so this contradicts the given facts. It tempts because disabled forwarding is the classic cause of failed transit routing, and would be correct if /proc/sys/net/ipv4/ip_forward returned 0 — but here the server itself routes fine.
D
The iptables FORWARD chain has a DROP policy
Why it fails: The stem states the FORWARD chain policy is ACCEPT, so a DROP policy cannot be the cause. It tempts because a restrictive FORWARD policy is a common reason transit packets are discarded, and would be correct if the policy were DROP or a rule matched those packets.

Review the full subnetting walkthrough →

Question 4mediummultiple choice

A server has two network interfaces: eth0 (10.0.0.10/24) and eth1 (192.168.1.10/24). The server needs to act as a router for a subnet 172.16.0.0/24, forwarding packets between it and the 10.0.0.0/24 network. Which sysctl parameter must be set to a value of 1 to enable IP forwarding?

Trap 1: net.core.forwarding

`net.core.forwarding` is not a valid sysctl parameter; the correct parameters are under the `net.ipv4` hierarchy.

Trap 2: net.ipv4.tcp_forwarding

`net.ipv4.tcp_forwarding` does not exist; TCP forwarding is not controlled by this parameter.

A
net.ipv4.conf.all.forwarding
Setting `net.ipv4.conf.all.forwarding=1` enables IPv4 packet forwarding across every interface, satisfying the router requirement between 172.16.0.0/24 and 10.0.0.0/24. The per-interface alternative, `net.ipv4.conf.eth0.forwarding`, would only cover one interface, so the `all` key is the reliable global switch here.
B
net.core.forwarding
Why it fails: `net.core.forwarding` is not a valid sysctl parameter; the correct parameters are under the `net.ipv4` hierarchy.
C
net.ipv4.tcp_forwarding
Why it fails: `net.ipv4.tcp_forwarding` does not exist; TCP forwarding is not controlled by this parameter.
D
net.ipv4.ip_forward
Setting net.ipv4.ip_forward to 1 enables the kernel to forward IPv4 packets between interfaces, which is precisely what routing between 172.16.0.0/24 and 10.0.0.0/24 requires. Without it, the server drops transit traffic arriving on eth1 rather than relaying it out eth0.

Question 5easymultiple choice

Based on the exhibit, which port is listening only on the loopback interface?

Exhibit

Refer to the exhibit.

[root@server ~]# ss -tln
State   Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   
LISTEN  0        128      0.0.0.0:22          0.0.0.0:*          
LISTEN  0        128      *:80                *:*                 
LISTEN  0        128      *:443               *:*                 
LISTEN  0        128      127.0.0.1:53        0.0.0.0:*          
LISTEN  0        128      0.0.0.0:8080        0.0.0.0:*

Trap 1: 22

Listening on 0.0.0.0, meaning all interfaces.

Trap 2: 443

Listening on * (all interfaces).

Trap 3: 80

Listening on * (all interfaces).

A
53
Port 53 satisfies the loopback-only constraint because its listening socket binds to 127.0.0.1 rather than 0.0.0.0, restricting access to the local host. In the exhibit, only this entry shows the loopback address in the local address column, confirming the service accepts connections solely from the machine itself.
B
22
Why it fails: Listening on 0.0.0.0, meaning all interfaces.
C
443
Why it fails: Listening on * (all interfaces).
D
80
Why it fails: Listening on * (all interfaces).

Question 6hardmultiple choice

You are a systems administrator for a company that runs a critical web application on a Linux server. The server has two network interfaces: eth0 (public IP 203.0.113.10/24, gateway 203.0.113.1) and eth1 (private IP 10.0.0.10/24). The web server listens on port 443 (HTTPS) and must be accessible from the internet. The server also needs to connect to an internal database server at 10.0.0.50/24 on port 3306. Recently, users reported that the website is intermittently unreachable. You SSH into the server and run 'ss -tln' and see that the web server is listening on 0.0.0.0:443. You check the routing table with 'ip route show' and see: default via 203.0.113.1 dev eth0; 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.10. You also run 'iptables -L -n -v' and see: Chain INPUT (policy ACCEPT), with no rules. However, you notice that the server's default gateway is unreachable from the server itself when you run 'ping 203.0.113.1' (100% packet loss). What is the most likely cause of the intermittent unreachability?

Trap 1: The web server is not listening on the public IP address.

Listening on 0.0.0.0 means it listens on all interfaces, including the public one.

Trap 2: A firewall rule is blocking incoming HTTPS traffic.

The iptables output shows no rules, so no traffic is being blocked.

Trap 3: The private interface eth1 has a misconfigured IP address.

The routing table shows a valid route on eth1, and the database connectivity is not mentioned as an issue.

A
The web server is not listening on the public IP address.
Why it fails: Listening on 0.0.0.0 means it listens on all interfaces, including the public one.
B
A firewall rule is blocking incoming HTTPS traffic.
Why it fails: The iptables output shows no rules, so no traffic is being blocked.
C
The default gateway is unreachable, preventing return traffic from the internet.
With no iptables rules blocking traffic, the unreachable default gateway 203.0.113.1 means outbound replies cannot leave via eth0. Return traffic to internet clients is dropped, causing intermittent unreachability, while the internal 10.0.0.0/24 route still works.
D
The private interface eth1 has a misconfigured IP address.
Why it fails: The routing table shows a valid route on eth1, and the database connectivity is not mentioned as an issue.

Question 7hardmultiple choice

A company wants to ensure that a web server (IP 192.168.1.10) is accessible from the internet via port 443, but all other inbound traffic should be blocked. The server also needs to communicate with an internal database (IP 10.0.0.50) on port 3306. The default firewall zone is 'public'. Which iptables rules should be applied to the server?

Trap 1: iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT…

This allows only established connections, not new HTTPS connections.

Trap 2: iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -P INPUT…

This accepts all incoming traffic, not just HTTPS.

Trap 3: iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT…

This blocks all outgoing traffic, preventing the database connection.

A
iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT; iptables -P INPUT DROP
Why it fails: This allows only established connections, not new HTTPS connections.
B
iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -P INPUT ACCEPT
Why it fails: This accepts all incoming traffic, not just HTTPS.
C
iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT; iptables -P INPUT DROP; iptables -P OUTPUT ACCEPT
This allows incoming HTTPS, blocks other inbound, and allows all outbound.
D
iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT; iptables -P INPUT DROP; iptables -P OUTPUT DROP
Why it fails: This blocks all outgoing traffic, preventing the database connection.

Question 8easymulti select

Which TWO commands can be used to display the current routing table on a Linux system?

Trap 1: ss -r

The `ss -r` command does not exist; `ss` is used for socket statistics, not routing table display.

Trap 2: netstat -r

`netstat -r` can display the routing table but is deprecated. The LFCS exam emphasizes the modern `ip` command over legacy tools like netstat, so it is not considered a correct answer here.

Trap 3: ifconfig

ifconfig displays network interfaces, not routing tables.

A
ss -r
Why it fails: The `ss -r` command does not exist; `ss` is used for socket statistics, not routing table display.
B
route -n
route -n prints the kernel IPv4 routing table, with -n suppressing DNS resolution so gateways and destinations appear as numeric addresses. It reads the same table as ip route, satisfying the requirement to display current routes without name lookups.
C
ip route show
The iproute2 suite's ip route show dumps the kernel's IPv4 routing table, listing destination prefixes, gateways and interfaces. It satisfies the stem's requirement to display current routes, unlike netstat, which is deprecated and may be absent on modern distributions.
D
netstat -r
Why it fails: `netstat -r` can display the routing table but is deprecated. The LFCS exam emphasizes the modern `ip` command over legacy tools like netstat, so it is not considered a correct answer here.
E
ifconfig
Why it fails: ifconfig displays network interfaces, not routing tables.

Question 9mediummultiple choice

Based on the exhibit, a system administrator runs ping to 8.8.8.8 and gets 'Destination Host Unreachable'. What is the most likely cause?

Exhibit

Refer to the exhibit.
# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1a:2b:3c:4d:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.15/24 brd 192.168.10.255 scope global dynamic eth0
       valid_lft 86399sec preferred_lft 86399sec
    inet6 fe80::21a:2bff:fe3c:4d5e/64 scope link
       valid_lft forever preferred_lft forever
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
# ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.10.15 icmp_seq=1 Destination Host Unreachable

Trap 1: The IP address 192.168.10.15 is not configured on eth0.

The IP is configured as shown in ip addr.

Trap 2: A firewall is blocking ICMP traffic.

The error is 'Destination Host Unreachable', not 'Request timed out', suggesting a routing issue rather than a firewall block.

Trap 3: The default route is missing.

The default route is present (0.0.0.0 via 192.168.10.1).

A
The IP address 192.168.10.15 is not configured on eth0.
Why it fails: The IP is configured as shown in ip addr.
B
A firewall is blocking ICMP traffic.
Why it fails: The error is 'Destination Host Unreachable', not 'Request timed out', suggesting a routing issue rather than a firewall block.
C
The gateway 192.168.10.1 is not reachable from this host.
The ping error indicates the gateway cannot be reached, likely because it's down or not on the same network.
D
The default route is missing.
Why it fails: The default route is present (0.0.0.0 via 192.168.10.1).

Read the full DNS explanation →

Question 10mediumdrag order

Order the steps to troubleshoot a DNS resolution issue from a Linux client.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Check firewall settings, then check network connectivity, then test…

This is incorrect because checking the firewall first is premature; you should verify the DNS configuration and test basic connectivity before assuming the firewall is the issue.

Trap 2: Test DNS resolution, then check DNS configuration, then check…

This is incorrect because you should check the DNS configuration before testing resolution; otherwise, you might misdiagnose a misconfigured resolver as a network problem.

Trap 3: Check network connectivity, then check DNS configuration, then test…

This is incorrect because checking connectivity before DNS configuration is less efficient; DNS issues often stem from configuration errors, so that should be the first step.

A
Check DNS configuration, then test DNS resolution, then check network connectivity, then check firewall settings
This is the correct order because you start by verifying the DNS configuration (e.g., /etc/resolv.conf), then test resolution with tools like nslookup, then check general connectivity (ping), and finally examine firewall rules that might block DNS traffic.
B
Check firewall settings, then check network connectivity, then test DNS resolution, then check DNS configuration
Why it fails: This is incorrect because checking the firewall first is premature; you should verify the DNS configuration and test basic connectivity before assuming the firewall is the issue.
C
Test DNS resolution, then check DNS configuration, then check firewall settings, then check network connectivity
Why it fails: This is incorrect because you should check the DNS configuration before testing resolution; otherwise, you might misdiagnose a misconfigured resolver as a network problem.
D
Check network connectivity, then check DNS configuration, then test DNS resolution, then check firewall settings
Why it fails: This is incorrect because checking connectivity before DNS configuration is less efficient; DNS issues often stem from configuration errors, so that should be the first step.

Question 11mediummatching

Match each Linux command to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Search text using patterns

Stream editor for text manipulation

Pattern scanning and processing language

Search for files in a directory hierarchy

Build and execute command lines from input

Trap 1: grep: stream editor for filtering and transforming text

Incorrect — stream editing is the function of sed, not grep.

Trap 2: sed: search text using patterns

Incorrect — pattern searching is the function of grep, not sed.

A
grep: search text using patterns
grep is used to search text files for lines matching a regular expression pattern.
B
sed: stream editor for filtering and transforming text
sed is a stream editor that performs basic text transformations on an input stream.
C
awk: pattern scanning and text processing language
awk is a scripting language used for pattern scanning and text processing.
D
find: search for files in a directory hierarchy
find searches for files in a directory tree based on criteria like name, type, size.
E
grep: stream editor for filtering and transforming text
Why it fails: Incorrect — stream editing is the function of sed, not grep.
F
sed: search text using patterns
Why it fails: Incorrect — pattern searching is the function of grep, not sed.

Question 12hardmultiple choice

A company is designing a multi-homed server with two network interfaces: one for internal traffic (eth0) and one for external traffic (eth1). The server must prioritize traffic to the 10.1.0.0/16 network through eth0. What is the best practice to ensure traffic to 10.1.0.0/16 uses eth0?

Trap 1: Configure policy routing using ip rule and two routing tables.

Policy routing is not necessary for a simple static route.

Trap 2: Set a lower metric on the default route for eth0.

Metrics affect default gateway selection, not specific subnets.

Trap 3: Use bonding to combine both interfaces.

Bonding is for fault tolerance or throughput, not for routing specific subnets.

A
Add a static route for 10.1.0.0/16 via the gateway on eth0.
A static route directs traffic for that subnet to the correct interface.
B
Configure policy routing using ip rule and two routing tables.
Why it fails: Policy routing is not necessary for a simple static route.
C
Set a lower metric on the default route for eth0.
Why it fails: Metrics affect default gateway selection, not specific subnets.
D
Use bonding to combine both interfaces.
Why it fails: Bonding is for fault tolerance or throughput, not for routing specific subnets.

Question 13hardmultiple choice

A server on a corporate network is intermittently losing connectivity. The administrator runs 'tcpdump -i eth0 icmp' and sees 'ICMP time exceeded in-transit' messages from a router. What is the most likely cause?

Trap 1: There is a mismatch in MTU size.

MTU mismatches produce fragmentation-needed ICMP messages (type 3, code 4) when the DF flag is set, not time-exceeded. The time-exceeded message specifically indicates TTL expiry, typically from a routing loop. MTU is tempting because it also causes intermittent connectivity, but the ICMP type differs.

Trap 2: The destination host is down.

A down host produces ICMP destination-unreachable or echo-request timeouts, not time-exceeded messages, which routers emit when a packet's TTL hits zero. Confusing unreachable-host symptoms with TTL expiry is tempting because both cause failed connectivity, but only routing loops or excessive hop counts generate time exceeded.

Trap 3: A firewall is blocking the packets.

Firewalls silently drop or reject packets, generating no ICMP time-exceeded messages; a router emitting them indicates TTL expiry from a routing loop. Blocking is tempting because it also causes intermittent loss, but the observed ICMP type points to forwarding loops rather than filtering.

A
There is a mismatch in MTU size.
Why it fails: MTU mismatches produce fragmentation-needed ICMP messages (type 3, code 4) when the DF flag is set, not time-exceeded. The time-exceeded message specifically indicates TTL expiry, typically from a routing loop. MTU is tempting because it also causes intermittent connectivity, but the ICMP type differs.
B
The destination host is down.
Why it fails: A down host produces ICMP destination-unreachable or echo-request timeouts, not time-exceeded messages, which routers emit when a packet's TTL hits zero. Confusing unreachable-host symptoms with TTL expiry is tempting because both cause failed connectivity, but only routing loops or excessive hop counts generate time exceeded.
C
A firewall is blocking the packets.
Why it fails: Firewalls silently drop or reject packets, generating no ICMP time-exceeded messages; a router emitting them indicates TTL expiry from a routing loop. Blocking is tempting because it also causes intermittent loss, but the observed ICMP type points to forwarding loops rather than filtering.
D
There is a routing loop or the TTL is too low.
ICMP time exceeded in-transit is generated when a packet's TTL reaches zero before delivery, which happens when a routing loop causes packets to circulate. This directly explains the intermittent connectivity loss, since looping traffic never reaches its destination.

Question 14mediummultiple choice

A company deploys a new web server with two network interfaces: one for public access (eth0) and one for database access (eth1). The database server is at 10.0.0.10. The web server's default gateway is via eth0, but traffic to 10.0.0.10 is being routed through eth0 instead of eth1. What is the simplest fix?

Trap 1: Remove the default gateway on eth0.

Would break internet access.

Trap 2: Configure policy routing to use both tables.

Policy routing would require additional routing tables and rules to direct traffic based on source or destination, but the stem’s issue is that the default gateway on eth0 overrides the direct route to 10.0.0.10 via eth1. The simplest fix is adding a static route for 10.0.0.0/24 via eth1, not policy routing. This option tempts because policy routing solves complex multi-homing scenarios where traffic must be selected by attributes like source IP or packet mark, but here only a single destination subnet needs a different next-hop, making a static route sufficient.

Trap 3: Change the default gateway metric to prefer eth1.

That would route all traffic through eth1, not desired.

A
Remove the default gateway on eth0.
Why it fails: Would break internet access.
B
Configure policy routing to use both tables.
Why it fails: Policy routing would require additional routing tables and rules to direct traffic based on source or destination, but the stem’s issue is that the default gateway on eth0 overrides the direct route to 10.0.0.10 via eth1. The simplest fix is adding a static route for 10.0.0.0/24 via eth1, not policy routing. This option tempts because policy routing solves complex multi-homing scenarios where traffic must be selected by attributes like source IP or packet mark, but here only a single destination subnet needs a different next-hop, making a static route sufficient.
C
Add a static route for 10.0.0.10/32 via eth1's gateway.
Directs only database traffic through eth1.
D
Change the default gateway metric to prefer eth1.
Why it fails: That would route all traffic through eth1, not desired.

Question 15hardmulti select

Which THREE conditions can cause an 'RTNETLINK answers: File exists' error when adding a static route?

Trap 1: The gateway is unreachable.

Would give 'Network is unreachable' error.

Trap 2: The interface is down.

Would give 'Cannot assign requested address' or similar.

A
The route exists with a different metric but same destination and netmask.
Metric is not part of the uniqueness; still duplicates.
B
The gateway is unreachable.
Why it fails: Would give 'Network is unreachable' error.
C
The interface is down.
Why it fails: Would give 'Cannot assign requested address' or similar.
D
The route exists with a different gateway but same destination and netmask.
Still a duplicate route entry if the destination/netmask is the same.
E
The route already exists with the same destination and netmask (exact duplicate).
Adding exact duplicate route returns 'File exists'.

Read the full DNS explanation →

Question 16easymulti select

Which TWO configuration files are commonly used to set DNS resolver settings on a Linux system?

Trap 1: /etc/hostname

Sets the hostname only.

Trap 2: /etc/sysconfig/network

Contains general network settings, not DNS resolver.

Trap 3: /etc/hosts

Contains static hostname mappings.

A
/etc/nsswitch.conf
Controls order of name resolution (e.g., files, dns).
B
/etc/hostname
Why it fails: Sets the hostname only.
C
/etc/sysconfig/network
Why it fails: Contains general network settings, not DNS resolver.
D
/etc/hosts
Why it fails: Contains static hostname mappings.
E
/etc/resolv.conf
Contains nameserver and search domain settings.

Question 17mediummultiple choice

Given the routing table output in the exhibit, what will happen when the system tries to send a packet to 10.1.1.1?

Exhibit

Refer to the exhibit.

$ ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 100
10.0.0.0/8 via 192.168.1.1 dev eth0 proto static metric 100
default via 192.168.1.1 dev eth0 proto static metric 100

Trap 1: The packet is sent via eth1.

Traffic to 10.1.1.1 matches a more specific route in the table, so eth1 is not selected for this destination. Sending via a named interface is what happens when that interface's connected subnet covers the address, which is not the case here.

Trap 2: The packet is sent via default route.

The default route is consulted only when no other entry matches the destination. Because the routing table contains a route covering 10.1.1.1, that entry is chosen and the default route is bypassed. Default routes suit destinations absent from the table.

Trap 3: The packet is dropped because there is no subnet matching 10.1.1.1.

There is a route: 10.0.0.0/8 covers 10.1.1.1.

A
The packet is sent via eth1.
Why it fails: Traffic to 10.1.1.1 matches a more specific route in the table, so eth1 is not selected for this destination. Sending via a named interface is what happens when that interface's connected subnet covers the address, which is not the case here.
B
The packet is sent to 192.168.1.1 via eth0.
The routing table's default gateway entry (0.0.0.0/0) via 192.168.1.1 on eth0 matches 10.1.1.1 when no more specific route exists. The packet is therefore forwarded to that gateway's MAC address out eth0, satisfying the exhibit's longest-prefix-match lookup.
C
The packet is sent via default route.
Why it fails: The default route is consulted only when no other entry matches the destination. Because the routing table contains a route covering 10.1.1.1, that entry is chosen and the default route is bypassed. Default routes suit destinations absent from the table.
D
The packet is dropped because there is no subnet matching 10.1.1.1.
Why it fails: There is a route: 10.0.0.0/8 covers 10.1.1.1.

Question 18mediummultiple choice

After configuring iptables rules on a Linux server, a junior administrator notices that incoming SSH connections from a specific IP address (192.168.1.100) are being blocked even though there is a rule to allow all traffic from that IP. The current rule set is: 1. -A INPUT -s 192.168.1.100 -j ACCEPT; 2. -A INPUT -p tcp --dport 22 -j DROP. What is the most likely reason for the block?

Trap 1: The IP address is being matched by a conntrack rule instead.

No conntrack rule appears in the supplied ruleset, and conntrack tracks established flows rather than overriding explicit ACCEPT or DROP verdicts in the INPUT chain. Conntrack matters when stateful matching (for example ESTABLISHED,RELATED) is required to permit return traffic for outbound-initiated sessions.

Trap 2: The ACCEPT rule for the IP uses the wrong chain.

Both rules sit in the INPUT chain, so the chain is correct; the ACCEPT rule simply precedes the DROP rule and should match first. Chain selection matters when traffic traverses a different path, such as FORWARD for routed packets or OUTPUT for locally generated traffic, which is not the case here.

Trap 3: The SSH service is listening only on IPv6.

IPv6-only listening would not explain a blocked IPv4 connection from 192.168.1.100, and the DROP rule explicitly targets IPv4 TCP port 22. IPv6 binding is relevant when clients connect over IPv6 addresses while the service binds only to the IPv4 stack, which is not the scenario described.

A
The IP address is being matched by a conntrack rule instead.
Why it fails: No conntrack rule appears in the supplied ruleset, and conntrack tracks established flows rather than overriding explicit ACCEPT or DROP verdicts in the INPUT chain. Conntrack matters when stateful matching (for example ESTABLISHED,RELATED) is required to permit return traffic for outbound-initiated sessions.
B
The ACCEPT rule for the IP uses the wrong chain.
Why it fails: Both rules sit in the INPUT chain, so the chain is correct; the ACCEPT rule simply precedes the DROP rule and should match first. Chain selection matters when traffic traverses a different path, such as FORWARD for routed packets or OUTPUT for locally generated traffic, which is not the case here.
C
The DROP rule for port 22 appears before the ACCEPT rule for the IP.
Correct. The block occurs because the DROP rule is evaluated before the ACCEPT rule.
D
The SSH service is listening only on IPv6.
Why it fails: IPv6-only listening would not explain a blocked IPv4 connection from 192.168.1.100, and the DROP rule explicitly targets IPv4 TCP port 22. IPv6 binding is relevant when clients connect over IPv6 addresses while the service binds only to the IPv4 stack, which is not the scenario described.

Question 19easymultiple choice

A system administrator wants to ensure that network interfaces receive predictable names based on firmware/BIOS topology rather than kernel enumeration. Which naming scheme should be enabled in GRUB?

Trap 1: net.ifnames=0

Incorrect. `net.ifnames=0` disables predictable naming, forcing kernel-style ethX names. It is the opposite of what the question asks.

Trap 2: ifrename=enable

Incorrect: `ifrename=enable` is not a valid GRUB parameter for controlling naming schemes.

Trap 3: biosdevname=0

Incorrect: `biosdevname=0` disables the Dell-specific biosdevname scheme, but the question asks for a firmware/BIOS topology-based scheme, which is enabled by `net.ifnames=0`.

A
net.ifnames=0
Why it fails: Incorrect. `net.ifnames=0` disables predictable naming, forcing kernel-style ethX names. It is the opposite of what the question asks.
B
ifrename=enable
Why it fails: Incorrect: `ifrename=enable` is not a valid GRUB parameter for controlling naming schemes.
C
net.ifnames=1
Correct. `net.ifnames=1` enables predictable naming based on firmware/BIOS topology, producing names like enp0s3 or ens33.
D
biosdevname=0
Why it fails: Incorrect: `biosdevname=0` disables the Dell-specific biosdevname scheme, but the question asks for a firmware/BIOS topology-based scheme, which is enabled by `net.ifnames=0`.

Read the full DHCP explanation →

Question 20easymultiple choice

A system administrator is troubleshooting a DHCP issue on a Linux client. After running 'dhclient -r eth0' and then 'dhclient eth0', the interface does not get an IP address. What command can be used to ensure the DHCP client process is fully released and restarted?

Trap 1: dhclient -s 10.0.0.1 eth0

This option specifies a DHCP server to use via `-s`, but does not release the current lease or restart the client. It cannot ensure a fresh release and restart.

Trap 2: dhclient -r eth0 && dhclient -v eth0

This repeats the same commands the administrator already tried (`-r` then `-v`), which only releases the lease but may leave the dhclient daemon running and holding onto state, failing to guarantee a full restart.

Trap 3: dhclient -x eth0 && dhclient eth0

While `-x` releases the lease and stops the dhclient daemon for that interface, it may not terminate all dhclient processes (e.g., if multiple interfaces are managed). This can leave residual state, making it less reliable than `killall` for a thorough restart.

A
dhclient -s 10.0.0.1 eth0
Why it fails: This option specifies a DHCP server to use via `-s`, but does not release the current lease or restart the client. It cannot ensure a fresh release and restart.
B
dhclient -r eth0 && dhclient -v eth0
Why it fails: This repeats the same commands the administrator already tried (`-r` then `-v`), which only releases the lease but may leave the dhclient daemon running and holding onto state, failing to guarantee a full restart.
C
killall dhclient && dhclient eth0
Correct. `killall dhclient` forcefully terminates all dhclient processes, ensuring no stale daemon remains. Then `dhclient eth0` starts a fresh client, completing a full release and restart cycle.
D
dhclient -x eth0 && dhclient eth0
Why it fails: While `-x` releases the lease and stops the dhclient daemon for that interface, it may not terminate all dhclient processes (e.g., if multiple interfaces are managed). This can leave residual state, making it less reliable than `killall` for a thorough restart.