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.

• ✗

  mkfs.ext4 /dev/sdc1; cryptsetup luksFormat /dev/sdc1; cryptsetup open /dev/sdc1 secret; mount /dev/mapper/secret /mnt

  Why it's wrong here

  This sequence creates an ext4 filesystem directly on /dev/sdc1 before any encryption is established, so all filesystem metadata and data are initially written in plaintext to the raw partition. Running luksFormat afterward only writes a LUKS header over a small portion of the device; it does not automatically encrypt the existing filesystem or erase its remnants, and any data that was written before encryption remains recoverable. The fundamental flaw is that filesystem creation must happen after encryption, on the decrypted mapper device (/dev/mapper/secret), not on the raw block device.

• ✗

  cryptsetup open /dev/sdc1 secret; mkfs.ext4 /dev/mapper/secret; cryptsetup luksFormat /dev/mapper/secret; mount /dev/mapper/secret /mnt

  Why it's wrong here

  The first command, cryptsetup open /dev/sdc1 secret, is invalid on a partition that has not yet been luksFormat'ed; there is no LUKS header to validate against, so the kernel dm-crypt layer cannot create the mapping and the command fails with an error. Even if that step were removed, mkfs.ext4 on /dev/mapper/secret before encryption again writes a plaintext filesystem, and then luksFormat is incorrectly applied to the mapper device rather than the raw /dev/sdc1, which would place a LUKS header on a device that is already supposed to be the decrypted view. The correct workflow requires luksFormat first to initialize the header on the raw partition, then open to create the mapper node.

• ✗

  cryptsetup luksFormat /dev/sdc1; mkfs.ext4 /dev/sdc1; cryptsetup open /dev/sdc1 secret; mount /dev/mapper/secret /mnt

  Why it's wrong here

  This option correctly runs luksFormat on /dev/sdc1, but then mkfs.ext4 is mistakenly executed against /dev/sdc1 itself rather than the decrypted mapping /dev/mapper/secret. Creating a filesystem directly on the encrypted raw partition overwrites the LUKS header, which resides at the beginning of /dev/sdc1, with ext4 superblock and other metadata; this destroys the encryption parameters and the key slots, making it impossible for cryptsetup open to decrypt the volume. After luksFormat, the only valid target for mkfs is the mapper device that appears after a successful cryptsetup open.

• ✗

  cryptsetup open /dev/sdc1 secret; cryptsetup luksFormat /dev/mapper/secret; mkfs.ext4 /dev/mapper/secret; mount /dev/mapper/secret /mnt

  Why it's wrong here

  This sequence attempts cryptsetup open before a LUKS header exists, so the open command cannot validate a passphrase or establish the dm-crypt mapping and will fail outright, leaving /dev/mapper/secret nonexistent. It then compounds the error by running luksFormat on /dev/mapper/secret, which is the wrong device for initializing LUKS — the LUKS header must be written to the raw block device (/dev/sdc1), not to a mapper device that is the decrypted view of an existing mapping. Also, mkfs.ext4 on /dev/mapper/secret is placed after luksFormat, but since the open never succeeded, that mapper node does not exist, so the command cannot succeed either.

• ✓

  cryptsetup luksFormat /dev/sdc1; cryptsetup open /dev/sdc1 secret; mkfs.ext4 /dev/mapper/secret; mount /dev/mapper/secret /mnt

  Why this is correct

  This is the correct sequence. First, cryptsetup luksFormat /dev/sdc1 writes the LUKS header and initial encryption metadata to the raw partition, binding it to a passphrase. Next, cryptsetup open /dev/sdc1 secret authenticates the passphrase and creates /dev/mapper/secret as a decrypted block device that transparently encrypts all writes and decrypts all reads. Then mkfs.ext4 on /dev/mapper/secret creates a normal ext4 filesystem inside the encrypted container, so every filesystem block is stored on /dev/sdc1 in ciphertext; finally, mount /dev/mapper/secret /mnt attaches that decrypted filesystem. The order is essential: format the raw device first, map it, and only then create the filesystem on the mapped device.

Go deeper

Related to this question