EX200 Configure local storage Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  First, run mkswap /dev/sdc1 to format the partition as swap. Then, run swapon /dev/sdc1 to activate it. Finally, add an entry to /etc/fstab to make it persistent across reboots.

  Why this is correct

  This sequence is correct because mkswap must first initialize /dev/sdc1 with a swap signature; without this signature, the kernel cannot recognize it as swap. After formatting, swapon activates the swap area immediately, making it available for use. Only after activation is it safe to add a persistent entry to /etc/fstab, preferably using the filesystem UUID obtained via blkid, so that systemd can automatically enable the swap on subsequent boots.

• ✗

  First, run swapon /dev/sdc1 to activate the swap. Then, run mkswap /dev/sdc1 to format it. Finally, add an entry to /etc/fstab.

  Why it's wrong here

  Running swapon before mkswap is invalid because swapon requires an existing valid swap signature on the device; on a fresh partition, there is no signature, so the command fails. Even if a stale signature were present, mkswap executed afterward would overwrite it, rendering the currently active swap area corrupt and unusable. Consequently, after mkswap completes, the swap is never reactivated before the fstab entry is added, meaning it will not be active until the next reboot at best, and at worst the fstab entry points to a device that is not currently enabled.

• ✗

  First, add an entry to /etc/fstab for /dev/sdc1. Then, run mkswap /dev/sdc1. Finally, run swapon /dev/sdc1.

  Why it's wrong here

  Adding an fstab entry before the partition is formatted as swap is dangerous because systemd reads fstab at boot and attempts to run swapon on /dev/sdc1 before mkswap has created a swap signature. This will cause a swapon failure, potentially delaying boot or dropping the system into emergency mode if swap is marked as required. Although running mkswap and swapon manually afterward can recover the situation, a reboot in the interim will fail to activate the swap, and the fstab entry remains problematic until fixed.

• ✗

  First, run mkswap /dev/sdc1. Then, add an entry to /etc/fstab. Finally, run swapon /dev/sdc1.

  Why it's wrong here

  This is incorrect because the standard order is to activate swap with swapon before editing fstab. While it can work, it is considered a mistake as it may lead to issues if swapon fails and the fstab entry remains.

Go deeper

Related to this question