System Architecture practice questions

timed

Why it fails: timed is not a standard time synchronization service.

chronyd

Why it fails: chronyd is a time synchronization service, but ntpd is the traditional choice.

systemd-timesyncd

Why it fails: timesyncd is a lightweight time sync service, but ntpd is more commonly referenced.

udev

Why it fails: udev is a userspace device manager that creates device nodes in /dev once the kernel and initramfs have started; it does not tell the kernel where root is. It is tempting because udev handles block device naming. The root= parameter, supplied by the bootloader, provides the kernel with the root filesystem location.

initramfs

Why it fails: initramfs is a temporary early userspace archive loaded alongside the kernel; it contains modules and scripts that locate and mount the real root filesystem, but the root device is passed to the kernel by the bootloader via the root= parameter. initramfs is essential when root resides on LVM, RAID or encrypted volumes needing drivers.

init

Why it fails: init is the first userspace process, started only after the root filesystem is already mounted; it cannot supply the kernel with the root location. It is tempting because init orchestrates later boot stages. The bootloader, through the root= kernel parameter, is what tells the kernel where root resides.

/etc/modprobe.d/modules.conf

Why it fails: This is for modprobe options, not auto-loading.

/etc/sysconfig/modules

Why it fails: This file is not standard; some distributions use /etc/sysconfig/modules/ but not a single file.

/etc/conf.modules

Why it fails: This is an older configuration file, not commonly used.

sda

Why it fails: sda is the whole disk, not a partition.

sda1

Why it fails: sda1 is mounted as /boot.

sda2

Why it fails: sda2 is swap space.

3 controllers; SSD at 6.0 Gbps

Why it fails: Only two ata ports are shown.

2 controllers; SSD at 3.0 Gbps

Why it fails: SSD speed is 6.0 Gbps, not 3.0.

1 controller; SSD at 6.0 Gbps

Why it fails: There are two ata ports, indicating two controllers or a dual-port controller.

Add the module name to /etc/modules-load.d/ directory.

Why it fails: The /etc/modules-load.d/ directory is read by systemd-modules-load.service, which does not exist as the boot mechanism on a SysV init system, so nothing would read the file. It is tempting because that path is the standard way to load modules at boot on systemd distributions, which would be correct here if the server ran systemd.

Add an install directive in /etc/modprobe.d/ for the module.

Why it fails: An install directive in /etc/modprobe.d/ only alters what command runs when modprobe is invoked for that module; it does not itself trigger loading at boot, so the module still would not load automatically. It is tempting because install directives are genuinely used to run commands alongside module loading, but only once something else requests the module.

Add a blacklist entry for the module in /etc/modprobe.d/blacklist.conf.

Why it fails: Blacklisting prevents modprobe from loading the module at all, which directly contradicts the requirement that it load before network services start. It is tempting because blacklisting is the correct action when a module must be kept unloaded, such as conflicting drivers, but here the module is wanted.

Step 1: Save the current iptables rules to a file. Step 2: Add the SSH allow rule. Step 3: Install and enable iptables-persistent.

Why it fails: This order is incorrect because saving before adding the rule would save an empty or outdated ruleset, missing the new SSH rule.

Step 1: Add the SSH allow rule. Step 2: Install and enable iptables-persistent. Step 3: Save the current iptables rules.

Why it fails: This order is incorrect because installing persistence before saving means the persistence setup may not include the new rule, and saving after persistence might overwrite the persistence configuration.

Step 1: Install and enable iptables-persistent. Step 2: Add the SSH allow rule. Step 3: Save the current iptables rules.

Why it fails: This order is incorrect because setting up persistence before adding the rule will load an empty or previous ruleset on boot, and adding the rule after persistence does not automatically make it persistent unless saved correctly.

lscpu

Why it fails: lscpu shows architecture but also other CPU info; not the only correct answer.

arch

Why it fails: While arch shows architecture, it is not the only correct answer.

uname -m

Why it fails: While uname -m does show architecture, it is not the only correct answer.

vgcreate, pvcreate, lvcreate

Why it fails: VG requires an existing PV to be created first.

pvcreate, lvcreate, vgcreate

Why it fails: Cannot create LV before VG.

lvcreate, vgcreate, pvcreate

Why it fails: Cannot create LV before VG and PV.

Use systemd-modules-load.service

Why it fails: Using systemd-modules-load.service directly is not a standard method; it reads config files. This is not considered best practice.

All of the above are valid methods

Why it fails: All methods are not valid; only adding the module name to /etc/modules or equivalent files is best practice.

Add a line to /etc/modprobe.d/

Why it fails: Adding a line to /etc/modprobe.d/ configures module options, not auto-loading. Modules listed there are not automatically loaded.

Incorrect partition table

Why it fails: Incorrect partition table would cause partition identification errors.

Filesystem corruption

Why it fails: Filesystem corruption usually produces fsck-related messages.

Missing kernel module for the device

Why it fails: Missing module would prevent the device from being recognized.

/sys/kernel/cmdline

Why it fails: Incorrect. /sys/kernel/cmdline displays the current kernel boot parameters but is not used to configure them.

/proc/cmdline

Why it fails: Incorrect. /proc/cmdline shows the kernel parameters of the currently running kernel, not a configuration file.

/boot/grub/grub.cfg

Why it fails: Incorrect. /boot/grub/grub.cfg is the generated boot menu file; it is not directly used to configure kernel parameters.

rescue.target

Why it fails: Rescue.target is a valid systemd target for single-user rescue mode, but it is not one of the three targets asked for in this question.

shutdown.target

Why it fails: Shutdown.target is not a standard systemd target; the correct target for shutdown is poweroff.target. It is incorrect.

fdisk /dev/sdb, then create a new primary partition accepting all defaults

Why it fails: fdisk requires interactive commands; not the quickest single command.

dd if=/dev/zero of=/dev/sdb bs=1M count=1

Why it fails: Zeroes the first megabyte, does not create a partition.

mkfs.ext4 /dev/sdb

Why it fails: Attempts to create filesystem directly on raw disk, not a partition.

The module is blacklisted in /etc/modprobe.d/.

Why it fails: A blacklisted module would produce a different error message, such as 'Module xyz is blacklisted'.

The module has dependencies that are missing.

Why it fails: Missing dependencies would produce an error like 'Module xyz has missing dependencies' or 'Required key not available'.

The module is not installed on the system.

Why it fails: While possible, the error message points to the kernel version-specific path, suggesting a version mismatch rather than a complete absence.

The /dev/sdb1 device file is missing or corrupted.

Why it fails: If the device physically exists, udev creates the device file. The error strongly suggests the path is wrong.

The entry in /etc/fstab has an incorrect filesystem type.

Why it fails: Incorrect filesystem type would produce an error about wrong fs type, not about the device not existing.

The filesystem on /dev/sdb1 is not formatted.

Why it fails: If the device exists but is unformatted, the error would be about a missing filesystem, not 'special device does not exist'.

uname -m

Why it fails: uname -m shows machine hardware name (e.g., x86_64), not full CPU details.

lsusb

Why it fails: lsusb lists USB devices, not CPU info.

cpufreq-info

Why it fails: cpufreq-info shows CPU frequency scaling information, not general CPU info.

The kernel image is not found in /boot.

Why it fails: Incorrect. A missing kernel image would cause a boot failure after GRUB has loaded, not a fallback to the rescue shell.

The BIOS cannot find a bootable device.

Why it fails: Incorrect. If the BIOS cannot find a bootable device, GRUB is never loaded, so no rescue shell is entered.

The initramfs is missing or corrupt.

Why it fails: Incorrect. A missing or corrupt initramfs causes a kernel panic after the kernel is loaded, not a rescue shell fallback.

The /boot/grub/grub.cfg file is missing or corrupt.

Why it fails: Incorrect. A missing or corrupt grub.cfg triggers the GRUB normal shell (command-line prompt), not the rescue shell.

9

Why it fails: 9 is not a standard SysV runlevel.

7

Why it fails: 7 is not a standard SysV runlevel; valid runlevels are 0-6.

Two disks: sda 10.7 GB, sdb 2.15 GB

Why it fails: The output shows 10.0 GiB and 2.00 GiB, not GB. Although marketing sizes may be 10.7 GB and 2.15 GB, the correct values per dmesg are in GiB.

Three disks: sda, sdb, and an unknown device

Why it fails: Only two disks are shown.

One disk: sda 10.7 GB

Why it fails: Two disks are detected: sda and sdb.