Knowledge + Practice

CCNA Networking Questions

75 of 113 questions · Page 1/2 · Networking · Answers revealed

Practice these questions Domain overview All questions

1

MCQmedium

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?

A.net.ipv4.conf.all.forwarding

B.net.core.forwarding

C.net.ipv4.tcp_forwarding

D.net.ipv4.ip_forward

AnswerD

This is the standard sysctl parameter to enable IP forwarding.

Why this answer

Option D is correct because `net.ipv4.ip_forward` is the primary sysctl parameter that controls IP forwarding at the kernel level on Linux systems. Setting it to 1 enables the kernel to forward packets between network interfaces, which is essential for the server to act as a router between the 172.16.0.0/24 and 10.0.0.0/24 subnets.

Exam trap

The trap here is that candidates may confuse the valid `net.ipv4.ip_forward` with the similarly named but non-existent `net.ipv4.conf.all.forwarding`, or mistakenly think that forwarding is controlled at the transport layer via a TCP-specific parameter.

How to eliminate wrong answers

Option A is wrong because `net.ipv4.conf.all.forwarding` is not a valid sysctl parameter; the correct parameter for per-interface or all-interface forwarding control is `net.ipv4.conf.all.forwarding` does not exist, and the proper parameter for enabling forwarding on all interfaces is `net.ipv4.conf.all.forwarding` is actually a valid parameter but it is an alias for `net.ipv4.ip_forward` in some kernel versions, however the standard and most commonly tested parameter is `net.ipv4.ip_forward`. Option B is wrong because `net.core.forwarding` is not a valid sysctl parameter; the `net.core` namespace deals with core networking parameters like `net.core.rmem_default` and `net.core.wmem_max`, not IP forwarding. Option C is wrong because `net.ipv4.tcp_forwarding` is not a valid sysctl parameter; TCP forwarding is not a kernel-level concept, and IP forwarding operates at the network layer (Layer 3), not the transport layer (Layer 4).

Practice this question →

2

MCQeasy

Refer to the exhibit. The output of 'iptables -L -n' shows the INPUT chain rules. What will happen to an SSH connection attempt from 10.0.0.1?

A.The connection will be accepted

B.The connection will be dropped by the first rule

C.The connection will be rate-limited

D.The connection will be dropped by the default policy

AnswerA

The ACCEPT rule matches the source 10.0.0.0/8, so the connection is allowed.

Why this answer

The exhibit shows iptables rules for the INPUT chain. The first rule explicitly accepts SSH (port 22) from 10.0.0.1, so the connection attempt from that source IP will be accepted. Since iptables processes rules sequentially and this rule matches, the packet is accepted immediately without checking subsequent rules or the default policy.

Exam trap

Linux Foundation often tests the sequential nature of iptables rule processing, where candidates mistakenly think the default policy applies before all rules are checked, or that a later rule could override an earlier match.

How to eliminate wrong answers

Option B is wrong because the first rule matches SSH from 10.0.0.1 and has a target of ACCEPT, not DROP, so the connection is accepted, not dropped. Option C is wrong because there is no rate-limiting rule (e.g., using the 'limit' module) in the exhibited chain; rate-limiting would require explicit rules with '--limit' or similar. Option D is wrong because the default policy only applies if no rule matches; here, the first rule matches and accepts the connection, so the default policy is never reached.

Practice this question →

3

MCQmedium

A financial firm requires all internal SSH connections to be encrypted with at least 256-bit ciphers. An administrator is configuring the SSH server. Which configuration line should be added to /etc/ssh/sshd_config?

A.MACs hmac-sha2-256

B.KexAlgorithms diffie-hellman-group-exchange-sha256

C.Ciphers aes256-ctr

D.HostKeyAlgorithms ssh-rsa

AnswerC

Specifies allowed ciphers; aes256-ctr is 256-bit.

Why this answer

Option C is correct because the Ciphers directive in sshd_config explicitly controls the symmetric encryption algorithms used to encrypt SSH session data. The cipher aes256-ctr provides 256-bit encryption, meeting the firm's requirement for at least 256-bit ciphers. Other directives like MACs, KexAlgorithms, or HostKeyAlgorithms do not directly set the encryption cipher strength.

Exam trap

The trap here is that candidates confuse MACs, KexAlgorithms, or HostKeyAlgorithms with encryption ciphers, assuming any directive with '256' or 'sha256' implies 256-bit encryption, when only the Ciphers directive controls the symmetric encryption algorithm strength.

How to eliminate wrong answers

Option A is wrong because MACs (Message Authentication Codes) specify integrity-check algorithms like hmac-sha2-256, not encryption ciphers; they ensure data authenticity, not confidentiality. Option B is wrong because KexAlgorithms define key exchange methods (e.g., diffie-hellman-group-exchange-sha256) that negotiate session keys, but they do not determine the symmetric cipher used for encrypting the actual data stream. Option D is wrong because HostKeyAlgorithms specify which host key types (e.g., ssh-rsa) are accepted for server authentication, not the encryption cipher for the session.

Practice this question →

4

MCQhard

Which nmcli command creates a VLAN interface with tag 10 on device eth0?

A.nmcli connection add type vlan con-name vlan10 ifname eth0 id 10

B.nmcli connection add type vlan con-name vlan10 dev eth0 id 10

C.nmcli device add vlan con-name vlan10 dev eth0 id 10

D.nmcli connection add type vlan con-name vlan10 ifname eth0.10

AnswerB

This is the correct syntax to create a VLAN connection on eth0 with ID 10.

Why this answer

Option B is correct because the `nmcli connection add` command with `type vlan` requires the `dev` option to specify the parent interface (eth0) and the `id` option to set the VLAN tag (10). The `con-name` assigns a name to the connection profile, and the resulting interface will be named automatically (e.g., eth0.10) unless overridden by `ifname`. This creates a VLAN interface that tags frames with ID 10 on the parent device eth0.

Exam trap

The trap here is confusing `ifname` (which sets the resulting interface name) with `dev` (which specifies the parent device), leading candidates to incorrectly use `ifname eth0` instead of `dev eth0` when the intent is to attach the VLAN to the physical interface.

How to eliminate wrong answers

Option A is wrong because it uses `ifname eth0` instead of `dev eth0`; `ifname` specifies the resulting interface name, not the parent device, so this would attempt to create a VLAN interface named eth0 (which conflicts with the existing physical interface) rather than attaching it to eth0. Option C is wrong because `nmcli device add` is not a valid subcommand; the correct syntax uses `nmcli connection add` to create a connection profile for the VLAN. Option D is wrong because `ifname eth0.10` directly sets the interface name to eth0.10 but omits the `id 10` parameter; while the name implies VLAN 10, the command does not explicitly set the VLAN tag, and the `id` option is required for proper 802.1Q tagging.

Practice this question →

5

MCQeasy

Which legacy command can still be used to view the IPv4 routing table on a modern Linux system?

A.ip route show

B.route -n

C.arp -a

D.netstat -r

AnswerD

netstat -r is a legacy command that still works on most systems.

Why this answer

Option D is correct because `netstat -r` is a legacy command that reads the kernel routing table from `/proc/net/route` and displays it in a human-readable format. It remains available on modern Linux systems for backward compatibility, even though its use is discouraged in favor of `ip route`. The `-r` flag specifically instructs `netstat` to show the routing table.

Exam trap

The trap here is that candidates often confuse 'legacy command' with 'modern command' and pick `ip route show` (Option A) because it is the current standard, but the question explicitly asks for a legacy command that still works.

How to eliminate wrong answers

Option A is wrong because `ip route show` is the modern, recommended command from the `iproute2` suite, not a legacy command. Option B is wrong because `route -n` is itself a legacy command (from the `net-tools` package) and is not the correct answer here; the question asks for a legacy command that can still be used, and `route -n` is also legacy but the correct answer is `netstat -r`. Option C is wrong because `arp -a` displays the ARP cache (mapping IP addresses to MAC addresses), not the IPv4 routing table.

Practice this question →

6

MCQhard

You are a senior Linux administrator for a large data center. A junior admin reports that a newly deployed application server (192.168.100.50/24, default gateway 192.168.100.1) cannot communicate with a legacy server (192.168.200.50/24, default gateway 192.168.200.1). The two subnets are connected via a router (192.168.100.1 and 192.168.200.1). From the app server, you can ping the legacy server's IP successfully. However, when you try to establish an SSH session from the app server to the legacy server, it times out. You check the legacy server's firewall (ufw) and find that it allows SSH (port 22) from the entire 192.168.0.0/16 range. You also confirm that the SSH daemon is running and listening on 0.0.0.0:22. What is the most likely cause?

A.The router is dropping TCP packets due to ACLs.

B.The legacy server's firewall is not allowing SSH; the rule might be misconfigured.

C.The app server's firewall (ufw) is blocking incoming SSH responses.

D.The legacy server's SSH service is not listening on the correct interface.

AnswerC

Since SSH is a TCP connection, the app server sends SYN, and the legacy server replies with SYN-ACK. If the app server's ufw does not allow related/established connections or has a rule that blocks new incoming connections, the SYN-ACK will be dropped, causing a timeout. This is a common misconfiguration.

Why this answer

The app server can ping the legacy server successfully, which confirms that ICMP traffic (Layer 3) passes through the router and that the legacy server's firewall allows ICMP. However, SSH (TCP port 22) fails because the app server's own firewall (ufw) is blocking the incoming SSH response packets (SYN-ACK) from the legacy server. Since the SSH client initiates the connection from the app server, the response packets must be allowed by the app server's firewall; if ufw on the app server blocks established or related incoming traffic, the TCP handshake cannot complete, resulting in a timeout.

Exam trap

The trap here is that candidates assume the problem must be on the target server (firewall or SSH service) because the symptom is a timeout, but the ping success proves Layer 3 connectivity, shifting the issue to the client-side firewall blocking the TCP handshake response.

How to eliminate wrong answers

Option A is wrong because the app server can ping the legacy server successfully, which proves that the router is forwarding packets between subnets and that no ACL is blocking ICMP; if the router were dropping TCP packets due to ACLs, the ping would also likely fail or at least the router's behavior would be inconsistent. Option B is wrong because the legacy server's firewall explicitly allows SSH from the entire 192.168.0.0/16 range, which includes the app server's IP (192.168.100.50), and the SSH daemon is confirmed running and listening on 0.0.0.0:22, so the firewall is not the issue. Option D is wrong because the SSH daemon is listening on 0.0.0.0:22, which means it accepts connections on all interfaces, including the one with IP 192.168.200.50; there is no interface-specific misconfiguration.

Practice this question →

7

MCQeasy

A system administrator needs to permanently configure a network interface named ens33 with a static IPv4 address of 192.168.1.100/24 and a default gateway of 192.168.1.1 on a system using NetworkManager. Which command should the administrator use to achieve this?

A.nmcli connection modify 'ens33' ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.method manual

B.ip addr add 192.168.1.100/24 dev ens33

C.ifconfig ens33 192.168.1.100 netmask 255.255.255.0 up

D.route add default gw 192.168.1.1 ens33

AnswerA

This permanently configures the static IP and gateway using NetworkManager.

Why this answer

Option A is correct because it uses the `nmcli` command to modify the NetworkManager connection profile for interface ens33, setting a static IPv4 address with CIDR notation and a default gateway, and explicitly setting the method to 'manual' to ensure the configuration persists across reboots. NetworkManager is the default network service on modern Linux distributions, and `nmcli` is the proper tool for permanent configuration changes.

Exam trap

The trap here is that candidates often choose temporary commands like `ip addr add` or `ifconfig` because they work immediately, but the LFCS exam specifically tests the ability to make permanent changes using the system's network management service (NetworkManager) rather than transient runtime commands.

How to eliminate wrong answers

Option B is wrong because `ip addr add` only adds an IP address temporarily to the interface; it does not persist after a reboot and does not configure a default gateway or set the addressing method to manual. Option C is wrong because `ifconfig` is deprecated and does not provide persistent configuration; any changes made with it are lost on reboot, and it does not interact with NetworkManager. Option D is wrong because `route add default gw` only adds a temporary default route; it does not set a static IP address, does not persist across reboots, and does not use NetworkManager's configuration system.

Practice this question →

8

MCQeasy

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?

A.dhclient -s 10.0.0.1 eth0

B.dhclient -r eth0 && dhclient -v eth0

C.killall dhclient && dhclient eth0

D.dhclient -x eth0 && dhclient eth0

AnswerD

'-x' gracefully stops DHCP client, releasing the lease.

Why this answer

Option D is correct because `dhclient -x eth0` explicitly releases the current lease and terminates the DHCP client process for that interface, ensuring a clean state before restarting with `dhclient eth0`. This avoids issues where a stale process or lease file prevents a fresh DHCP handshake, which can occur with `-r` alone if the client daemon remains running.

Exam trap

The trap here is that candidates assume `-r` (release) followed by a new dhclient invocation is sufficient, but they overlook that the dhclient daemon may still be running and holding onto the old lease, whereas `-x` explicitly terminates the process and clears the lease state.

How to eliminate wrong answers

Option A is wrong because `dhclient -s 10.0.0.1 eth0` forces the client to send requests only to a specific DHCP server IP, which does not release or restart the client process; it merely overrides server discovery. Option B is wrong because `dhclient -r eth0` only releases the current lease but does not terminate the dhclient process, so the subsequent `dhclient eth0` may fail if the daemon is still holding state or a stale lease file. Option C is wrong because `killall dhclient` kills all dhclient processes indiscriminately, which can disrupt other interfaces or leave the system in an inconsistent state; it is not the proper way to release a lease and restart a specific interface.

Practice this question →

9

MCQhard

A systemd-networkd managed interface enp1s0 needs to be configured with a static IP address 192.168.1.100/24 and a default gateway via 192.168.1.1. Which .network file configuration is correct?

A.[Match] Interface=enp1s0 [Network] StaticIP=192.168.1.100/24 Gateway=192.168.1.1

B.[Link] Name=enp1s0 [Network] IPAddress=192.168.1.100/24 Gateway=192.168.1.1

C.[Match] Name=enp1s0 [Network] Address=192.168.1.100/24 Gateway=192.168.1.1

D.[Match] Name=enp1s0 [Network] Address=192.168.1.100/24 DefaultGateway=192.168.1.1

AnswerC

Correct syntax for static IP and gateway.

Why this answer

Option C is correct because systemd-networkd uses the `[Match]` section with `Name=` to match the interface, and the `[Network]` section with `Address=` to assign a static IP address and `Gateway=` to set the default gateway. The syntax `Address=192.168.1.100/24` is the proper directive for defining a static IP address in a .network file, and `Gateway=192.168.1.1` correctly specifies the default gateway.

Exam trap

The trap here is that candidates confuse the `[Match]` section key `Name=` with `Interface=` (which is used in other tools like ifcfg files) and mistakenly use `DefaultGateway=` (a valid directive in some network configuration systems like Netplan) instead of the correct `Gateway=` in systemd-networkd.

How to eliminate wrong answers

Option A is wrong because it uses `Interface=` in the `[Match]` section (the correct key is `Name=`) and `StaticIP=` in the `[Network]` section (the correct key is `Address=`). Option B is wrong because it uses `[Link]` instead of `[Match]` to identify the interface, and `IPAddress=` is not a valid directive in the `[Network]` section (the correct directive is `Address=`). Option D is wrong because it uses `DefaultGateway=` instead of the correct `Gateway=` directive for setting the default gateway in systemd-networkd.

Practice this question →

10

MCQhard

You are a systems administrator for a company that runs a critical application on a Linux server with two network interfaces: eth0 (public IP 203.0.113.10/24, gateway 203.0.113.1) and eth1 (private IP 10.0.1.10/24, no gateway). The server must be accessible via SSH (port 22) from the internet, but only from a specific management subnet 198.51.100.0/24. Additionally, the server should be able to access the internet for package updates, but no other inbound traffic from the internet is allowed. The local firewall is iptables. After implementing rules, you find that the server cannot reach the internet (e.g., ping 8.8.8.8 fails), but SSH from the management subnet works. What is the most likely cause?

A.The server's DNS resolver is not configured

B.The SSH rule is misconfigured and accidentally blocks all traffic

C.The iptables rules do not include a rule to allow established and related connections

D.The default policy on the INPUT chain is DROP

AnswerC

Without a state tracking rule, return traffic for outbound connections is blocked, breaking internet access.

Why this answer

Option C is correct because iptables is stateful: by default, the INPUT chain processes only the first packet of a connection. Without a rule allowing established and related connections (e.g., `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`), return traffic from the server's outbound internet requests (e.g., ping to 8.8.8.8) is blocked by the INPUT chain, causing the failure. SSH from the management subnet works because the initial SYN packet is allowed, but the server's outbound traffic fails because the response packets are not recognized as part of an allowed flow.

Exam trap

The trap here is that candidates assume a default DROP policy on INPUT is the root cause, but they overlook that stateful filtering requires an explicit rule for return traffic, which is a classic LFCS and iptables nuance.

How to eliminate wrong answers

Option A is wrong because DNS resolution is irrelevant to a direct ping to 8.8.8.8 (an IP address), and the question states the server cannot reach the internet at all, not just resolve names. Option B is wrong because if the SSH rule were misconfigured and accidentally blocked all traffic, SSH from the management subnet would also fail, but the question confirms SSH works. Option D is wrong because a default DROP policy on the INPUT chain would still allow SSH from the management subnet if an explicit ACCEPT rule exists for that traffic; the issue is specifically that outbound-initiated traffic's return packets are not matched by any rule, not the default policy itself.

Practice this question →

11

MCQmedium

Refer to the exhibit. A server is configured with two network interfaces. A user on the 192.168.2.0/24 network reports that they cannot reach the server at IP 10.0.0.5. What is the most likely cause based on the routing table?

A.There is no route on the server to the 192.168.2.0/24 network.

B.The default gateway is misconfigured; it should be 192.168.1.1.

C.The server's IP address 10.0.0.5 is not in the same subnet as the default gateway.

D.The firewall on eth0 is blocking incoming traffic.

AnswerA

Without a return route, the server cannot send replies to the 192.168.2.0/24 network.

Why this answer

The routing table on the server does not contain a route for the 192.168.2.0/24 network. When the user on that network sends traffic to 10.0.0.5, the server can receive it, but any reply traffic from the server to the 192.168.2.0/24 source address will be dropped because the server has no matching route. Without a route to the source network, the server cannot send return packets, making communication fail.

Exam trap

Linux Foundation often tests the misconception that a missing route only affects outbound traffic, but the trap here is that the server can receive packets from the 192.168.2.0/24 network but cannot reply, causing a one-way communication failure that users perceive as 'cannot reach the server'.

How to eliminate wrong answers

Option B is wrong because the default gateway is correctly set to 192.168.1.1, which is on the same subnet as the server's eth0 IP (10.0.0.5/24); changing it to 192.168.1.1 would be redundant or incorrect as that address is already the gateway. Option C is wrong because the server's IP 10.0.0.5 and the default gateway 192.168.1.1 are both in the 10.0.0.0/24 subnet (assuming a /24 netmask), so they are in the same subnet; the issue is not subnet mismatch. Option D is wrong because the problem is a routing issue, not a firewall one; even if the firewall on eth0 were blocking traffic, the user's inability to reach the server would typically manifest as a timeout or connection refused, but the core cause here is the missing return route.

Practice this question →

12

MCQeasy

The command 'ss -tuln' shows port 80 is listening on a server, but a remote client cannot connect via HTTP. What is the most likely cause?

A.The HTTP service is not running

B.The client has a misconfigured default gateway

C.The server's /etc/hosts file is misconfigured

D.A firewall is blocking incoming TCP port 80

AnswerD

Firewalls commonly block ports; even if the service listens, external access may be blocked.

Why this answer

The `ss -tuln` command shows that port 80 is in the LISTEN state, which means the HTTP service (e.g., Apache or Nginx) is bound to the port and ready to accept connections. Since the server is listening but the remote client cannot connect, the most likely cause is a firewall (such as iptables, nftables, or a cloud security group) that is blocking incoming TCP SYN packets destined for port 80, preventing the three-way handshake from completing.

Exam trap

The trap here is that candidates see 'listening' on port 80 and assume the service is fully accessible, forgetting that a firewall can silently drop incoming packets even when the service is up and listening.

How to eliminate wrong answers

Option A is wrong because if the HTTP service were not running, `ss -tuln` would not show port 80 in the LISTEN state; the command output explicitly confirms the service is running. Option B is wrong because a misconfigured default gateway on the client would prevent the client from reaching any remote network, not just port 80 on this specific server; the client can likely reach other services or the server itself via other ports. Option C is wrong because the `/etc/hosts` file is used for local hostname resolution and does not affect network connectivity at the transport layer; a misconfigured hosts file would cause a DNS-like resolution failure, not a TCP connection timeout or reset.

Practice this question →

13

MCQeasy

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?

A.net.ifnames=0

B.ifrename=enable

C.net.ifnames=1

D.biosdevname=0

AnswerA

Enables predictable naming based on firmware topology.

Why this answer

Option A is correct because setting `net.ifnames=0` in GRUB disables the predictable network interface naming scheme (based on firmware/BIOS topology) and reverts to the traditional kernel enumeration (e.g., eth0, eth1). This is the standard kernel parameter used to control systemd's udev naming policy, ensuring names like enp0s3 or ens33 are replaced with legacy names.

Exam trap

The trap here is that candidates confuse `net.ifnames=0` with enabling predictable naming, when in fact it disables it, and they may also mistake `biosdevname=0` as the correct parameter for enabling topology-based names, whereas biosdevname is a separate, older scheme from Dell.

How to eliminate wrong answers

Option B is wrong because `ifrename=enable` is not a valid GRUB kernel parameter; ifrename is a separate tool (part of the wireless-tools package) for renaming interfaces, not a kernel boot parameter. Option C is wrong because `net.ifnames=1` enables predictable naming (the default behavior), which is the opposite of what the question asks (the admin wants predictable names based on topology, not kernel enumeration). Option D is wrong because `biosdevname=0` disables the biosdevname naming scheme (which uses BIOS-provided names like em1 or p1p1), but the question specifically asks for predictable names based on firmware/BIOS topology, and biosdevname is a separate mechanism from systemd's predictable naming; setting it to 0 would disable that scheme, not enable the desired behavior.

Practice this question →

14

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

First check DNS config, then test resolution, then connectivity, then firewall.

Practice this question →

15

MCQhard

An administrator is configuring network bonding on a RHEL 7 server with two physical NICs (eth0 and eth1) to provide redundancy. The bond interface bond0 is configured with mode 1 (active-backup). The administrator uses the following configuration in /etc/sysconfig/network-scripts/ifcfg-bond0: BONDING_OPTS="miimon=100 mode=1". The slave interfaces are configured with MASTER=bond0 and SLAVE=yes. After restarting the network service, the bond interface comes up with the active link on eth0. To test failover, the administrator disconnects the cable from eth0. The bond interface does not fail over to eth1. The administrator checks /proc/net/bonding/bond0 and sees that both slaves are listed but eth0 is still marked as active even though the cable is disconnected. What is the most likely reason for the failover failure?

A.Add arp_interval=1000 and arp_ip_target=192.168.1.1 to BONDING_OPTS.

B.Change bonding mode to mode 4 (802.3ad load balancing).

C.Remove one slave and re-add it to force a failover.

D.Check /var/log/messages for bonding driver errors.

AnswerA

ARP monitoring can detect link failures when MII monitoring fails.

Why this answer

Option A is correct because in mode 1 (active-backup), the bonding driver uses MII monitoring (miimon) to detect link state changes via the physical carrier signal. However, some switches or NICs do not properly report carrier loss when a cable is disconnected, causing miimon to miss the failure. Adding arp_interval and arp_ip_target forces the bonding driver to use ARP-based monitoring, which actively probes a target IP to verify link availability, thus detecting failures that miimon cannot see.

Exam trap

The trap here is that candidates assume miimon always detects physical disconnection, but the exam tests the understanding that carrier detection can fail, requiring ARP monitoring as a fallback for reliable failover.

How to eliminate wrong answers

Option B is wrong because mode 4 (802.3ad) requires switch support for LACP and is designed for load balancing, not redundancy; it does not solve the miimon detection issue. Option C is wrong because removing and re-adding a slave does not address the root cause—the driver still relies on miimon, which is failing to detect the link loss. Option D is wrong because checking logs for bonding driver errors is a diagnostic step, not a configuration fix; the issue is a missing monitoring mechanism, not a driver error.

Practice this question →

16

MCQeasy

A system administrator needs to ensure that a Linux server can communicate with other hosts on the same subnet. Which command should be used to verify the IP address and netmask configuration?

A.netstat -rn

B.route -n

C.ifconfig

D.ip addr show

AnswerD

ip addr show is the modern command to display IP addresses and netmasks.

Why this answer

The `ip addr show` command is the modern, recommended tool in Linux for viewing IP addresses and netmasks (prefix lengths) assigned to network interfaces. It directly displays the configuration needed to verify subnet communication, unlike legacy tools that may not show the netmask clearly or mix routing information.

Exam trap

The trap here is that candidates often choose `ifconfig` out of habit, not realizing it is deprecated and may be missing on minimal installations, while `ip addr show` is the current standard and always available in modern Linux distributions.

How to eliminate wrong answers

Option A is wrong because `netstat -rn` displays the kernel routing table, not IP address or netmask configuration. Option B is wrong because `route -n` also shows the routing table, not interface IP/netmask details. Option C is wrong because `ifconfig` is deprecated and may not be installed by default on modern distributions; it can show IP and netmask but is less reliable and lacks the structured output of `ip`.

Practice this question →

17

MCQeasy

To permanently disable IPv6 on a network interface, which configuration should be added to /etc/sysctl.conf?

A.net.ipv6.conf.all.disable=1

B.ipv6.disable=1

C.net.ipv6.conf.eth0.disable_ipv6 = 1

D.net.ipv6.conf.all.disable_ipv6 = 1

AnswerD

This disables IPv6 on all interfaces system-wide.

Why this answer

Option D is correct because the sysctl parameter `net.ipv6.conf.all.disable_ipv6 = 1` is the proper kernel interface to globally disable IPv6 on all network interfaces. This setting is applied via the sysctl system, which reads `/etc/sysctl.conf` at boot to configure kernel parameters. The key must use the exact `disable_ipv6` suffix (not `disable`) and the `all` scope ensures the setting applies to every interface, including future ones.

Exam trap

The trap here is that candidates confuse the sysctl parameter name `disable_ipv6` with the simpler `disable` (Option A) or mix up sysctl settings with kernel boot parameters like `ipv6.disable=1` (Option B), while also overlooking that `all` is the correct scope for a permanent, interface-agnostic configuration in `/etc/sysctl.conf`.

How to eliminate wrong answers

Option A is wrong because `net.ipv6.conf.all.disable=1` uses an incorrect parameter name; the correct sysctl key ends with `disable_ipv6`, not `disable`. Option B is wrong because `ipv6.disable=1` is a kernel boot parameter (passed via GRUB command line), not a sysctl setting that belongs in `/etc/sysctl.conf`. Option C is wrong because while `net.ipv6.conf.eth0.disable_ipv6 = 1` is a valid sysctl key, it only disables IPv6 on the specific interface `eth0`, not permanently across all interfaces as the question requires; the question asks for a configuration to disable IPv6 on 'a network interface' but the context of `/etc/sysctl.conf` and the 'permanently' keyword implies a global or interface-agnostic setting, and the correct answer uses `all` to cover all interfaces.

Practice this question →

18

MCQhard

Which iptables command allows incoming SSH traffic only from the 10.0.0.0/8 network?

A.iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT

B.Edited: Option A: only ACCEPT, Option B: default DROP with ACCEPT (but missing state tracking for return traffic), Option C: ACCEPT from network then DROP others, Option D: completely wrong command.

Why this answer

Option D is correct because it adds a rule to accept SSH from the source network, then sets the default policy to DROP (or assumes a subsequent DROP rule). Option A is incorrect because it does not block other sources. Option B is incorrect because order matters; default policy DROP without an ACCEPT rule blocks everything.

Option C is incorrect because it accepts all SSH regardless of source.

Practice this question →

19

MCQhard

A technician configured a new network interface eth1 on a CentOS 7 server but the interface does not obtain an IPv4 address via DHCP. Which of the following is the most likely cause?

A.The interface MTU is set too high

B.SELinux is blocking dhclient

C.NetworkManager is not managing the interface (NM_CONTROLLED=no)

D.Firewalld is blocking DHCP ports (67/68)

AnswerC

When NM_CONTROLLED=no, NetworkManager ignores the interface, so DHCP is not attempted.

Why this answer

Option C is correct because when NM_CONTROLLED=no is set in the interface configuration file (/etc/sysconfig/network-scripts/ifcfg-eth1), NetworkManager will not manage that interface. Since dhclient is typically invoked by NetworkManager (or by legacy network scripts only if NM_CONTROLLED=yes), the interface will not automatically obtain an IPv4 address via DHCP. On CentOS 7, NetworkManager is the default network service, and disabling its control prevents DHCP client activation.

Exam trap

The trap here is that candidates often assume firewall or SELinux is the culprit for DHCP failures, but the most common cause on CentOS 7 is the NM_CONTROLLED=no setting, which disables NetworkManager's DHCP client management.

How to eliminate wrong answers

Option A is wrong because MTU (Maximum Transmission Unit) being set too high does not prevent DHCP from obtaining an address; DHCP uses Layer 2 broadcast frames and Layer 3 UDP packets, and MTU issues typically cause fragmentation or packet loss, not a complete failure to acquire an IP. Option B is wrong because SELinux does not block dhclient by default; dhclient runs in the dhcpc_t domain, and SELinux policies allow it to send and receive DHCP packets on ports 67/68. Option D is wrong because firewalld blocking DHCP ports (67/68) would prevent DHCP discovery and offer packets from reaching the client, but the question states the interface does not obtain an IPv4 address via DHCP—firewalld could cause this, but it is less likely than the direct configuration issue of NM_CONTROLLED=no, which is a common misconfiguration on CentOS 7.

Practice this question →

20

Matchingmedium

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

Why these pairings

These are powerful text processing and file search commands.

Practice this question →

21

MCQhard

A Linux server is unable to resolve the hostname 'app.internal.example.com' but can resolve other names. The /etc/nsswitch.conf file contains: hosts: files mdns4_minimal [NOTFOUND=return] dns. The /etc/hosts file does not list the hostname. Which configuration change would most likely resolve the issue?

A.Change the hosts line to: hosts: dns files mdns4_minimal

B.Configure /etc/resolv.conf to use a different DNS server

C.Remove the mdns4_minimal entry or change it to 'mdns4' without the NOTFOUND=return

D.Add the hostname to the local multicast DNS configuration

AnswerC

Removing the return policy allows fallback to DNS.

Why this answer

The issue is that mdns4_minimal with [NOTFOUND=return] causes the resolver to stop after a failed mDNS query, preventing it from falling back to DNS. Since the hostname is not in /etc/hosts and not reachable via mDNS, the resolver returns 'not found' immediately without querying DNS. Removing the mdns4_minimal entry or changing it to 'mdns4' (without the NOTFOUND=return) allows the resolver to proceed to DNS if mDNS fails.

Exam trap

The trap here is that candidates assume the issue is with DNS configuration or order, but the real problem is the [NOTFOUND=return] action on mdns4_minimal, which prematurely terminates the resolution chain for non-.local hostnames.

How to eliminate wrong answers

Option A is wrong because changing the order to 'dns files mdns4_minimal' would still leave the mdns4_minimal with [NOTFOUND=return] in place, so if mDNS fails, the resolver still returns immediately without consulting DNS. Option B is wrong because the server can resolve other names, indicating that the DNS server in /etc/resolv.conf is working correctly; the problem is specific to the resolution order and fallback behavior, not the DNS server itself. Option D is wrong because adding the hostname to multicast DNS configuration would only help if the hostname is served via mDNS on the local link, but the hostname 'app.internal.example.com' is likely a standard DNS name, not a .local mDNS name, so mDNS would not resolve it anyway.

Practice this question →

22

Multi-Selectmedium

A server with two network interfaces needs to forward IP packets between them. Which two steps are required to enable IP forwarding? (Choose two.)

Select 2 answers

A.Run systemctl restart network

B.Run sysctl -p

C.Set net.ipv4.ip_forward=1 in /etc/sysctl.conf

D.Add a route to the second interface

E.Set net.ipv4.conf.all.forwarding=1

AnswersB, C

This applies the sysctl settings from /etc/sysctl.conf.

Why this answer

Option B is correct because `sysctl -p` reloads kernel parameters from `/etc/sysctl.conf`, making the `net.ipv4.ip_forward=1` setting active without a reboot. Option C is correct because setting `net.ipv4.ip_forward=1` in `/etc/sysctl.conf` enables IP forwarding persistently across reboots. Together, these two steps ensure the kernel forwards IP packets between network interfaces.

Exam trap

The trap here is that candidates often confuse enabling IP forwarding with adding routes or restarting network services, but the core requirement is a kernel parameter change, not a routing table or service restart.

Practice this question →

23

MCQmedium

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

A.The packet is sent via eth1.

B.The packet is sent to 192.168.1.1 via eth0.

C.The packet is sent via default route.

D.The packet is dropped because there is no subnet matching 10.1.1.1.

AnswerB

The 10.0.0.0/8 route matches and points to that gateway.

Why this answer

The routing table shows a specific route for the 10.0.0.0/8 network via gateway 192.168.1.1 on eth0. Since 10.1.1.1 falls within this subnet, the packet is forwarded to 192.168.1.1 via eth0, not through the default route or any other interface.

Exam trap

The trap here is that candidates often assume a destination like 10.1.1.1 has no matching route and default to the default gateway, overlooking the presence of a classful /8 route that explicitly covers it.

How to eliminate wrong answers

Option A is wrong because eth1 is associated with the 192.168.2.0/24 network, which does not include 10.1.1.1. Option C is wrong because the default route is only used when no more specific route matches the destination; here, the 10.0.0.0/8 route is a more specific match. Option D is wrong because the routing table explicitly contains a route for 10.0.0.0/8, which covers 10.1.1.1, so the packet is not dropped.

Practice this question →

24

Multi-Selecteasy

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

Select 2 answers

A.ss -r

B.route -n

C.ip route show

D.netstat -r

E.ifconfig

AnswersB, C

route -n displays the routing table.

Why this answer

The `route -n` command displays the kernel IP routing table with numeric addresses, avoiding DNS resolution for faster output. The `ip route show` command is part of the modern `iproute2` suite and shows the same routing table with more detail and flexibility. Both are standard tools for viewing the current routing table on Linux.

Exam trap

The trap here is that `netstat -r` is a valid command for displaying the routing table, but it is deprecated and not considered a primary tool in the LFCS exam, which emphasizes the modern `ip` command over legacy tools.

Practice this question →

25

MCQhard

A server has multiple IP aliases on eth0. Remote hosts cannot reach the secondary IP addresses. What should the administrator check?

A.The server's routing table includes routes for the secondary IPs' subnets.

B.The ARP flux settings are configured correctly.

C.The interface is set to NOARP.

D.The secondary IPs are in the same subnet as the primary.

AnswerB

Incorrect arp_ignore/arp_announce can cause secondary IPs to be unreachable.

Why this answer

When multiple IP aliases are configured on a single Ethernet interface, the kernel may respond to ARP requests inconsistently, a behavior known as ARP flux. This causes remote hosts to receive conflicting MAC addresses for the secondary IPs, preventing connectivity. Correctly configuring ARP flux settings (e.g., using `arp_ignore=1` and `arp_announce=2` via sysctl) ensures the kernel responds only from the appropriate IP and advertises the correct MAC.

Exam trap

The trap here is that candidates assume secondary IPs must be in the same subnet as the primary (Option D) or that routing entries are needed (Option A), when the actual cause is the kernel's default ARP behavior, which is controlled by sysctl settings.

How to eliminate wrong answers

Option A is wrong because the routing table does not need routes for the secondary IPs' subnets; the secondary IPs are local to the interface, and the kernel handles them via local routing automatically. Option C is wrong because setting the interface to NOARP would disable ARP entirely, preventing any IP communication on that interface, not just secondary IPs. Option D is wrong because secondary IPs can be in a different subnet from the primary; the issue is ARP flux, not subnet matching.

Practice this question →

26

MCQhard

A server uses firewalld. Which command permanently allows HTTP traffic?

A.firewall-cmd --add-service=http

B.firewall-cmd --add-service=http --permanent

C.firewall-cmd --add-port=80/tcp

D.systemctl reload firewalld

AnswerB

Adds the http service permanently to the default zone.

Why this answer

Option B is correct because the `--permanent` flag is required to make the rule persist across reboots when using `firewall-cmd`. Without it, the rule is only added to the runtime configuration and will be lost after a firewall reload or system restart. The `--add-service=http` parameter uses the predefined service definition for HTTP (port 80/tcp), which is the proper way to allow HTTP traffic in firewalld.

Exam trap

The trap here is that candidates often assume `firewall-cmd --add-service=http` alone is sufficient, forgetting that without `--permanent`, the rule is ephemeral and will be lost on reload or reboot.

How to eliminate wrong answers

Option A is wrong because it omits the `--permanent` flag, so the rule is applied only to the runtime configuration and will not survive a firewall reload or reboot. Option C is wrong because `--add-port=80/tcp` adds a direct port rule rather than using the predefined HTTP service; while it may work functionally, it bypasses firewalld's service abstraction and is not the standard method for allowing HTTP traffic. Option D is wrong because `systemctl reload firewalld` reloads the firewall configuration but does not add any rule; it would only apply permanent rules that were already added, not create a new rule.

Practice this question →

27

MCQhard

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?

A.There is a mismatch in MTU size.

B.The destination host is down.

C.A firewall is blocking the packets.

D.There is a routing loop or the TTL is too low.

AnswerD

'Time exceeded' indicates TTL expired, common in loops.

Why this answer

The 'ICMP time exceeded in-transit' message indicates that a packet's TTL (Time to Live) has reached zero before reaching its destination. This is most commonly caused by a routing loop, where packets circulate endlessly between routers, or by an initial TTL value that is too low for the number of hops required. The router that decrements the TTL to zero sends this ICMP Type 11 Code 0 message back to the source, as defined in RFC 792.

Exam trap

Linux Foundation often tests the distinction between ICMP error types, and the trap here is that candidates confuse 'time exceeded' with 'destination unreachable' or assume any connectivity loss is due to a firewall or MTU issue, rather than recognizing the specific TTL exhaustion symptom.

How to eliminate wrong answers

Option A is wrong because an MTU mismatch typically triggers 'ICMP fragmentation needed' (Type 3 Code 4) messages, not 'time exceeded'. Option B is wrong because if the destination host is down, the last-hop router would send 'ICMP destination unreachable' (Type 3 Code 1) or the host itself would be silent, not a 'time exceeded' from an intermediate router. Option C is wrong because a firewall blocking packets would either drop them silently or send 'ICMP administratively prohibited' (Type 3 Code 13), not a 'time exceeded' message.

Practice this question →

28

MCQhard

Given the routing table, if the server sends a packet to destination 10.0.1.200, which interface will be used and what is the next hop?

A.eth1 via 10.0.1.1

B.eth1 directly to 10.0.1.200

C.eth0 with next hop 10.0.0.1

D.eth0 with next hop 10.0.1.200

AnswerB

Directly connected route, no gateway needed.

Why this answer

The destination 10.0.1.200 falls within the directly connected network 10.0.1.0/24 on eth1. According to the routing table, this route has a /24 netmask and is marked as directly connected, meaning no next-hop router is needed. The server will ARP for 10.0.1.200 and send the packet directly to that host via eth1.

Exam trap

The trap here is that candidates often assume all traffic must go through a gateway (next hop), forgetting that directly connected routes allow direct delivery without a router, leading them to pick Option A or C.

How to eliminate wrong answers

Option A is wrong because it incorrectly specifies a next-hop gateway (10.0.1.1) for a directly connected network; when the destination is on the same subnet, the packet is sent directly, not via a router. Option C is wrong because eth0 is associated with the 10.0.0.0/24 network, and 10.0.1.200 is not within that subnet; the routing table would not use eth0 for this destination. Option D is wrong because eth0 is not the correct interface for the 10.0.1.0/24 network, and even if it were, a directly connected route does not use a next-hop IP; the packet would be sent directly to the destination MAC.

Practice this question →

29

MCQhard

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?

A.iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT; iptables -P INPUT DROP

B.iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -P INPUT ACCEPT

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

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

AnswerC

This allows incoming HTTPS, blocks other inbound, and allows all outbound.

Why this answer

Option C is correct because it explicitly allows inbound HTTPS traffic on port 443, permits return traffic for established/related connections (which is essential for the server to communicate with the internal database on port 3306), and sets a default DROP policy on the INPUT chain to block all other inbound traffic. The OUTPUT chain is left with a default ACCEPT policy, allowing the server to initiate outbound connections to the database without additional rules.

Exam trap

The trap here is that candidates often forget to set a default DROP policy on the INPUT chain or mistakenly set a default DROP on the OUTPUT chain, thinking it enhances security, but this breaks outbound connectivity required for the server to communicate with the internal database.

How to eliminate wrong answers

Option A is wrong because it does not set a default policy on the INPUT chain; the default policy remains ACCEPT (unless explicitly changed), which would allow all inbound traffic, contradicting the requirement to block all other inbound traffic. Option B is wrong because it sets the INPUT chain default policy to ACCEPT, which permits all inbound traffic, and it lacks the ESTABLISHED,RELATED rule, which would break return traffic for the database connection. Option D is wrong because it sets the OUTPUT chain default policy to DROP, which would block the server from initiating outbound connections to the internal database on port 3306, violating the requirement that the server needs to communicate with the database.

Practice this question →

30

MCQmedium

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?

A.The hosts on 10.0.1.0/24 do not have a route to 10.0.2.0/24

B.The server cannot reach 10.0.2.10

C.IP forwarding is not enabled

D.The iptables FORWARD chain has a DROP policy

AnswerA

If hosts don't know where 10.0.2.0/24 is, they send packets to their default gateway, which may not be this server.

Why this answer

The server can ping both networks, confirming IP forwarding is enabled and iptables FORWARD chain policy is ACCEPT. Hosts on 10.0.1.0/24 can ping the server's eth0 IP but not hosts on 10.0.2.0/24, which indicates the hosts lack a route to the 10.0.2.0/24 network. Without a route, packets from 10.0.1.0/24 destined for 10.0.2.0/24 are dropped at the source host because the kernel has no next-hop information for that destination.

Exam trap

The trap here is that candidates often assume the router's IP forwarding or firewall is the problem when the server itself can reach both networks, overlooking the requirement for client-side routing configuration.

How to eliminate wrong answers

Option B is wrong because the server can ping 10.0.2.10, proving reachability from the server to that host. Option C is wrong because IP forwarding is confirmed enabled by the server's ability to ping both networks, and the question states it is enabled. Option D is wrong because the iptables FORWARD chain policy is explicitly stated as ACCEPT, so packets are not being dropped by the firewall.

Practice this question →

31

Multi-Selectmedium

Which TWO utilities can be used to configure network bridges on Linux?

Select 2 answers

A.route

B.ip

C.nmcli

D.brctl

E.ifconfig

AnswersB, D

The ip command can manage bridges using 'ip link set master' and 'ip link add type bridge'.

Why this answer

The `ip` command (from the iproute2 suite) is the modern, recommended tool for configuring network bridges on Linux. It can create, delete, and manage bridge devices (e.g., `ip link add name br0 type bridge`) and enslave interfaces to them, replacing the older `brctl` utility. `brctl` is also correct as it was the traditional tool from the bridge-utils package, still widely used for bridge management.

Exam trap

The trap here is that candidates often confuse `route` (Layer 3 routing) with bridge configuration (Layer 2 switching), or assume `ifconfig` is still a valid tool for all interface management tasks, including bridges.

Practice this question →

32

MCQeasy

A system administrator needs to configure a static IPv4 address of 192.168.1.100/24 on interface eth0 using NetworkManager. Which command accomplishes this?

A.nmcli dev set eth0 ipv4.address 192.168.1.100/24

B.nmcli con up eth0 ipv4.address 192.168.1.100/24

C.nmcli con mod eth0 ipv4.addresses 192.168.1.100/24 ipv4.method manual

D.nmcli con add con-name eth0 type ethernet ipv4.address 192.168.1.100/24

AnswerC

This correctly modifies the connection to use a static IP address and sets the method to manual.

Why this answer

Option C is correct because `nmcli con mod` modifies an existing connection profile, and setting `ipv4.addresses` along with `ipv4.method manual` is the proper way to assign a static IPv4 address in NetworkManager. The `/24` prefix length is correctly specified as part of the address value, and the manual method disables DHCP for IPv4.

Exam trap

The trap here is that candidates often confuse `nmcli dev set` (device-level) with `nmcli con mod` (connection-level), or they use the singular `ipv4.address` instead of the plural `ipv4.addresses`, which is the correct property name in NetworkManager.

How to eliminate wrong answers

Option A is wrong because `nmcli dev set` is used to set device-level properties (like link state or MTU), not IP address configuration; it does not accept `ipv4.address` as a parameter. Option B is wrong because `nmcli con up` brings a connection profile up (activates it) and does not accept `ipv4.address` as an argument; it cannot modify configuration. Option D is wrong because `nmcli con add` creates a new connection profile, but the correct parameter for the IP address is `ipv4.addresses` (plural), not `ipv4.address` (singular), and it also requires `ipv4.method manual` to set a static address; without that, the profile would default to DHCP.

Practice this question →

33

Multi-Selecthard

Which TWO commands can display a list of active TCP connections listening on the system? (Choose two.)

Select 2 answers

A.ss -tuln

B.nmcli connection show

C.ifconfig

D.netstat -tuln

E.ip route show

AnswersA, D

Modern replacement for netstat; shows listening sockets.

Why this answer

Option A is correct because `ss -tuln` displays TCP (`-t`) and UDP (`-u`) sockets in a listening (`-l`) state with numeric (`-n`) addresses and ports, directly showing active TCP listening connections. Option D is correct because `netstat -tuln` performs the same function, listing TCP and UDP listening sockets with numeric output, and is the traditional tool for this purpose.

Exam trap

The trap here is that candidates confuse commands that show network configuration (like `ifconfig` or `ip route`) with commands that show active socket states, leading them to pick options that display interface or routing information instead of listening TCP ports.

Practice this question →

34

MCQmedium

A Linux server cannot reach the internet, but internal LAN connectivity works. The output of 'ip route' shows a default gateway of 192.168.1.1, but pinging 8.8.8.8 fails. What is the most likely cause?

A.The default gateway is not reachable or has no internet connectivity.

B.The ARP table is corrupted.

C.The default gateway is missing.

D.DNS resolution is failing.

AnswerA

The gateway may be down or misconfigured.

Why this answer

The default gateway 192.168.1.1 is present in the routing table, but pinging 8.8.8.8 fails while internal LAN connectivity works. This indicates that the gateway itself either cannot be reached (e.g., due to a layer 2 issue or misconfiguration) or, more likely, it has no upstream internet connectivity. Since the default route is configured, the failure is not due to a missing gateway but rather the gateway's inability to forward traffic to external networks.

Exam trap

The trap here is that candidates often assume a missing default gateway is the problem when they see internet failure, but the question explicitly states the default gateway is present, shifting the focus to the gateway's own connectivity rather than the local routing table.

How to eliminate wrong answers

Option B is wrong because a corrupted ARP table would prevent communication with any host on the local subnet, including the default gateway, causing internal LAN connectivity to fail as well; since internal connectivity works, ARP is functioning correctly. Option C is wrong because the 'ip route' output explicitly shows a default gateway of 192.168.1.1, so the default gateway is not missing. Option D is wrong because DNS resolution is irrelevant when pinging a raw IP address like 8.8.8.8; the failure occurs at the network layer, not at the application layer.

Practice this question →

35

MCQhard

Refer to the exhibit. The /etc/sysconfig/network-scripts/ifcfg-eth0 file contains the above content. After reboot, eth0 still does not obtain an IP via DHCP. What is the most likely missing configuration?

A.The MTU is not specified

B.DNS1 is not set

C.TYPE=Ethernet is missing

D.The gateway is not defined

AnswerC

Without TYPE=Ethernet, the network service may not process the file correctly.

Why this answer

Option C is correct because the `ifcfg-eth0` file is missing the `TYPE=Ethernet` directive. In RHEL/CentOS 7 and later, NetworkManager requires the `TYPE` parameter to correctly identify and manage the interface type. Without it, NetworkManager may ignore the file or fail to apply DHCP settings, even if `BOOTPROTO=dhcp` is present.

Exam trap

The trap here is that candidates often focus on DHCP-specific parameters like DNS or gateway, overlooking that NetworkManager requires the `TYPE` directive to recognize the interface as an Ethernet device, without which the DHCP configuration is never applied.

How to eliminate wrong answers

Option A is wrong because MTU is optional and not required for DHCP to function; the default MTU of 1500 is used if not specified. Option B is wrong because DNS1 is not required for obtaining an IP via DHCP; DNS servers are typically provided by the DHCP server itself. Option D is wrong because the gateway is not required for DHCP to obtain an IP address; the DHCP server supplies the default gateway via the DHCP offer.

Practice this question →

36

MCQmedium

A system administrator is managing a RHEL 8 server that requires a static IP address on interface ens192. The administrator modifies /etc/sysconfig/network-scripts/ifcfg-ens192 to set BOOTPROTO=static, IPADDR=192.168.1.100, PREFIX=24, GATEWAY=192.168.1.1, and DNS1=8.8.8.8. After saving, the administrator runs 'systemctl restart NetworkManager'. The interface obtains the correct static IP and network connectivity works. However, after a reboot of the server, the interface fails to come up with the static IP and instead obtains an IP via DHCP from the local network. The administrator verifies that the DHCP server is active and that the physical connection is good. What is the most likely cause of the issue?

A.The kernel parameter nomodeset is set in /etc/default/grub.

B.The firewall is blocking the static IP assignment.

C.The ONBOOT parameter is set to no or missing in the configuration file.

D.The network service is not enabled to start at boot.

AnswerC

ONBOOT=yes is required for the interface to start at boot.

Why this answer

The ONBOOT parameter controls whether the interface is activated at system boot. If set to 'no' or missing entirely, NetworkManager will not bring up the interface automatically after a reboot, causing it to fall back to DHCP if a DHCP client is active. Setting BOOTPROTO=static and IPADDR correctly only takes effect when ONBOOT=yes is present.

Exam trap

The trap here is that candidates assume setting BOOTPROTO=static and IPADDR is sufficient, overlooking the mandatory ONBOOT=yes parameter required for automatic activation at boot.

How to eliminate wrong answers

Option A is wrong because the kernel parameter 'nomodeset' affects video driver initialization, not network interface configuration or static IP assignment. Option B is wrong because the firewall operates at Layer 3/4 and does not block the assignment of a static IP address to an interface; it filters traffic after the IP is assigned. Option D is wrong because the 'network' service is deprecated in RHEL 8 and replaced by NetworkManager, which is enabled by default; the issue is not about the service being disabled but about the per-interface ONBOOT setting.

Practice this question →

37

MCQmedium

Which bonding mode provides high availability without requiring switch configuration?

A.mode 1 (active-backup)

B.mode 4 (802.3ad)

C.mode 6 (balance-alb)

D.mode 0 (balance-rr)

AnswerA

Active-backup uses only one NIC at a time; no switch configuration needed.

Why this answer

Mode 1 (active-backup) provides high availability by designating one NIC as active and the others as standby, with automatic failover if the active link fails. It requires no special switch configuration because it does not use any link aggregation protocol or load-balancing algorithm that depends on switch-side settings.

Exam trap

The trap here is that candidates often confuse 'high availability' with 'load balancing' and choose mode 0 or mode 4, not realizing that those modes require switch configuration or do not inherently provide failover without additional setup.

How to eliminate wrong answers

Option B is wrong because mode 4 (802.3ad) requires the switch to be configured with a matching LACP (Link Aggregation Control Protocol) port channel. Option C is wrong because mode 6 (balance-alb) requires the switch to accept packets from multiple MAC addresses on the same port, which may need switch-side ARP filtering or port security adjustments. Option D is wrong because mode 0 (balance-rr) requires the switch to support Ethernet bonding (e.g., static link aggregation) and typically needs switch configuration to treat the multiple links as a single logical link.

Practice this question →

38

MCQhard

A system administrator needs to securely transfer files between two Linux servers using port 22. The administrator uses the following command: 'scp file.txt user@remote:/tmp/'. The transfer fails with the error 'Permission denied (publickey)'. What is the most likely cause?

A.The client's public key is not in the remote user's authorized_keys file.

B.The remote server does not have SSH installed.

C.The SSH service is not running on the remote server.

D.The remote server's firewall is blocking port 22.

AnswerA

'Permission denied (publickey)' indicates key authentication failed.

Why this answer

The error 'Permission denied (publickey)' indicates that the SSH key-based authentication failed. SCP uses SSH for transport, and by default, SSH on the remote server checks the client's public key against the remote user's ~/.ssh/authorized_keys file. If the client's public key is not listed there, the SSH server rejects the connection, causing the SCP transfer to fail.

Exam trap

The trap here is that candidates often confuse network-level issues (firewall, service status) with authentication-level errors, but the specific 'Permission denied (publickey)' message directly points to SSH key authentication failure, not connectivity or service availability.

How to eliminate wrong answers

Option B is wrong because if the remote server did not have SSH installed, the error would typically be 'Connection refused' or 'No route to host', not 'Permission denied (publickey)'. Option C is wrong because if the SSH service were not running, the client would receive a 'Connection refused' error, not a publickey authentication failure. Option D is wrong because if the remote server's firewall were blocking port 22, the client would see a timeout or 'Connection refused' error, not a publickey permission error.

Practice this question →

39

MCQhard

A server has two network interfaces: eth0 (192.168.1.10/24) and eth1 (10.0.0.10/24). The default gateway is 192.168.1.1. The administrator wants traffic to 10.0.1.0/24 to go through eth1's gateway 10.0.0.1. Which command adds this route?

A.Both A and B are correct

B.ip route add 10.0.1.0/24 via 10.0.0.1 dev eth1

C.ip route add 10.0.1.0/24 dev eth1 via 10.0.0.1

D.route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.0.0.1 eth1

AnswerA

Both commands correctly add the route; ip route is the modern method, but route is still supported on many systems.

Why this answer

Option A is correct because both B and C are valid `ip route add` syntax variations that achieve the same result: adding a route to 10.0.1.0/24 via gateway 10.0.0.1 on interface eth1. The `ip route` command accepts the `via` and `dev` keywords in either order, making both B and C syntactically correct. Option D uses the legacy `route` command with improper syntax (missing `dev` keyword before the interface name), which would fail or produce unexpected behavior.

Exam trap

The trap here is that candidates assume the legacy `route` command's syntax is interchangeable with `ip route`, or that the order of `via` and `dev` in `ip route` is fixed, leading them to incorrectly dismiss valid options B or C.

How to eliminate wrong answers

Option B is wrong because it is actually correct — it uses proper `ip route add` syntax with `via` followed by `dev`. Option C is wrong because it is also correct — the `ip route add` command allows `dev` before `via` without issue. Option D is wrong because the legacy `route add` command requires the `dev` keyword before the interface name (e.g., `dev eth1`), not just appending `eth1` at the end; the correct syntax would be `route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.0.0.1 dev eth1`.

Practice this question →

40

MCQeasy

A system administrator wants to combine two network interfaces for increased throughput and fault tolerance. The requirement is that both links are active simultaneously and the system can tolerate a failure of one link without interruption. Which bonding mode should be used?

A.Mode 4 (802.3ad)

B.Mode 2 (balance-xor)

C.Mode 1 (active-backup)

D.Mode 0 (balance-rr)

AnswerA

Combines links for throughput and fails over if a link goes down.

Why this answer

Mode 4 (802.3ad) is correct because it implements IEEE 802.3ad Link Aggregation Control Protocol (LACP), which allows both links to be active simultaneously for increased throughput while providing fault tolerance. If one link fails, traffic is automatically redistributed across the remaining active links without interruption, meeting the requirement for both active links and failure tolerance.

Exam trap

The trap here is that candidates often confuse Mode 4 (802.3ad) with Mode 0 (balance-rr) because both allow active links, but Mode 0 lacks the standardized LACP negotiation and seamless failover that Mode 4 provides, leading to incorrect selection when fault tolerance is explicitly required.

How to eliminate wrong answers

Option B (Mode 2, balance-xor) is wrong because while it allows both links to be active, it does not provide fault tolerance without interruption—a link failure may cause traffic disruption until the bonding driver rebalances. Option C (Mode 1, active-backup) is wrong because it uses only one active link at a time, failing the requirement for both links to be active simultaneously. Option D (Mode 0, balance-rr) is wrong because although both links are active, it does not support 802.3ad negotiation and may cause out-of-order packet delivery, and it does not guarantee seamless failover without interruption.

Practice this question →

41

MCQmedium

A system administrator notices that a web server is not reachable from the internet but is reachable from the internal network. The server's IP is 10.0.1.10/24, and the gateway is 10.0.1.1. Which command should be used to verify the default gateway configuration?

A.arp -a

B.ip route show

C.ip addr show

D.ss -tln

AnswerB

This command displays the routing table, including the default gateway.

Why this answer

The `ip route show` command displays the kernel routing table, including the default gateway entry. Since the server is reachable internally but not from the internet, a missing or incorrect default gateway is the likely cause. This command directly verifies whether a default route (e.g., via 10.0.1.1) is present.

Exam trap

The trap here is that candidates often confuse `ip addr show` (which shows IP configuration) with `ip route show` (which shows routing), leading them to check the IP address instead of the default gateway when troubleshooting external connectivity.

How to eliminate wrong answers

Option A is wrong because `arp -a` shows the ARP cache (IP-to-MAC address mappings) for the local network, not the routing table or default gateway. Option C is wrong because `ip addr show` displays IP addresses and interface configuration, not routing information. Option D is wrong because `ss -tln` lists listening TCP sockets and their ports, which is used to verify service availability, not network-layer routing.

Practice this question →

42

MCQeasy

Which command displays the listening UDP ports on a Linux system?

A.ss -a

B.ss -tln

C.ss -uln

D.netstat -tln

AnswerC

-u for UDP, -l for listening, -n for numeric.

Why this answer

Option C is correct because `ss -uln` specifically displays listening UDP sockets. The `-u` flag filters for UDP, `-l` shows only listening sockets, and `-n` displays numeric addresses and ports (avoiding DNS resolution). This is the most precise command for listing listening UDP ports.

Exam trap

The trap here is that candidates often confuse the `-t` (TCP) and `-u` (UDP) flags, or assume that `netstat -tln` or `ss -tln` will show all listening ports, forgetting that UDP requires explicit `-u` filtering.

How to eliminate wrong answers

Option A is wrong because `ss -a` shows all sockets (both listening and non-listening, TCP and UDP), which is too broad and does not filter for UDP or listening state specifically. Option B is wrong because `ss -tln` filters for TCP sockets only (`-t`), so it will not display any UDP ports. Option D is wrong because `netstat -tln` also filters for TCP sockets only (`-t`), and while netstat can show UDP with `-u`, this option omits the `-u` flag, so it shows only listening TCP ports.

Practice this question →

43

Multi-Selecthard

Which THREE statements about Linux network bonding modes are correct? (Choose three.)

Select 3 answers

A.Mode 2 (balance-xor) distributes traffic based on packet type.

B.Mode 0 (balance-rr) can cause out-of-order packet delivery.

C.Modes 5 and 6 (balance-tlb and balance-alb) require IEEE 802.3ad switch support.

D.Mode 4 (802.3ad) requires the switch to support LACP.

E.Mode 1 (active-backup) provides fault tolerance but only one link is active at a time.

AnswersB, D, E

Correct.

Why this answer

Mode 0 (balance-rr) transmits packets in sequential order from the first available slave through the last, then starts over. This round-robin distribution can cause packets belonging to the same TCP session to take different physical paths, leading to out-of-order delivery at the receiver, which may trigger TCP retransmissions and degrade performance.

Exam trap

The trap here is that candidates often confuse 'balance-rr' with 'balance-xor' and assume round-robin distributes traffic based on a hash or packet type, when in fact it simply cycles through slaves without any flow-level awareness.

Practice this question →

44

MCQhard

A systems administrator is responsible for a production Linux server running CentOS 7 that provides SSH access to users. The administrator decides to tighten security by restricting SSH access to a specific management subnet 10.0.0.0/24. While connected to the server via SSH from a workstation on 10.0.0.50, the administrator adds the following iptables rule: iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT followed by iptables -P INPUT DROP. Immediately after the rule change, the administrator loses all connectivity to the server, including SSH. The administrator suspects that the new default policy dropped the existing SSH session. What is the most reliable method for the administrator to regain access to the server without rebooting?

A.Use netcat to send a TCP reset packet to the SSH server.

B.Use iptables-save and iptables-restore from another host on the same subnet.

C.Use IPMI or iDRAC to access the server's console and remove or modify the iptables rules.

D.Boot the server into single-user mode and flush iptables rules.

AnswerC

Out-of-band management provides console access independent of network.

Why this answer

Option C is correct because IPMI (Intelligent Platform Management Interface) or iDRAC (Integrated Dell Remote Access Controller) provides out-of-band management access to the server's console, independent of the operating system's network stack. This allows the administrator to log in locally, remove or modify the iptables rules that dropped the SSH session, and restore connectivity without rebooting. Since the default INPUT policy was set to DROP, all new and existing SSH packets are blocked, but out-of-band management bypasses iptables entirely.

Exam trap

The trap here is that candidates assume iptables rules only affect new connections, forgetting that changing the default policy to DROP without a stateful rule for ESTABLISHED connections will immediately terminate existing sessions, and they overlook out-of-band management as the only non-reboot recovery option.

How to eliminate wrong answers

Option A is wrong because netcat cannot send a TCP reset packet to an existing SSH session that is already blocked by the iptables DROP policy; the kernel's netfilter will drop any packets to port 22, including resets, and netcat operates at the application layer, not at the raw socket level required to inject a reset. Option B is wrong because iptables-save and iptables-restore require an active SSH session or network connectivity to execute commands on the target server; since the administrator has lost all connectivity, there is no way to run these commands from another host. Option D is wrong because booting into single-user mode requires a reboot, which the question explicitly states should be avoided; moreover, single-user mode is a boot-time option that cannot be entered without restarting the system.

Practice this question →

45

MCQhard

A Linux administrator needs to configure VLAN tagging on a network bridge to isolate traffic from different virtual machines. The physical interface is eth0, and VLAN ID 100 should be accessible via the bridge br0. Which set of commands correctly creates this configuration using the ip command?

A.ip link add link eth0 name eth0.100 type vlan id 100; ip link add br0 type bridge; ip link set eth0.100 master br0; ip link set br0 up

B.ip link add br0 type bridge; ip link set eth0 master br0; ip link set br0 up

C.ip link add eth0.100 link eth0 type vlan id 100; ip link set eth0.100 master br0; ip link add br0 type bridge

D.ip link add name br0 type bridge; ip link add link br0 name vlan100 type vlan id 100; ip link set eth0 master br0

AnswerA

Correct sequence: create VLAN subinterface, create bridge, attach VLAN to bridge.

Why this answer

Option A is correct because it first creates a VLAN interface (eth0.100) on top of physical interface eth0 with VLAN ID 100 using `ip link add link eth0 name eth0.100 type vlan id 100`. It then creates a bridge (br0) with `ip link add br0 type bridge`, attaches the VLAN interface to the bridge as a port with `ip link set eth0.100 master br0`, and finally brings the bridge up. This sequence ensures that traffic tagged with VLAN 100 on eth0 is properly forwarded through the bridge to virtual machines, while untagged or other VLAN traffic is isolated.

Exam trap

The trap here is that candidates often forget the order of operations — the bridge must exist before enslaving a port, and the VLAN interface must be created on the physical NIC, not on the bridge itself.

How to eliminate wrong answers

Option B is wrong because it directly attaches the physical interface eth0 to the bridge without creating a VLAN interface, so no VLAN tagging or isolation is configured — all traffic on eth0 passes through the bridge untagged. Option C is wrong because it attempts to set eth0.100 as a slave of br0 before the bridge br0 has been created, which will fail since the bridge must exist first for the `master` command to succeed. Option D is wrong because it creates a VLAN interface on top of the bridge (br0) rather than on the physical interface eth0, which would tag traffic originating from the bridge itself rather than isolating incoming VLAN 100 traffic from eth0.

Practice this question →

46

MCQmedium

A system administrator runs 'ss -tuln' and sees that port 80 is listening. What does the 'u' option represent?

A.User

B.Unix sockets

C.UDP

D.Unicast

AnswerC

The -u option filters for UDP sockets.

Why this answer

In the `ss` command, the `-u` option filters output to show only UDP sockets. Since the question shows `ss -tuln`, which combines `-t` (TCP), `-u` (UDP), `-l` (listening), and `-n` (numeric), the `u` specifically represents UDP. This is confirmed by the `ss` man page and standard Linux networking tools.

Exam trap

The trap here is that candidates confuse `-u` with 'Unix sockets' (which is `-x`) or 'User' (which is `-p`), because the letter 'u' is commonly associated with 'Unix' or 'user' in other commands, but in `ss` it specifically means UDP.

How to eliminate wrong answers

Option A is wrong because `-u` does not stand for 'User'; user information is displayed with the `-p` option or by default in some output formats, not with `-u`. Option B is wrong because Unix sockets are displayed with the `-x` option, not `-u`; `-u` is exclusively for UDP sockets. Option D is wrong because 'Unicast' is a type of network transmission, not a socket type or protocol filter in `ss`; `ss` uses `-u` to filter by UDP protocol, not by unicast addressing.

Practice this question →

47

MCQmedium

After editing /etc/resolv.conf to set a custom DNS server, the changes are reverted after reboot. What is the most likely cause?

A.The DHCP client overwrites resolv.conf on lease renewal

B.SELinux reinitializes the file from defaults

C.NetworkManager manages DNS and overwrites manual changes

D.systemd-resolved regenerates the file from configuration

AnswerC

NetworkManager updates resolv.conf based on its configuration; to persist manual changes, set dns=none in NetworkManager.conf.

Why this answer

NetworkManager actively manages network interfaces and DNS settings by default on many Linux distributions. When a user manually edits /etc/resolv.conf, NetworkManager detects the change and overwrites it with its own configuration, especially after a reboot or network restart, because it treats the file as a managed resource. This is the most common reason for DNS changes being reverted.

Exam trap

The trap here is that candidates often assume DHCP client behavior (Option A) is the primary cause, but the LFCS exam focuses on NetworkManager as the default network service manager on modern enterprise Linux distributions like RHEL and CentOS.

How to eliminate wrong answers

Option A is wrong because while a DHCP client can overwrite resolv.conf on lease renewal, this typically occurs only if the DHCP client is configured to manage DNS directly, which is less common than NetworkManager's default behavior on modern systems. Option B is wrong because SELinux does not reinitialize files from defaults; it enforces security policies on file access but does not regenerate or overwrite configuration files. Option D is wrong because systemd-resolved can regenerate resolv.conf from its own configuration, but this only happens if systemd-resolved is actively managing DNS and resolv.conf is symlinked to /run/systemd/resolve/stub-resolv.conf, which is not the default in all distributions and is less likely than NetworkManager's direct management.

Practice this question →

48

MCQhard

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?

A.The web server is not listening on the public IP address.

B.A firewall rule is blocking incoming HTTPS traffic.

C.The default gateway is unreachable, preventing return traffic from the internet.

D.The private interface eth1 has a misconfigured IP address.

AnswerC

The gateway is down, so the server cannot send packets to the internet, making the web server unreachable.

Why this answer

The correct answer is C. The server's default gateway (203.0.113.1) is unreachable, as confirmed by the 100% packet loss on ping. This means that although the web server is listening on 0.0.0.0:443 and the firewall allows traffic, any response packets from the server to internet clients must be routed through the default gateway.

Without a working gateway, return traffic cannot reach the clients, causing intermittent unreachability from the internet.

Exam trap

The trap here is that candidates often focus on firewall rules or service binding, overlooking the fact that even with correct listening and permissive firewall, network-layer routing (specifically a working default gateway) is essential for bidirectional communication with the internet.

How to eliminate wrong answers

Option A is wrong because the web server is listening on 0.0.0.0:443, which binds to all available IP addresses, including the public IP 203.0.113.10, so it is accessible on the public interface. Option B is wrong because the iptables output shows an empty INPUT chain with a default policy of ACCEPT, meaning no firewall rules are blocking incoming HTTPS traffic. Option D is wrong because the routing table shows a correct route for 10.0.0.0/24 via eth1 with the source IP 10.0.0.10, and the private interface is functioning for internal database connectivity; the issue is with the default gateway, not the private IP configuration.

Practice this question →

49

Multi-Selectmedium

A system administrator needs to configure a network bond on a Linux server using NetworkManager. Which TWO steps are required to create a functional bond interface?

Select 2 answers

A.Set the bond mode to 'balance-rr' in the connection profile.

B.Load the bonding kernel module using 'modprobe bonding'.

C.Use 'nmcli connection add type bond ifname bond0' to create the bond interface.

D.Use 'nmcli connection add type ethernet ifname eth0 master bond0' to attach a slave.

E.Ensure that the slave interfaces are down before adding them to the bond.

AnswersC, D

Creating the bond connection is the first required step.

Why this answer

The two required steps are creating the bond connection and attaching slave interfaces. The bonding kernel module is usually loaded automatically. Setting the bond mode and IP address can be done later, and the slave interfaces do not need to be down.

Practice this question →

50

MCQhard

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?

A.The default route is missing

B.The default gateway 10.0.1.1 does not have internet connectivity

C.The host has no route to 10.0.2.0/24

D.The host has no route to 10.0.1.1

AnswerB

Even though the host can reach the gateway, the gateway itself may not have a path to the internet.

Why this answer

The host can ping 10.0.2.1, which is on the directly connected 10.0.2.0/24 network, confirming that the local interface and link-layer are functional. However, it cannot ping 8.8.8.8, a public internet address. The routing table shows a default route via 10.0.1.1, so the host will forward the packet to that gateway.

Since the host has a default route, the most likely cause is that the gateway 10.0.1.1 itself lacks internet connectivity (e.g., no upstream route, NAT misconfiguration, or ISP outage), preventing the packet from reaching 8.8.8.8.

Exam trap

The trap here is that candidates assume a missing default route is the only cause for internet unreachability, but the question explicitly states the routing table includes a default route, shifting the focus to the gateway's own connectivity or upstream routing failure.

How to eliminate wrong answers

Option A is wrong because the routing table includes a default route (0.0.0.0/0 via 10.0.1.1), so the default route is not missing. Option C is wrong because the host can ping 10.0.2.1, which is on the 10.0.2.0/24 network, proving that a route to that subnet exists (likely a directly connected route). Option D is wrong because the host does not need a specific route to 10.0.1.1; the default route via 10.0.1.1 implies the host can reach that gateway through its local subnet (e.g., via ARP on the directly connected network), and the problem is upstream, not local reachability.

Practice this question →

51

MCQeasy

An administrator wants to permanently configure a static IP address on a CentOS 7 system. Which file should be edited?

A./etc/sysconfig/network-scripts/ifcfg-eth0

B./etc/sysconfig/network

C./etc/hostname

D./etc/network/interfaces

AnswerA

This is the standard network interface configuration file for CentOS/RHEL 7.

Why this answer

On CentOS 7, network interface configuration is stored in individual files under /etc/sysconfig/network-scripts/, named ifcfg-<interface>. The ifcfg-eth0 file contains parameters like BOOTPROTO, IPADDR, NETMASK, and GATEWAY, and setting BOOTPROTO=static along with the IP address values permanently configures a static IP. This is the standard method for RHEL/CentOS 7 systems using the legacy network scripts (not NetworkManager's keyfile format).

Exam trap

The trap here is that candidates familiar with Debian-based systems may choose /etc/network/interfaces (Option D), while those who confuse global network settings with per-interface settings may pick /etc/sysconfig/network (Option B), both of which are incorrect for CentOS 7's static IP configuration.

How to eliminate wrong answers

Option B is wrong because /etc/sysconfig/network is a system-wide file that sets global networking parameters (e.g., HOSTNAME, GATEWAY) but does not define per-interface IP addresses; editing it alone cannot configure a static IP for a specific interface. Option C is wrong because /etc/hostname only sets the system's hostname, not IP address configuration; it is unrelated to static IP assignment. Option D is wrong because /etc/network/interfaces is the configuration file used by Debian/Ubuntu systems (ifupdown), not by CentOS 7 which uses the ifcfg files under /etc/sysconfig/network-scripts/.

Practice this question →

52

MCQeasy

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

A.53

B.22

C.443

D.80

AnswerA

Listening on 127.0.0.1, which is the loopback interface only.

Why this answer

Option A is correct because port 53 (DNS) is configured to listen only on the loopback interface (127.0.0.1) as shown in the exhibit's output of `ss -tlnp`. The listening address `127.0.0.1:53` indicates the service is bound exclusively to the loopback interface, meaning it is not accessible from external network interfaces.

Exam trap

The trap here is that candidates often confuse 'listening on all interfaces' (0.0.0.0) with 'listening only on loopback' (127.0.0.1), and may incorrectly assume that common services like SSH or HTTP are loopback-only when they are typically bound to all interfaces.

How to eliminate wrong answers

Option B (22) is wrong because SSH (port 22) is listening on `0.0.0.0:22`, which means it is bound to all interfaces, including external ones, not just the loopback. Option C (443) is wrong because HTTPS (port 443) is listening on `0.0.0.0:443`, indicating it is available on all interfaces, not restricted to loopback. Option D (80) is wrong because HTTP (port 80) is listening on `0.0.0.0:80`, meaning it is bound to all interfaces and not limited to the loopback interface.

Practice this question →

53

MCQhard

Refer to the exhibit. A system administrator notices that SSH connections to the server are being dropped immediately. Assuming the server's external interface is eth0, which rule is responsible for this behavior?

A.Rule 3

B.Both Rule 2 and Rule 3

C.Rule 1

D.Rule 2

AnswerA

Rule 3 drops all incoming traffic on eth0, which includes new SSH connections.

Why this answer

Rule 3 drops all incoming traffic on eth0. SSH traffic is a new connection, so it does not match Rule 2 (which only accepts established/related connections). It also does not match Rule 1 (loopback).

Therefore, Rule 3 drops the SSH connection.

Practice this question →

54

MCQeasy

A network engineer needs to temporarily disable a network interface eth1 without bringing it down permanently. Which command?

A.systemctl stop network

B.ip link set eth1 down

C.nmcli device disconnect eth1

D.ifdown eth1

AnswerB

This temporarily brings the interface down until manually brought up or reboot.

Why this answer

The `ip link set eth1 down` command temporarily disables the eth1 interface by changing its state to DOWN at the kernel level, without making any persistent changes to configuration files. This is the correct approach for a temporary disable because the interface can be re-enabled with `ip link set eth1 up` and will revert to its configured state upon reboot.

Exam trap

The trap here is that candidates often confuse `ifdown eth1` as a temporary disable, but it can trigger persistent configuration changes or rely on deprecated tools, whereas `ip link set eth1 down` is the modern, stateless method for a temporary interface shutdown.

How to eliminate wrong answers

Option A is wrong because `systemctl stop network` disables all network interfaces managed by the network service and stops the entire networking stack, which is not a targeted temporary disable of a single interface. Option C is wrong because `nmcli device disconnect eth1` only disconnects the interface from NetworkManager's active connection, but the interface remains administratively UP and can be reconnected automatically; it does not bring the interface down at the kernel level. Option D is wrong because `ifdown eth1` is a legacy command that reads configuration files (e.g., /etc/network/interfaces) and may trigger persistent changes or rely on deprecated ifupdown scripts, making it unsuitable for a strictly temporary disable without side effects.

Practice this question →

55

Multi-Selectmedium

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

Select 2 answers

A.netstat -rn

B.ifconfig -a

C.ss -tuln

D.route -n

E.ip addr

AnswersA, D

Displays routing table.

Why this answer

Both `netstat -rn` and `route -n` display the kernel IP routing table. The `-r` flag in netstat shows the routing table, and `-n` disables DNS resolution, showing numeric addresses. The `route -n` command directly prints the routing table without resolving hostnames, making both commands suitable for viewing the current routing table.

Exam trap

The trap here is that candidates confuse `ip addr` (which shows addresses) with `ip route` (which shows routes), or assume `ifconfig` shows routing information because it displays interface details, but it never shows the routing table.

Practice this question →

56

MCQmedium

Based on the iptables-save output, what is the default policy for the FORWARD chain and what happens to a new SSH connection from an external host on eth0?

A.Default policy FORWARD is ACCEPT; SSH connections are dropped.

B.Default policy FORWARD is DROP; SSH connections are dropped.

C.Default policy FORWARD is DROP; SSH connections are accepted.

D.Default policy FORWARD is ACCEPT; SSH connections are accepted.

AnswerC

FORWARD default is DROP; SSH rule allows traffic on port 22.

Why this answer

The default policy for the FORWARD chain is DROP, as shown in the iptables-save output (e.g., `:FORWARD DROP [0:0]`). A new SSH connection from an external host on eth0 is accepted because there is a rule in the FORWARD chain that matches incoming SSH traffic (typically TCP port 22) and has a target of ACCEPT, overriding the default DROP policy for that specific traffic.

Exam trap

The trap here is that candidates often confuse the default policy with the actual behavior for specific traffic, assuming that a DROP default policy means all traffic is dropped, ignoring the effect of explicit ACCEPT rules.

How to eliminate wrong answers

Option A is wrong because the default policy for FORWARD is DROP, not ACCEPT, and SSH connections are accepted, not dropped. Option B is wrong because although the default policy is DROP, SSH connections are accepted due to a specific rule, not dropped. Option D is wrong because the default policy is DROP, not ACCEPT, and SSH connections are accepted, not dropped.

Practice this question →

57

MCQmedium

A server has two network interfaces: eth0 (public IP 203.0.113.10/24) and eth1 (private IP 10.0.0.1/8). The default gateway is 203.0.113.1. The admin wants to ensure that traffic to the private subnet 10.0.0.0/8 goes via eth1. Which command correctly adds a static route?

A.ip route add 10.0.0.1/8 dev eth1

B.ip route add 10.0.0.0/8 via 10.0.0.1 dev eth0

C.ip route add 10.0.0.0/8 dev eth1

D.route add -net 10.0.0.0/8 eth1

AnswerC

Correct: adds network route via device eth1.

Why this answer

Option C is correct because it adds a static route for the 10.0.0.0/8 network directly via the eth1 interface, which is the private interface with IP 10.0.0.1/8. The `ip route add` command with `dev eth1` specifies that traffic destined for the 10.0.0.0/8 subnet should be sent out through eth1, without needing a next-hop gateway since eth1 is directly connected to that subnet.

Exam trap

The trap here is that candidates often confuse the network address with a host address (as in Option A) or incorrectly assume a gateway is always required (as in Option B), forgetting that directly connected networks only need a device specification.

How to eliminate wrong answers

Option A is wrong because it specifies the destination as 10.0.0.1/8, which is a host address (10.0.0.1) with a /8 prefix, instead of the network address 10.0.0.0/8; this would create a route for a single host, not the entire subnet. Option B is wrong because it uses `via 10.0.0.1 dev eth0`, which attempts to route 10.0.0.0/8 traffic through eth0 (the public interface) to the gateway 10.0.0.1, but 10.0.0.1 is not reachable via eth0 and the gateway should be on the same subnet as the interface; this would cause traffic to be sent to the wrong interface. Option D is wrong because the `route add` command syntax is incorrect: it uses `-net 10.0.0.0/8 eth1` but the correct syntax requires a `dev` keyword before the interface name (e.g., `route add -net 10.0.0.0/8 dev eth1`), and the command as written would fail or be misinterpreted.

Practice this question →

58

MCQmedium

A network administrator needs to block all incoming SSH traffic (port 22) from the 192.168.2.0/24 subnet. Which iptables command accomplishes this?

A.iptables -A INPUT -d 192.168.2.0/24 -p tcp --dport 22 -j DROP

B.iptables -A OUTPUT -d 192.168.2.0/24 -p tcp --sport 22 -j DROP

C.iptables -A INPUT -s 192.168.2.0/24 -j DROP

D.iptables -A INPUT -s 192.168.2.0/24 -p tcp --dport 22 -j DROP

AnswerD

This drops incoming TCP packets from the subnet to port 22.

Why this answer

Option D is correct because it appends a rule to the INPUT chain that matches packets originating from the 192.168.2.0/24 subnet (-s 192.168.2.0/24) using TCP protocol with destination port 22 (--dport 22), and then drops them (-j DROP). This precisely blocks all incoming SSH traffic from that subnet while leaving other traffic unaffected.

Exam trap

The trap here is that candidates often confuse the -s and -d flags, or mistakenly apply the rule to the OUTPUT chain, thinking they need to block outgoing responses rather than incoming connection attempts.

How to eliminate wrong answers

Option A is wrong because it uses -d (destination) instead of -s (source), which would match packets destined to the 192.168.2.0/24 subnet, not packets coming from it. Option B is wrong because it adds a rule to the OUTPUT chain with --sport 22, which would block outgoing SSH responses from the local machine, not incoming SSH connections. Option C is wrong because it drops all traffic from the 192.168.2.0/24 subnet regardless of protocol or port, which is overly broad and would block legitimate traffic such as DNS or HTTP from that subnet.

Practice this question →

59

MCQmedium

An administrator is unable to SSH into the server from a remote host at 192.168.1.100. Based on the exhibited iptables rules, what is the most likely reason?

A.The SSH rule only allows connections from 10.0.1.0/24, and 192.168.1.100 is not in that subnet

B.SSH is not allowed from any source

C.The INPUT chain policy is ACCEPT, so SSH should be allowed

D.The DROP rule for SSH is not matching because of packet count zero

AnswerA

The second rule allows SSH only from 10.0.1.0/24, and the third rule drops all other SSH.

Why this answer

Option A is correct because the exhibited iptables rules show an SSH rule that explicitly accepts incoming TCP traffic on port 22 only from the source subnet 10.0.1.0/24. The remote host at 192.168.1.100 is not within that subnet, so the SSH rule does not match, and the packet will fall through to the next rule or the default policy. Since no other rule permits SSH from 192.168.1.100, the connection is implicitly dropped or rejected, preventing SSH access.

Exam trap

The trap here is that candidates see the INPUT chain policy is ACCEPT and assume all traffic is allowed, overlooking that a more specific rule (like the SSH rule with a source restriction) can prevent traffic from non-matching sources, effectively overriding the default policy for that service.

How to eliminate wrong answers

Option B is wrong because the iptables rules do allow SSH from the specific subnet 10.0.1.0/24, so SSH is not disallowed from all sources. Option C is wrong because while the INPUT chain policy is ACCEPT, the packet must first match a rule; if a rule explicitly restricts SSH to a specific subnet, packets from other sources are not accepted by that rule and will be evaluated by subsequent rules or the default policy, which in this case does not permit the connection. Option D is wrong because a packet count of zero on a DROP rule simply indicates that no packets have matched that rule yet; it does not mean the rule is inactive or not matching—the rule will still match and drop packets that meet its criteria, and the zero count is irrelevant to whether SSH is allowed from 192.168.1.100.

Practice this question →

60

MCQhard

An administrator is troubleshooting intermittent connectivity issues. Running 'ping -c 100 -i 0.2 10.0.0.1' shows about 5% packet loss. What is the primary purpose of the '-i 0.2' option?

A.It sets the TTL to 0.2

B.It sets the timeout to 0.2 seconds

C.It sets the packet size to 0.2 bytes

D.It sets the interval between pings to 0.2 seconds

AnswerD

This speeds up the test to detect intermittent loss.

Why this answer

The '-i 0.2' option in the ping command sets the interval between sending ICMP Echo Request packets to 0.2 seconds. This allows the administrator to send pings more frequently than the default (typically 1 second), which helps in detecting intermittent connectivity issues over a shorter test duration. By sending 100 packets at a 0.2-second interval, the test completes in about 20 seconds, making it practical for troubleshooting transient packet loss.

Exam trap

The trap here is that candidates confuse '-i' with timeout or TTL options, mistakenly thinking it controls how long to wait for a reply rather than the spacing between packet transmissions.

How to eliminate wrong answers

Option A is wrong because '-i' does not set the TTL (Time to Live); TTL is set with the '-t' option in ping. Option B is wrong because '-i' controls the interval between packets, not the timeout; the timeout for waiting for a reply is set with '-W' (or '-w' for a deadline). Option C is wrong because '-i' does not affect packet size; packet size is set with '-s' (e.g., '-s 1472' for a specific payload size).

Practice this question →

61

MCQmedium

A system administrator wants to allow incoming SSH connections from a specific IP range 192.168.10.0/24 using firewalld. Which command should be used?

A.firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" service name="ssh" accept' --permanent

B.firewall-cmd --add-service=ssh --add-source=192.168.10.0/24 --zone=internal --permanent

C.firewall-cmd --add-source=192.168.10.0/24 --add-service=ssh --permanent

D.firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" service name="ssh" accept' --permanent

AnswerD

This is the correct syntax for adding a rich rule that allows SSH from a specific source in a specific zone.

Why this answer

Option D is correct because it explicitly targets the 'public' zone (the default zone for external-facing interfaces) and uses a rich rule to allow SSH traffic only from the 192.168.10.0/24 source IP range. The --permanent flag ensures the rule persists across reloads. This is the precise syntax required by firewalld for source-specific service access.

Exam trap

The trap here is that candidates often forget to specify the zone (defaulting to the wrong zone) or incorrectly assume that --add-source and --add-service can be combined directly without a rich rule, leading to a rule that either applies to all sources or fails silently.

How to eliminate wrong answers

Option A is wrong because it omits the --zone parameter, so the rule would be applied to the default zone (which may not be 'public'), and the rich-rule syntax is incomplete (missing 'accept' action). Option B is wrong because it uses --add-source and --add-service together in a single command without a rich rule; firewalld does not combine source and service in this way — --add-source adds a source binding to a zone, not a filtering rule. Option C is wrong because it lacks a zone specification and attempts to combine --add-source and --add-service as direct options, which is invalid syntax; the correct approach requires a rich rule or a direct rule with zone context.

Practice this question →

62

Multi-Selecteasy

Which TWO methods can be used to set a static IPv4 address on a CentOS 7 system? (Choose two.)

Select 2 answers

A.Run the command 'systemctl set-static-ip eth0 192.168.1.100/24'

B.Use 'ip addr add 192.168.1.100/24 dev eth0'

C.Use the nmtui utility

D.Edit the /etc/network/interfaces file

E.Edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file directly

AnswersC, E

nmtui is a text-based tool for NetworkManager configuration, including static IP.

Why this answer

Option C is correct because nmtui is a text-based user interface for NetworkManager, which is the default networking service on CentOS 7. It allows you to interactively configure network interfaces, including setting a static IPv4 address, without needing to manually edit configuration files. Option E is correct because the ifcfg-eth0 file in /etc/sysconfig/network-scripts is the traditional, direct configuration method for network interfaces on CentOS 7, where you can set BOOTPROTO=static and define IPADDR, PREFIX, and GATEWAY.

Exam trap

The trap here is that candidates often confuse temporary runtime commands like 'ip addr add' with permanent configuration methods, or they assume that systemctl can be used for network configuration because it is a common system administration tool.

Practice this question →

63

MCQmedium

A server with two network interfaces (eth0 and eth1) needs to be configured as a bridge (br0) to allow KVM virtual machines to share the host's physical network. Which steps are correct?

A.Create bridge br0, add eth0 as port, assign IP to br0, remove IP from eth0.

B.Create bridge br0, add eth0 as port, assign IP to eth0, do not assign IP to br0.

C.Create bond0 from eth0 and eth1, then add bond0 to bridge br0.

D.Create bridge br0, add eth0 and eth1 as bridge ports, assign IP to br0, remove IP from eth0 and eth1.

AnswerA

This is the standard procedure for configuring a bridge with a physical interface.

Why this answer

Option A is correct because bridging requires the physical interface (eth0) to be added as a port to the bridge (br0) without an IP address, while the bridge itself gets the IP address to act as the network layer endpoint. This allows KVM virtual machines connected to br0 to communicate through eth0, which operates at layer 2. Removing the IP from eth0 prevents IP conflicts and ensures all traffic is handled by the bridge.

Exam trap

The trap here is that candidates often think the physical interface must retain its IP address or that both interfaces must be added to the bridge, confusing bridging with routing or bonding.

How to eliminate wrong answers

Option B is wrong because assigning an IP to eth0 while it is a bridge port creates a layer 2 loop and IP conflict; the IP must be on the bridge interface, not the physical port. Option C is wrong because bonding (bond0) is for link aggregation or redundancy, not required for a simple bridge; adding a bond to a bridge is an unnecessary complexity and not a standard step for sharing a physical network with KVM. Option D is wrong because adding both eth0 and eth1 as bridge ports without bonding or routing configuration would create a bridge that forwards traffic between two separate physical networks, which is not the goal of sharing a single physical network; typically only one interface is needed unless specific bridging of both networks is intended.

Practice this question →

64

Multi-Selectmedium

Which THREE are built-in chains in the iptables filter table? (Choose three.)

Select 3 answers

A.POSTROUTING

B.INPUT

C.OUTPUT

D.FORWARD

E.PREROUTING

AnswersB, C, D

INPUT chain processes incoming packets destined for the local system.

Why this answer

The filter table in iptables is used for packet filtering decisions based on IP addresses, ports, and protocols. Its built-in chains are INPUT (for packets destined for the local system), OUTPUT (for packets originating from the local system), and FORWARD (for packets routed through the system). These three chains allow you to control traffic at different points in the packet flow.

Exam trap

The trap here is that candidates often confuse the filter table's chains with those of the nat table (PREROUTING, POSTROUTING) because all chains are used in packet traversal, but only INPUT, OUTPUT, and FORWARD belong to the filter table.

Practice this question →

65

MCQmedium

A Linux system administrator is troubleshooting a DNS resolution issue on a Ubuntu 20.04 server. The server is configured with a static IP address on interface eth0 via /etc/netplan/01-netcfg.yaml. The administrator set the DNS servers to 8.8.8.8 and 8.8.4.4 in the cloud-config file. After applying the netplan configuration, the server can resolve hostnames correctly. However, after a few days, users report that the server can no longer resolve external hostnames. The administrator checks /etc/resolv.conf and sees that it contains only a local DNS server (127.0.0.53) and no references to the public DNS servers. The administrator wants to ensure that the public DNS servers are always used and that local DNS is bypassed. What is the best course of action?

A.Modify the netplan configuration to set dns servers and set 'dhcp4-overrides: {use-dns: false}' then apply.

B.Directly edit /etc/resolv.conf to add the public DNS servers and make it immutable using chattr +i.

C.Use the 'host' command to force DNS queries to use a specific server.

D.Stop and disable the systemd-resolved service using systemctl.

AnswerA

This ensures netplan configures systemd-resolved to use the specified DNS servers.

Why this answer

Option A is correct because in Ubuntu 20.04, netplan uses systemd-resolved by default, which listens on 127.0.0.53. Setting 'dhcp4-overrides: {use-dns: false}' in the netplan configuration prevents DHCP from overriding the manually specified DNS servers, ensuring that only the public DNS servers (8.8.8.8 and 8.8.4.4) are used for resolution. After applying with 'netplan apply', systemd-resolved will forward queries to those public servers, bypassing the local stub resolver.

Exam trap

The trap here is that candidates often think directly editing /etc/resolv.conf or disabling systemd-resolved is a valid fix, but they fail to understand that netplan and systemd-resolved work together to manage DNS, and the proper way to bypass the local stub is to configure the upstream servers correctly in netplan with DHCP overrides disabled.

How to eliminate wrong answers

Option B is wrong because directly editing /etc/resolv.conf and making it immutable with chattr +i is a fragile workaround that will be overwritten by systemd-resolved or netplan on reboot or reapply, and it does not address the underlying mechanism that manages resolv.conf. Option C is wrong because the 'host' command can specify a DNS server for a single query but does not change the system-wide DNS resolution behavior; users and applications will still use the local resolver. Option D is wrong because stopping and disabling systemd-resolved will break DNS resolution entirely, as netplan relies on it to manage /etc/resolv.conf, and without it, the system may have no working DNS resolver.

Practice this question →

66

MCQmedium

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?

A.The IP address is being matched by a conntrack rule instead.

B.The ACCEPT rule for the IP uses the wrong chain.

C.The DROP rule for port 22 appears before the ACCEPT rule for the IP.

D.The SSH service is listening only on IPv6.

AnswerC

iptables processes rules sequentially; the first match stops processing.

Why this answer

Option C is correct because iptables processes rules in sequential order, and the first matching rule determines the packet's fate. In this rule set, the DROP rule for TCP port 22 is listed second, but since it is the first rule that matches SSH traffic from 192.168.1.100 (the ACCEPT rule matches the source IP but not the destination port, so it does not match SSH packets specifically), the DROP rule is applied before the ACCEPT rule can take effect. The ACCEPT rule for the IP address would only match non-SSH traffic from that IP, while SSH packets are dropped by the subsequent port-based rule.

Exam trap

The trap here is that candidates assume an ACCEPT rule for a source IP will override any subsequent DROP rules, but iptables processes rules in order and the first match wins, so the order of rules is critical.

How to eliminate wrong answers

Option A is wrong because conntrack rules (e.g., -m conntrack --ctstate ESTABLISHED,RELATED) are not present in the given rule set, and connection tracking would not cause a block unless a related rule explicitly references it. Option B is wrong because both rules are in the INPUT chain, which is the correct chain for filtering incoming connections to the local system; the ACCEPT rule for the IP address is correctly placed in the INPUT chain. Option D is wrong because the SSH service listening only on IPv6 would not affect iptables rules for IPv4 traffic; the administrator is connecting from an IPv4 address (192.168.1.100), and iptables rules for IPv4 are independent of IPv6.

Practice this question →

67

MCQmedium

Refer to the exhibit. The output of 'ip addr show' reveals that eth0 is in state DOWN and has no IPv4 address. Which command is most likely to bring the interface up and obtain an IP via DHCP?

A.ip link set eth0 up

B.ifup eth0

C.ip route add default via 192.168.1.1 dev eth0

D.ip link set dev eth0 up

AnswerB

ifup invokes the network configuration scripts, which will start DHCP based on config.

Why this answer

Option B is correct because the `ifup` command is a distribution-agnostic tool that reads the interface configuration from files (e.g., `/etc/network/interfaces` on Debian/Ubuntu or `/etc/sysconfig/network-scripts/ifcfg-eth0` on RHEL/CentOS) and brings the interface up while automatically initiating a DHCP client (e.g., dhclient or dhcpcd) to obtain an IPv4 address. This is the standard way to activate a network interface with its configured addressing method, including DHCP, in a single step.

Exam trap

The trap here is that candidates often assume `ip link set eth0 up` (options A or D) is sufficient to obtain an IP via DHCP, but this command only activates the link layer and does not invoke any DHCP client, leaving the interface without an IP address.

How to eliminate wrong answers

Option A is wrong because `ip link set eth0 up` only changes the interface's administrative state to UP but does not trigger any DHCP client or assign an IP address; the interface will remain without an IPv4 address unless a separate DHCP command is run. Option C is wrong because `ip route add default via 192.168.1.1 dev eth0` adds a default gateway route, but this command requires the interface to already have an IP address and be in the UP state; it does not bring the interface up nor obtain an IP via DHCP. Option D is wrong because `ip link set dev eth0 up` is functionally identical to option A (just a different syntax) and similarly does not initiate DHCP or assign an IP address.

Practice this question →

68

Multi-Selecthard

Which THREE conditions must be met for a Linux system to function as a router between two networks?

Select 3 answers

A.Each interface has an IP address in the respective subnet

B.IP forwarding is enabled (net.ipv4.ip_forward = 1)

C.Both interfaces have the same MAC address

D.iptables rules allow forwarding (FORWARD chain policy or rules)

E.The system is configured as the default gateway for both networks

AnswersA, B, D

The router must have an IP in each network to send/receive packets.

Why this answer

Option A is correct because each interface must have an IP address in its respective subnet for the Linux system to receive packets from that network and forward them to the other. Without an IP address in the subnet, the interface cannot participate in ARP resolution or routing decisions for that network.

Exam trap

The trap here is that candidates often think a router must be the default gateway for both networks, but in reality, it only needs to have IP addresses in each subnet and proper routing entries; the default gateway is a client-side setting, not a router requirement.

Practice this question →

69

Multi-Selectmedium

Which TWO NFS export options ensure that client writes are considered stable only after the data is written to the server's disk? (Choose two.)

Select 2 answers

A./etc/network/interfaces (Debian/Ubuntu style)

B./etc/hostname

C./etc/rc.local

D./etc/sysconfig/network-scripts/ (RHEL/CentOS style)

E./etc/resolv.conf

AnswersA, D

Used by ifupdown, still common on Debian-based systems.

Why this answer

The question asks about NFS export options that ensure client writes are considered stable only after data is written to the server's disk. The correct options are 'sync' and 'no_wdelay', but these are not listed in the answer choices. However, the provided answer options (A and D) are actually configuration files for network interfaces, not NFS export options.

This appears to be a misaligned question; the correct NFS options are 'sync' (forces synchronous writes) and 'no_wdelay' (disables write delay, forcing immediate disk writes). The 'sync' option ensures the NFS server does not reply to a write request until the data is physically written to disk, while 'no_wdelay' prevents the server from delaying small writes to batch them, ensuring each write is committed to disk immediately.

Exam trap

The trap here is that the question lists network configuration files as answer options, which are completely unrelated to NFS export options, testing whether candidates recognize that NFS export options like 'sync' and 'no_wdelay' are specified in /etc/exports, not in network interface configuration files.

Practice this question →

70

Multi-Selectmedium

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

Select 2 answers

A.route -n

B.ip route show

C.ip addr show

D.arp -a

E.ss -tln

AnswersA, B

This is the traditional command to show routing table.

Why this answer

The `route -n` command displays the kernel IP routing table with numeric addresses, showing destination, gateway, netmask, and interface. The `ip route show` command is the modern equivalent from the iproute2 suite, which also displays the routing table with more detailed information. Both are standard tools for viewing routing decisions on a Linux system.

Exam trap

The trap here is that candidates often confuse `ip addr show` (which displays interface addresses) with `ip route show` (which displays routes), or mistake `arp -a` for a routing command because both involve network layer information.

Practice this question →

71

MCQhard

An administrator is configuring a bridge using iproute2. Which command correctly attaches eth0 to bridge br0?

A.ip link set br0 master eth0

B.ip link set eth0 master br0

C.nmcli device modify eth0 master br0

D.brctl addif br0 eth0

AnswerB

This is the correct iproute2 command.

Why this answer

Option B is correct because the `ip link set eth0 master br0` command attaches the physical interface `eth0` as a slave port of the bridge `br0` using the iproute2 suite. The `master` keyword specifies the bridge device that should become the master of the specified interface, which is the standard way to add an interface to a bridge with iproute2.

Exam trap

The trap here is that candidates often confuse the order of arguments in the `ip link set` command, mistakenly using `ip link set br0 master eth0` (Option A) because they think the bridge should be the 'master' of the interface, but the syntax requires the slave interface first followed by `master <bridge>`.

How to eliminate wrong answers

Option A is wrong because it attempts to set `br0` as a slave of `eth0` (i.e., `ip link set br0 master eth0`), which would make the bridge a port of the physical interface—the opposite of the intended configuration. Option C is wrong because `nmcli device modify eth0 master br0` is not a valid nmcli syntax; the correct nmcli command to attach an interface to a bridge is `nmcli connection add type bridge-slave ifname eth0 master br0` or `nmcli device connect eth0 master br0`. Option D is wrong because `brctl addif br0 eth0` is a valid command from the deprecated bridge-utils package, not from iproute2, and the question explicitly specifies using iproute2.

Practice this question →

72

MCQeasy

After configuring the /etc/network/interfaces file as shown, the administrator runs 'ifup eth0'. Which IP address will be assigned to eth0?

A.192.168.1.1

B.192.168.1.100

C.No IP assigned

D.An IP from DHCP

AnswerB

Static IP as configured.

Why this answer

Option B is correct because the configuration in /etc/network/interfaces specifies a static IP address of 192.168.1.100 with the 'address' directive. When 'ifup eth0' is executed, it reads this file and assigns the configured static IP to the interface, ignoring any DHCP settings.

Exam trap

The trap here is that candidates may assume a missing 'dhcp' keyword defaults to DHCP, but the explicit 'static' keyword overrides any implicit behavior, and the 'address' line directly assigns the IP.

How to eliminate wrong answers

Option A is wrong because 192.168.1.1 is not defined in the configuration; the 'address' line explicitly sets 192.168.1.100. Option C is wrong because the configuration includes both an 'address' and a 'netmask' line, so an IP will be assigned. Option D is wrong because the configuration does not include 'iface eth0 inet dhcp'; instead, it uses 'static', so DHCP is not used.

Practice this question →

73

MCQmedium

A company has a server with two network interfaces: eth0 (192.168.1.10/24, gateway 192.168.1.1) and eth1 (10.0.0.10/24, gateway 10.0.0.1). The server needs to reach a remote network 172.16.0.0/16 via a VPN tunnel that terminates at 10.0.0.5 on eth1. Which command should be used to add a route for this traffic?

A.ip route add 172.16.0.0/16 via 10.0.0.5 dev eth1

B.ip route add 172.16.0.0/16 via 10.0.0.5 dev eth0

C.ip route add 172.16.0.0/16 via 192.168.1.1 dev eth0

D.ip route add 172.16.0.0/16 dev eth1

AnswerA

This correctly routes traffic to the VPN endpoint via eth1.

Why this answer

Option A is correct because the VPN tunnel endpoint is at 10.0.0.5 on the eth1 network, so traffic to 172.16.0.0/16 must be forwarded via that next-hop IP address using the eth1 interface. The `ip route add` command with `via 10.0.0.5 dev eth1` explicitly sets the gateway and egress interface, ensuring packets are sent through the VPN tunnel.

Exam trap

The trap here is that candidates often forget to specify the `via` next-hop IP when the destination is not directly connected, or they mistakenly use the default gateway instead of the VPN tunnel endpoint, assuming all external traffic goes through the same gateway.

How to eliminate wrong answers

Option B is wrong because it specifies `dev eth0`, but the VPN tunnel endpoint (10.0.0.5) is not reachable on the 192.168.1.0/24 network; eth0 has no route to 10.0.0.0/24, so the packet would be dropped or misrouted. Option C is wrong because it uses the default gateway 192.168.1.1 as the next-hop, which would send traffic to the local LAN gateway instead of the VPN tunnel endpoint at 10.0.0.5, failing to reach the remote network. Option D is wrong because it omits the `via` parameter; without a next-hop IP, the kernel assumes the destination is directly connected on eth1, but 172.16.0.0/16 is not on the 10.0.0.0/24 subnet, so the route would be invalid and traffic would not be forwarded.

Practice this question →

74

MCQmedium

A system administrator needs to configure bonding in active-backup mode. Which line in /etc/sysconfig/network-scripts/ifcfg-bond0 defines the bonding mode and primary interface?

A.BONDING_OPTS="mode=1 primary=eth0 miimon=100"

B.BONDING_OPTS="miimon=100 mode=active-backup primary=eth0"

C.BONDING_OPTS="mode=0 primary=eth0"

D.BONDING_OPTS="mode=active-backup miimon=100"

AnswerA

This correctly defines mode=1 (active-backup) with primary eth0 and miimon.

Why this answer

Option A is correct because it uses the BONDING_OPTS directive with mode=1 (which corresponds to active-backup mode in Linux bonding) and explicitly specifies the primary interface as eth0. The miimon=100 parameter is also included to enable link monitoring via MII (Media Independent Interface) polling every 100 milliseconds, which is essential for failover detection in active-backup mode.

Exam trap

The trap here is that candidates often confuse the numeric mode values (e.g., mode=1 for active-backup) with the descriptive keywords (e.g., mode=active-backup), or they forget that the primary interface must be explicitly defined in the BONDING_OPTS line to meet the requirement of specifying both the bonding mode and the primary interface.

How to eliminate wrong answers

Option B is wrong because although it specifies mode=active-backup, the correct syntax for the mode parameter in BONDING_OPTS is a numeric value (0-6) or the exact keyword; however, the primary interface is not defined, and the order of parameters is irrelevant, but the missing primary=eth0 makes it incomplete for the requirement. Option C is wrong because mode=0 corresponds to balance-rr (round-robin) mode, not active-backup, and it lacks miimon=100 for link monitoring. Option D is wrong because it correctly uses mode=active-backup and miimon=100 but omits the primary=eth0 parameter, which is necessary to specify which interface should be the active one in active-backup mode.

Practice this question →

75

Multi-Selectmedium

Which THREE are common tools used for network troubleshooting on Linux?

Select 3 answers

A.traceroute

B.fdisk

C.ping

D.tcpdump

E.useradd

AnswersA, C, D

Traces the route packets take to a destination.

Why this answer

A. traceroute is correct because it uses ICMP (or UDP on some systems) to trace the path packets take to a destination, revealing each hop's IP address and round-trip time. This helps identify routing issues, packet loss, or latency bottlenecks in the network path.

Exam trap

The trap here is that candidates might confuse system administration tools (like fdisk and useradd) with network utilities, or incorrectly assume that any command that interacts with the system can be used for network troubleshooting, when only dedicated network diagnostic tools like traceroute, ping, and tcpdump are appropriate.

Practice this question →

Page 1 of 2 · 113 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Networking questions.

Start 20-question session