Linux Foundation Certified System Administrator LFCS (LFCS) — Questions 301–375

Why this answer

How to eliminate wrong answers

Option A is wrong because `free -m` shows overall system memory and swap usage, but the error 'cannot allocate memory' can occur even with plenty of free RAM if a per-process limit is imposed; `free` does not reveal user limits. Option C is wrong because `cat /proc/meminfo` provides detailed kernel memory statistics (e.g., MemTotal, MemFree, Committed_AS) but does not show per-process resource limits enforced by the shell or PAM; it cannot diagnose a `ulimit` restriction. Option D is wrong because `sysctl vm.overcommit_memory` controls the kernel's memory overcommit policy (0=heuristic, 1=always, 2=never overcommit), but the error 'cannot allocate memory' from a service is typically a per-process limit issue, not a system-wide overcommit setting; changing this sysctl is a more advanced step after confirming limits.

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the 'ip route show' output explicitly shows 'default via 10.0.0.1 dev eth0', meaning the default gateway is present in the routing table. Option C is wrong because DNS resolution is not required for a ping to an IP address like 8.8.8.8; the failure occurs at the network layer, not at the application or name resolution layer. Option D is wrong because while a firewall could block ICMP, the question states the server can reach internal resources, and the most likely cause given the routing configuration is a gateway issue; a firewall blocking outbound ICMP would not explain why the gateway itself is unreachable for internet traffic, and the symptom is consistent with a lack of NAT or upstream route on the gateway.

Why this answer

Why this answer

How to eliminate wrong answers

Why this answer

How to eliminate wrong answers

Option A is wrong because 'man grep' displays the manual page for grep, which provides documentation and usage information, not the filesystem location of the binary. Option C is wrong because 'uname -a' prints system information (kernel name, hostname, kernel release, etc.), which is unrelated to locating a command's binary. Option D is wrong because 'grep -r' performs a recursive text search for the string 'grep' within files under /usr/bin, which is inefficient, may return many irrelevant matches, and does not reliably identify the grep binary itself.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a 'socket' unit type is used for socket-based activation (e.g., listening on a TCP port or Unix socket), not for grouping units for boot execution. Option B is wrong because a 'timer' unit type schedules and triggers services based on time or calendar events, not for grouping units during boot. Option C is wrong because a 'service' unit type manages a single daemon or process, not a collection of units; grouping multiple services requires a target.

Why this answer

How to eliminate wrong answers

Option B is wrong because `gzip -d` permanently decompresses the file, replacing `syslog.gz` with an uncompressed `syslog` file, which alters the original compressed archive. Option C is wrong because `gunzip` is equivalent to `gzip -d` and also permanently decompresses the file, removing the `.gz` version. Option D is wrong because `cat` reads raw binary data and will output garbled, unreadable content when applied to a gzip-compressed file, as it does not perform any decompression.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because creating a RAID 0 array with mdadm would require reformatting and moving data, causing downtime, and does not integrate with the existing LVM structure. Option B is wrong because shrinking other logical volumes is risky, may not free up enough contiguous space, and is not the recommended approach when a new physical disk is available. Option D is wrong because backing up and recreating the entire LVM stack is unnecessarily disruptive, requires downtime, and is not needed when LVM supports online extension with `xfs_growfs`.

Why this answer

How to eliminate wrong answers

Option A is wrong because /dev/sda2 is usually reserved for the root filesystem or swap, not the boot partition, and using it would conflict with standard partitioning conventions. Option B is wrong because /dev/sda1 is a valid partition that can serve as the boot filesystem, so 'None of the above' is incorrect. Option D is wrong because /dev/sda3 is typically an extended partition or a logical volume container, not the primary boot partition, and it may not be directly bootable.

Why this answer

How to eliminate wrong answers

Option A is wrong because the 'ip' command only makes runtime changes that are lost on reboot; it has no persistent flags to save configuration. Option C is wrong because while ifcfg files are still read by NetworkManager for backward compatibility, Red Hat deprecates direct editing in RHEL 8 and recommends nmcli or nmtui instead. Option D is wrong because systemd-networkd is not the default or recommended network stack in RHEL 8; RHEL 8 uses NetworkManager, not systemd-networkd.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `ls -lh /` lists the contents of the root directory with sizes in human-readable format, but it does not show disk usage of the filesystem itself—it only shows file and directory sizes, which is not the same as filesystem capacity or usage. Option C is wrong because `fdisk -l /` is used to manipulate or display the partition table of a disk device (e.g., `/dev/sda`), not to show filesystem disk usage; passing `/` as an argument is invalid and will produce an error. Option D is wrong because `du -sh /` calculates the total disk usage of all files and directories under `/` (i.e., the entire filesystem tree), but it does not show the filesystem's total capacity or available space; it also takes significantly longer to run and is not the intended command for checking filesystem-level disk usage.

Why this order

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because being in the root group does not grant any special file access; group membership only matters if the file's group permissions allow access, and /etc/passwd is typically world-readable (644), so group membership is irrelevant. Option B is wrong because the immutable attribute (chattr +i) prevents modification or deletion of a file, not reading; a user can still read an immutable file if they have read permission. Option C is wrong because /etc/passwd typically has permissions 644 (rw-r--r--), meaning all users have read permission; the 'Permission denied' error in this context is not due to missing read permission on the file itself.

Why this answer

How to eliminate wrong answers

Option A is wrong because `gzip file.txt` compresses the file and, by default, deletes the original `file.txt`, leaving only `file.txt.gz`. Option B is wrong because `gzip -d file.txt.gz` decompresses the archive, which does not compress a file and also removes the `.gz` file unless `-k` is used. Option C is wrong because `gzip -1 file.txt` sets the compression level to fastest (level 1), but still removes the original file; the `-1` flag does not affect file preservation.

Why this answer

How to eliminate wrong answers

Option A is wrong because `cryptsetup luksOpen` is used to map an existing LUKS container to a device mapper name (e.g., /dev/mapper/encrypted_device), not to create a new encrypted container. Option C is wrong because `openssl enc` performs file-level encryption using a cipher like AES-256-CBC, but it does not create a LUKS container or handle block device encryption with proper metadata; it would produce an encrypted file, not a usable encrypted block device. Option D is wrong because `dm-crypt create` is not a valid command; the correct tool for device-mapper encryption is `cryptsetup`, and the syntax `dm-crypt create` does not exist in standard Linux utilities.

Why these pairings

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `systemctl show default` is not a valid systemctl subcommand; `systemctl show` is used to display properties of a unit (e.g., `systemctl show sshd.service`), not to retrieve the default target. Option B is wrong because `systemctl list-default` does not exist; the correct subcommand for listing targets is `systemctl list-units --type=target`, which shows all loaded target units, not the default one. Option D is wrong because `systemctl default` is a valid command but it changes the current target to the default target (i.e., it activates the default boot target), not displays it.

Why this answer

How to eliminate wrong answers

Option A is wrong because `Restart=on-success` triggers restarts only when the service exits with a zero exit code (success), which is the opposite of a crash condition. Option C is wrong because `Restart=always` restarts the service regardless of the exit status, including when the administrator manually stops it with `systemctl stop`, which is not desired for crash-only recovery. Option D is wrong because it only sets `RestartSec=10` without specifying a `Restart=` directive, so the default `Restart=no` applies and the service will never restart automatically.

Why this answer

How to eliminate wrong answers

Option A is wrong because cfdisk is a curses-based partition editor that, by default, operates on MBR partition tables and does not natively support GPT without additional flags or a separate version (like cgdisk). Option B is wrong because fdisk traditionally uses MBR and, although newer versions (util-linux 2.23+) can handle GPT, it is not the recommended or primary tool for GPT on a 2TB disk; its default behavior and legacy association with MBR make it a poor choice for this specific requirement. Option D is wrong because sfdisk is a script-oriented tool for dumping and restoring partition tables, not an interactive partitioner for initial setup; while it can handle GPT, it is not the standard interactive tool a sysadmin would use to partition a new disk.

Why this answer

How to eliminate wrong answers

Option A is wrong because `ls -lS /var/log` lists files sorted by size, but it does not recurse into subdirectories, so it will miss large files in subdirectories like /var/log/journal or /var/log/nginx. Option B is wrong because `find /var/log -size +100M` only finds files larger than 100 MB, but the /var partition could be full due to many smaller files accumulating to fill the space, and it does not sort or prioritize the largest files. Option D is wrong because `df -h /var/log` shows the disk usage of the /var/log filesystem (or partition), not the sizes of individual files, so it cannot identify which files to delete.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `systemctl reenable sshd` is not a valid systemd command; the correct command to re-enable a service is `systemctl enable sshd` (which removes and recreates symlinks if already enabled). Option B is wrong because `systemctl mask sshd` prevents the service from being started manually or automatically by linking it to `/dev/null`, which is the opposite of what is needed. Option C is wrong because `systemctl start sshd` starts the service immediately but does not configure it to start automatically at boot; it only affects the current runtime state.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `lvcreate -L 100G -n thinvol vg1` creates a standard (thick) logical volume, not a thin logical volume, and does not reference a thin pool. Option B is wrong because `lvcreate -s vg1/pool1 -n thinvol` is used to create a snapshot, not a thin logical volume; the `-s` flag creates a snapshot of an existing logical volume. Option D is wrong because `lvcreate -L 100G -T vg1/pool1 --name thinvol` uses the `-L` flag to specify the size, but for thin volumes, the `-V` flag must be used to define the virtual size; `-L` is for the pool's metadata or data size, not the thin volume's virtual size.

Why this answer

How to eliminate wrong answers

Option A is wrong because it uses `--permanent`, which would make the rule persistent across reboots but does not apply it to the current runtime configuration unless followed by `firewall-cmd --reload`; the question asks to allow traffic without affecting existing rules, and `--permanent` alone does not activate the rule immediately. Option B is wrong because it adds both `--add-service=http` (which opens port 80/tcp) and `--add-port=8080/tcp`, unnecessarily opening an extra port (80) that was not requested, violating the requirement to allow only port 8080. Option D is wrong because it targets the `public` zone, but the internal interface eth1 is assigned to the `internal` zone, so this command would open port 8080 on the wrong interface and not affect eth1.

Why this answer

How to eliminate wrong answers

Option B is wrong because `systemctl set-default` sets the default target (e.g., `multi-user.target` or `graphical.target`), not a service; it controls which target the system boots into, not individual service autostart. Option C is wrong because `systemctl daemon-reload` reloads systemd manager configuration after unit file changes but does not enable or disable any service for boot-time startup. Option D is wrong because `systemctl start` immediately starts a service in the current session but does not configure it to start automatically at future boots.

Why this answer

How to eliminate wrong answers

Option A is wrong because the DHCP server's IP address (192.168.1.1) is in the same subnet as the clients (192.168.1.0/24), so subnet mismatch is not the issue. Option C is wrong because the problem states the dhcpd service is running and listening on UDP port 67, so the service is operational. Option D is wrong because the switch blocking broadcast packets would prevent DHCPDISCOVERs from reaching the server, but the tcpdump shows DHCPDISCOVER packets are being sent, and no firewall rules are blocking traffic, so the switch is not the cause.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the ARP table is only relevant for hosts on the same subnet; 10.0.0.1 is not on the local subnet (the server's IP is presumably in 192.168.1.0/24), so ARP will never contain an entry for it. Option B is wrong because the question asks for the next step in investigating the connectivity issue from the server's perspective; while the remote host's firewall could block ICMP, the administrator should first verify the path with traceroute before assuming a firewall issue. Option D is wrong because the remote host is clearly not in the same subnet (10.0.0.1 vs. 192.168.1.0/24), and the successful ping to the gateway confirms the server is correctly forwarding traffic to the default route.

Why this answer

How to eliminate wrong answers

Option A is wrong because an SSH key not being authorized would generate a 'Failed publickey for <valid_user>' message, not 'invalid user'. Option B is wrong because a locked account (e.g., via `passwd -l` or expired password) would produce a 'Failed password for <valid_user>' or 'Authentication failure' log entry, not 'invalid user'. Option D is wrong because an expired password triggers a password change prompt or a 'Password expired' message during authentication, and the log would still reference a valid username, not 'invalid user'.

Why this answer

How to eliminate wrong answers

Option A is wrong because filesystem fragmentation does not cause a discrepancy between 'du' and 'df'; fragmentation affects performance, not space accounting. Option B is wrong because reserved blocks for root (default 5% on ext4) are counted as used by 'df' but are not the cause of a 98% full partition when only 2 GB is used; reducing the reserved percentage would free space but does not explain the discrepancy. Option C is wrong because 'du -sh /data' already counts all files including hidden files (dot files) by default; the '-sh' option sums the total size, and hidden files are included in that total.

Why this answer

How to eliminate wrong answers

Option A is wrong because the syntax `mdadm /dev/md0 --add /dev/sdc1` omits the required `--manage` or device mode flag; `mdadm` expects either a mode (like `--manage`) or a direct command option before the device name, and this ordering can cause a parsing error or unintended behavior. Option C is wrong because `mdadm --manage /dev/md0 --add /dev/sdc1` is technically valid but redundant — the `--manage` mode is implied when using `--add`, and the LFCS exam expects the simpler, standard form `mdadm --add /dev/md0 /dev/sdc1` as the correct answer. Option D is wrong because `mdadm --re-add` is used to re-add a disk that was previously part of the array and has been removed but not failed (e.g., after a temporary disconnection); it does not apply to a new replacement disk that was never part of the array.

Why this answer

How to eliminate wrong answers

Option A is wrong because `ls -lihrt` includes `-i` (inode number) and `-h` (human-readable sizes), which are not requested, and while it sorts by time and reverses, it lacks `-a` so hidden files are omitted. Option C is wrong because `ls -lat` sorts by modification time but newest first, not oldest first, as the `-r` flag is missing. Option D is wrong because `ls -lrt` sorts by time and reverses to oldest first, but it lacks `-a`, so hidden files are not listed.

Why this answer

How to eliminate wrong answers

Option A is wrong because `systemctl daemon-reload` reloads the systemd manager configuration after unit files have been changed, but it does not enable a service to start at boot. Option C is wrong because `systemctl reenable` removes and then recreates the enablement symlinks, which is useful for resetting the enablement state but is not the standard command for initially enabling a service. Option D is wrong because `systemctl start` immediately starts the service in the current session but does not configure it to start automatically at boot.

Why this answer

How to eliminate wrong answers

Option A is wrong because logrotate configuration affects log rotation and compression, not process termination causes; it would not help diagnose why myapp was killed. Option B is wrong because strace captures system calls of a running process, but myapp has already crashed and cannot be traced without reproducing the issue first; this is a premature step before confirming the root cause. Option C is wrong because enabling core dumps and reproducing the issue is useful for debugging segmentation faults or other signals (e.g., SIGSEGV), but SIGKILL cannot be caught or handled by the process, so no core dump is generated; this step would be ineffective here.

Why these pairings

Why this answer

How to eliminate wrong answers

Option B (tune2fs -l /dev/sdb1) is wrong because tune2fs is an ext2/ext3/ext4 filesystem tuning tool; while it can display the UUID in its output, it only works on ext2/3/4 filesystems and will fail or produce no UUID for other types like XFS or Btrfs. Option C (df -h /dev/sdb1) is wrong because df reports disk space usage for mounted filesystems, not UUIDs; it shows mount points and capacity, not block device attributes. Option D (lsblk /dev/sdb1) is wrong because lsblk lists block devices and their partitions, but by default it does not display UUIDs unless the -f or -o UUID option is used; without those flags, it shows only device names, sizes, and mount points.

Why this answer

How to eliminate wrong answers

Option A is wrong because `nl` numbers lines and outputs the entire file to stdout without pausing, so it is not suitable for viewing one screen at a time. Option B is wrong because while `more` does display content one screen at a time, it only allows forward navigation (space bar) and cannot scroll backward, making it less flexible than `less` for interactive viewing. Option C is wrong because `cat` concatenates and outputs the entire file to stdout at once, which will flood the terminal and is not designed for paging.

Why this answer

How to eliminate wrong answers

Option B (SIGTERM, signal 15) is wrong because it is the default polite termination signal that the process can catch and ignore, which is exactly why it failed to kill the hung process. Option C (SIGINT, signal 2) is wrong because it is typically generated by Ctrl+C and can be caught or ignored by the process, making it ineffective for a hung process. Option D (SIGHUP, signal 1) is wrong because it is primarily used to notify a process of terminal disconnection or to reload configuration, and it can also be caught or ignored, so it will not force termination.

Why this answer

How to eliminate wrong answers

Option A is wrong because `find /var -size +100M` omits `-type f`, so it will also match directories and other non-regular files that happen to have a size attribute, potentially cluttering results or causing unintended matches. Option B is wrong because `-size +100MB` uses an invalid suffix; `find` accepts `c` (bytes), `k` (kilobytes), `M` (megabytes), `G` (gigabytes), but not `MB` — this will cause a syntax error or be ignored. Option C is wrong because `ls -lh /var | grep '100M'` only matches lines containing the literal string '100M', missing files like '200M' or '1.5G', and it does not recursively search subdirectories; it also fails to handle files with sizes formatted differently (e.g., '101M' would not match).

Why this answer

How to eliminate wrong answers

Option A is wrong because bad blocks are handled by the device mapper or LVM at the block level, not by the filesystem; `mkfs.xfs` does not mark bad blocks as unusable during creation. Option C is wrong because the volume group having insufficient physical extents would prevent the logical volume from being created at all, not reduce its capacity after creation. Option D is wrong because the `noatime` mount option affects access time updates and performance, not the reported filesystem capacity.

Why this answer

How to eliminate wrong answers

Option A is wrong because removing the default gateway on eth0 would break all other outbound traffic that must go through eth0 (e.g., internet access), leaving the server without a default route. Option B is wrong because policy routing is an overcomplicated solution for this simple scenario; it involves creating additional routing tables and rules, which is unnecessary when a single static route can solve the problem. Option D is wrong because changing the default gateway metric to prefer eth1 would route all default traffic through eth1, which is likely not desired (eth1 is for database access only), and it would not fix the specific routing for 10.0.0.10 without affecting other traffic.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because chmod 755 adds execute permission for the owner, group, and others, not just the owner. Option B is wrong because chmod 755 does not remove write permission for others; it sets the others permission to r-x (read and execute), which already excludes write, but the command is not specifically removing write—it is setting the entire permission triad. Option C is wrong because the setuid bit is set using chmod 4xxx (e.g., chmod 4755), not chmod 755, which uses the octal value 0 for the setuid/setgid/sticky bits.

Why this answer

How to eliminate wrong answers

Option B is wrong because policy routing (ip rule and multiple routing tables) is overkill for a simple destination-based routing requirement; it is typically used for complex scenarios like load balancing or source-based routing, not for a single static route. Option C is wrong because setting a lower metric on the default route for eth0 would only affect the default route preference, not direct traffic specifically to 10.1.0.0/16; it would not create a route for that network. Option D is wrong because bonding combines interfaces for redundancy or increased throughput, not for routing traffic to a specific network; it does not control which interface is used for a particular destination.

Why this answer

How to eliminate wrong answers

Option B is wrong because `vm.swappiness` controls the kernel's tendency to swap anonymous memory to disk; a value of 100 makes the system swap aggressively, which would cause disk I/O and latency, not high CPU usage by Nginx workers directly. Option C is wrong because `net.core.somaxconn` limits the backlog of pending TCP connections; a low value would cause connection refused errors under load, not high CPU usage or memory exhaustion. Option D is wrong because `kernel.pid_max` sets the maximum PID number; a low value would prevent new processes from starting, not cause existing Nginx workers to consume high CPU or memory.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because `systemctl mask httpd` creates a symlink to /dev/null, which prevents the service from being started manually or automatically, even by dependencies, and is not temporary — it requires unmasking to reverse. Option C is wrong because `systemctl disable httpd` removes the symlinks that cause the service to start at boot, permanently altering its enablement state until re-enabled. Option D is wrong because `systemctl kill httpd` sends a signal (default SIGTERM) to the service's control group, but it is not the standard command for stopping a service; it is used for sending arbitrary signals or killing specific processes, and it does not manage the service's unit state or dependencies properly.

Why this answer

How to eliminate wrong answers

Option A is wrong because it uses `gateway` instead of `gateway4`; Netplan requires `gateway4` for IPv4 gateways. Option B is wrong because it uses `address` (singular) instead of `addresses` (plural list), and `dns-nameservers` is a legacy ifupdown syntax not valid in Netplan. Option C is wrong because it omits the required `version: 2` field, which Netplan mandates for the configuration to be recognized.

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because it lacks the `-n` flag, so line numbers are not displayed. Option B is wrong because it uses `-i` and `-n` but omits `-w`, so it will match substrings (e.g., 'error404') and produce false positives. Option C is wrong because it uses `-w` and `-n` but omits `-i`, so it will not match uppercase variants like 'Error' or 'ERROR'.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `find / -type f -size +100M` only finds files larger than 100 MB, missing smaller files that could collectively consume significant space, and it does not sort or summarize results. Option B is wrong because `ls -lR / | sort -k5 -rn` is extremely slow on a full filesystem, produces a massive unsorted list, and does not aggregate sizes per directory, making it impractical for identifying the largest space consumers. Option C is wrong because `find / -type f -exec du -sh {} \;` runs `du` on every single file individually, which is extremely slow and inefficient compared to using `du` on directories to get aggregated sizes.

Why this answer

Why this answer

How to eliminate wrong answers

Option A (BindsTo=app.service) is wrong because BindsTo creates a stronger dependency where web.service would be bound to the lifecycle of app.service, and if app.service fails or stops, web.service would be forcefully stopped and could not be started independently; this is too restrictive for a frontend that should only restart when the backend restarts, not be permanently tied. Option C (Requires=app.service) is wrong because Requires only ensures that app.service is started when web.service starts, but it does not cause web.service to restart when app.service restarts; it only activates the dependency at startup. Option D (Wants=app.service) is wrong because Wants is a weaker form of Requires that does not enforce any restart behavior; it merely attempts to start app.service alongside web.service but does not propagate restarts or stops.

Why this answer

How to eliminate wrong answers

Option B is wrong because `netstat -r` displays the routing table, which is unrelated to DNS resolution; it would not help diagnose why domain names fail to resolve. Option C is wrong because `traceroute 8.8.8.8` tests network path connectivity to an IP address, which is already working per the user's report, and does not involve DNS. Option D is wrong because `ping google.com` would fail due to the same DNS resolution issue, making it useless for diagnosis; it would not reveal whether the problem is with DNS or something else.

Why this answer

How to eliminate wrong answers

Option A is wrong because eth1 having no gateway is not the cause of the failure to reach 8.8.8.8; the default route is already set via eth0, and eth1 is only used for local subnet traffic. Option C is wrong because DNS resolution is not involved in a direct ping to an IP address (8.8.8.8), so a DNS failure would not prevent the ping. Option D is wrong because eth0 is up (ping to 10.0.1.1 succeeds), so the interface is operational.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a crash does not disable the service; disabling is a separate administrative action using `systemctl disable`, which only affects boot-time behavior, not runtime restart policy. Option C is wrong because systemd's `Restart=on-failure` directive explicitly instructs the init system to restart the service automatically upon crash, so it does not remain stopped. Option D is wrong because systemd does not send alerts by default; while it can log the event via journald, alerting requires additional configuration (e.g., custom scripts, monitoring tools, or `OnFailure=` unit dependencies).

Why this answer

How to eliminate wrong answers

Option A is wrong because it adds a rule to the OUTPUT chain (which handles outgoing traffic) and uses `--sport 8080` (source port), which would match outgoing packets originating from port 8080, not incoming connections. Option C is wrong because the FORWARD chain handles traffic routed through the system, not traffic destined for the local host; adding a rule there would not affect incoming connections to the local system. Option D is wrong because it uses `-j DROP` to reject traffic, and while `-I INPUT 1` inserts the rule at the top, the action is to drop, not accept, the incoming TCP connections on port 8080.