23 Troubleshooting: Boot, Storage & Permissions Practice Questions & Answers

1. 1. A dpkg-based server's web service has been failing since early this morning. `journalctl -u nginx -xe` fills the screen with one line repeated: `nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)`. The administrator needs the entry that began the failure sequence rather than the newest one. Which approach finds it?

   • A.Run `journalctl -u nginx -p err --since 05:00` and read the oldest entry in that window first.✓ Answer
   • B.Run `journalctl -xe` again and scroll to the very bottom, since that last line names the root fault.
   • C.Run `journalctl --vacuum-size=100M` first so the unit's older records collapse onto a single page.
   • D.Run `systemctl restart nginx` and read only what appears afterwards, since older records are stale.

   The journal is written chronologically, so the first error in a time window is normally the cause and everything after it is consequence. `-u` limits the output to that unit, `-p err` drops informational noise and `--since` bounds the window, whereas `-xe` deliberately jumps to the newest entry, which here is only the last repetition of the symptom.

   Source: journalctl(1) manual page: --unit, --priority and --since/--until filteringReport a problem with this question

2. 2. A systemd unit is reported as down. `systemctl status billing.service` shows: ``` Active: failed (Result: exit-code) since Tue 03:14:07 UTC; 21min ago Main PID: 1841 (code=exited, status=1/FAILURE) Tue 01:02:55 host systemd[1]: Started Billing API. Tue 03:14:07 host systemd[1]: billing.service: Main process exited, code=exited, status=1/FAILURE ``` What does this evidence establish?

   • A.The unit never ran ExecStart at all, so the program path named in the unit file is wrong and must be corrected.
   • B.The unit started normally and ran for two hours before its process exited failing; read the application's own log.✓ Answer
   • C.The unit is not enabled for boot, so systemd stopped it when the machine switched over to its default target.
   • D.The unit was held back by a Requires= dependency that never came up, so that dependency has to be started first.

   The timestamps separate the two cases: systemd logged `Started` at 01:02 and the main process exited only at 03:14, so startup succeeded and the program died later of its own accord. A unit that fails to start never logs `Started`, and its status names the stage that failed instead of a main PID that exited, so the investigation belongs in the application's runtime log.

   Source: systemctl(1) and systemd.service(5) manual pages: Active state, Result and main process exit reportingReport a problem with this question

3. 3. On an RPM-based server /var is full. `df -h /var` reports 0 available, `df -i /var` reports 6% of inodes used, `du -sh /var/log/*` reports a single 38G file /var/log/app/app.log, `ls /etc/logrotate.d` holds no entry for that application, and `lsof +L1 /var` returns nothing. What does the evidence point to?

   • A.The application's log was never covered by a rotation rule and grew unbounded; add a logrotate configuration for it.✓ Answer
   • B.Inodes are exhausted on /var, so writes fail while blocks stay free; the filesystem has to be recreated.
   • C.A deleted file is still held open by a process, so the space comes back as soon as that process is restarted.
   • D.The journal has outgrown its size limit, so `journalctl --vacuum-size=1G` is what reclaims the space here.

   Each competing cause is ruled out by one piece of the evidence: 6% inode use rules out inode exhaustion, an empty `lsof +L1` rules out a deleted-but-open file, and `du` names an ordinary on-disk log rather than the journal. A log file only stops growing when a rotation rule renames, compresses and expires it, so a file with no entry in /etc/logrotate.d grows until the filesystem fills.

   Source: logrotate(8) manual page: rotation rules in /etc/logrotate.conf and /etc/logrotate.dReport a problem with this question

4. 4. An administrator reviewing a systemd host runs `journalctl -b -p warning`. Which records does that command return?

   • A.Only records logged at exactly warning severity, with error and critical records filtered out.
   • B.Records at warning severity and at every severity more serious than it, up to emergency.✓ Answer
   • C.Only records from units whose unit file sets a warning threshold, for the current boot.
   • D.Records at warning severity and below it, so notice, informational and debug are included.

   `-p` sets a ceiling rather than an exact match: the journal keeps the classic syslog severity scale, where emergency is the most serious and debug the least, and asking for a level returns that level plus everything more serious. `-b` restricts the output to the current boot, which is how an administrator separates this boot's faults from an earlier one's.

   Source: journalctl(1) manual page: --priority and the syslog severity levels it acceptsReport a problem with this question

5. 5. On a dpkg-based server an administrator sets `GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=none"` in /etc/default/grub and reboots, but `cat /proc/cmdline` still shows the old parameters. Why?

   • A.The regeneration command on this family is `grub2-mkconfig -o /boot/grub2/grub.cfg`, and it was not run.
   • B.The generated boot loader configuration was never rebuilt; `update-grub` writes the new setting into it.✓ Answer
   • C.Kernel parameters take effect only after `systemctl daemon-reload` re-reads boot configuration for PID 1.
   • D./etc/default/grub governs rescue entries only; /boot/grub/grub.cfg must be hand-edited for normal ones.

   /etc/default/grub is an input file, not the file the boot loader reads: a generator turns it into the boot loader's own configuration, and until that generator runs the old generated file is still what boots. On a dpkg-based system the wrapper is `update-grub`; the generated file is never hand-edited, because the next regeneration overwrites it.

   Source: GNU GRUB manual and grub-mkconfig(8); the update-grub wrapper on dpkg-based distributionsReport a problem with this question

6. 6. After moving the root filesystem to a new LVM logical volume on an RPM-based server, boot stops with `ALERT! /dev/mapper/vg0-root does not exist. Dropping to a shell!` and an `(initramfs)` prompt. Booted from installation media, the volume and its filesystem are intact. What is the most likely cause and fix?

   • A.The boot menu entry names the wrong device; /boot/grub2/grub.cfg has to be hand-edited to point at it.
   • B.The filesystem on the volume is corrupt; run `xfs_repair` on it from the (initramfs) prompt.
   • C.The initial RAM filesystem lacks what is needed to activate the volume; rebuild it with `dracut --force`.✓ Answer
   • D.The root entry in /etc/fstab uses a device name, not a UUID; correct it with the `blkid` value.

   The prompt itself localizes the failure: the kernel and the initial RAM filesystem loaded and ran, so the boot loader is fine, but the code in that image could not assemble the device holding root. Activating an LVM, RAID or encrypted root needs the matching modules and tools inside the image, and adding that layer after installation requires regenerating the image before the next boot.

   Source: dracut(8) manual page: regenerating the initramfs so required modules are present at bootReport a problem with this question

7. 7. A data disk entry was added to /etc/fstab and the disk was later re-created. The server now boots to `Welcome to emergency mode!`, and the journal shows `Timed out waiting for device /dev/disk/by-uuid/3f2a9c1e-...`, `Dependency failed for /data.` and `Dependency failed for Local File Systems.` What should the administrator do?

   • A.Read the real identifier with `blkid`, correct the /etc/fstab entry, then verify with `mount -a` before rebooting.✓ Answer
   • B.Rebuild the initial RAM filesystem with `dracut --force`, because the mount failed before PID 1 was started.
   • C.Add `noexec,nosuid` to the /data entry so the failing mount is skipped and boot continues to the default target.
   • D.Run `fsck` on the data device from the emergency shell, because emergency mode indicates filesystem corruption.

   Recreating the disk gave it a new identifier, so the entry in the mount table points at something that no longer exists, the local filesystems target fails and PID 1 falls back to the emergency shell. `blkid` reports the identifier the device actually has now, and `mount -a` processes the whole mount table immediately, which is how the correction is proved before a reboot depends on it. The option that keeps an optional device from failing boot is `nofail`, not the hardening options.

   Source: fstab(5) and mount(8) manual pages: device identifiers, the nofail option, and mount -aReport a problem with this question

8. 8. After a kernel update on an RPM-based server, boot ends in `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)`. The GRUB menu still lists the previous kernel and its initramfs. Service must be restored now. What is the first action?

   • A.Select the previous kernel entry in the boot menu to restore service, then investigate the new initramfs.✓ Answer
   • B.Append `systemd.unit=emergency.target` to the new kernel entry to reach a shell and repair the failed units.
   • C.Reinstall the operating system from media, because a panic before PID 1 leaves no configuration to recover.
   • D.Boot the installation media in rescue mode and reset the root password, since the panic blocks authentication.

   This panic happens before userspace exists, so no target, unit or password prompt is reachable and appending a systemd target changes nothing. Package managers keep the older kernel and its matching initial RAM filesystem as menu entries precisely so a bad kernel or a bad image can be rolled back by choosing the previous entry, which restores service and leaves the broken pair available to fix.

   Source: GNU GRUB manual, menu entry selection; Linux kernel root filesystem mount panic messagesReport a problem with this question

9. 9. The root password on an RPM-based server that uses dracut and runs SELinux in enforcing mode is unknown, and no other account has sudo. The administrator has console access at the GRUB menu. Which sequence resets it?

   • A.Boot normally, then run `passwd root` from any user session, because the console counts as a trusted terminal.
   • B.Append `systemd.unit=rescue.target`, then run `passwd` at the shell prompt that the rescue target presents.
   • C.Append `selinux=0`, then blank the second field of the root line in /etc/passwd so no password is required.
   • D.Append `rd.break`, remount /sysroot read-write, `chroot /sysroot`, run `passwd`, then `touch /.autorelabel`.✓ Answer

   Breaking out of the boot before the real root is handed over gives a shell that needs no credentials, and the real root is reachable at /sysroot, which starts read-only and must be remounted read-write before the password file can be changed. Writing that file from the boot environment leaves it with the wrong security context, so the flag file that requests a relabel on the next boot is what keeps the system usable afterwards; the rescue target is no help because it asks for the password that is missing.

   Source: dracut.cmdline(7) manual page (rd.break), passwd(1), and the SELinux /.autorelabel relabel flagReport a problem with this question

10. 10. Mail delivery on a cloud instance fails with `No space left on device`: ``` $ df -h /var/spool Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg0-spool 20G 8.2G 11G 44% /var/spool $ df -i /var/spool Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/vg0-spool 1310720 1310720 0 100% /var/spool ``` What does this evidence show?

    • A.The filesystem was remounted read-only after an I/O error, which the kernel reports as a space error.
    • B.A deleted file is still open, which is why `df` and `du` disagree; space returns when the holder restarts.
    • C.Inodes on that filesystem are exhausted, so no new file can be created although free blocks remain.✓ Answer
    • D.The logical volume has no free extents left, so the filesystem can no longer allocate new data blocks.

    A filesystem tracks blocks and inodes separately, and every file, directory and symbolic link consumes one inode whatever its size, so a spool full of tiny messages can run out of inodes with most of its capacity unused. The `No space left on device` error covers both shortages, which is why `df -i` is the follow-up that tells them apart; on a filesystem whose inode count is fixed at creation the only real cures are deleting files or recreating it larger.

    Source: df(1) manual page: --inodes reporting, and inode allocation fixed at filesystem creationReport a problem with this question

11. 11. /var is full on a dpkg-based server: ``` $ df -h /var /dev/sda3 50G 47G 0 100% /var $ du -sh /var 9.8G /var $ sudo lsof +L1 /var COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME rsyslogd 912 root 7w REG 8,3 39421337600 0 418 /var/log/syslog.1 (deleted) ``` How is the space reclaimed?

    • A.Run `rm -f /var/log/syslog.1` again, because the directory entry survived the first deletion attempt.
    • B.Run `fsck` on /var at the next reboot to correct the block accounting that `df` and `du` disagree on.
    • C.Grow the filesystem with `lvextend -r`, because the usage that `df` reports is genuine and permanent.
    • D.Restart rsyslogd so the deleted file's descriptor is released and the kernel frees those blocks.✓ Answer

    Unlinking a file removes only its directory entry; the inode and its blocks survive as long as any process holds an open descriptor, which is exactly the `NLINK 0` entry that `+L1` is designed to reveal. `df` counts those blocks because the filesystem still owns them while `du` cannot see a file with no name, so the gap closes only when the holding process releases the descriptor by being restarted.

    Source: lsof(8) manual page: +L link-count selection for unlinked open files; unlink(2) semanticsReport a problem with this question

12. 12. Users of /data on an RPM-based server report `Read-only file system` although they own the files and the mode is 0775. `dmesg` ends with: ``` blk_update_request: critical medium error, dev sdb, sector 41945280 EXT4-fs error (device sdb1): ext4_journal_check_start:83: Detected aborted journal EXT4-fs (sdb1): Remounting filesystem read-only ``` What is the cause?

    • A.The directory lost its execute bit, which the kernel reports to writers as a read-only filesystem.
    • B.The kernel met media errors and aborted the journal, so it remounted the filesystem read-only.✓ Answer
    • C.The entry in /etc/fstab carries the `ro` option, so `mount -o remount,rw /data` restores writing.
    • D.An SELinux denial is blocking the writes, and `restorecon -Rv /data` would return the right context.

    A read-only filesystem error is not a permission decision at all: the kernel took the whole filesystem out of write service after the block layer returned a medium error and the journal could no longer be trusted, which is the protective behaviour an error policy of remounting read-only asks for. Permission bits, mount options and mandatory access control would each produce `Permission denied` instead, and the fix here starts with the failing device rather than with the filesystem.

    Source: mount(8) manual page (ext4 errors=remount-ro) and the ext4 administration documentation in the Linux kernel treeReport a problem with this question

13. 13. A storage alert points at md0 on a dpkg-based server: ``` $ cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdc1[2](F) sdb1[0] 2930134016 blocks super 1.2 [2/1] [U_] ``` What does this show, and what comes next?

    • A.Both members are offline and the data is unreachable, so restore the volume from backup before writing.
    • B.The array is resynchronizing after a reboot; wait for the rebuild before touching either member device.
    • C.The metadata version does not match this kernel, so the array must be stopped and reassembled by hand.
    • D.One member is flagged faulty and the mirror runs degraded; confirm with `mdadm --detail` and add a replacement.✓ Answer

    Three details in that line agree: the `(F)` suffix marks the member the kernel failed, `[2/1]` says one of two expected members is present, and `[U_]` draws one device up and one missing. The array is therefore still serving data with no redundancy left, so the correct move is to identify the failed member precisely and add a healthy device so the mirror can rebuild; a resync in progress would instead print a recovery line with a percentage.

    Source: mdadm(8) manual page and the md driver documentation in the Linux kernel tree: /proc/mdstat status fieldsReport a problem with this question

14. 14. On an RPM-based server: ``` $ sudo lvextend -L +5G /dev/vg0/data Insufficient free space: 1280 extents needed, but only 0 available $ sudo vgs VG #PV #LV #SN Attr VSize VFree vg0 1 3 0 wz--n- 99.00g 0 ``` What has to happen first?

    • A.Run `lvextend -r` so the filesystem resizes with the volume, freeing the extents needed.
    • B.Run `xfs_growfs /data` first, since the filesystem must claim space before the volume grows.
    • C.Run `pvresize` on the existing member, reserving further extents from the group metadata.
    • D.Add capacity to the volume group first: `pvcreate` a new device, then `vgextend vg0`, then extend.✓ Answer

    A logical volume can only be extended out of extents that its volume group already holds free, and `VFree` of zero says the group has none to give, so no flag on the extend command can manufacture capacity. The order that adds capacity runs from the bottom up: initialize a new physical volume, join it to the group, then extend the logical volume and grow the filesystem on it.

    Source: lvextend(8), vgextend(8) and pvcreate(8) manual pages: extent allocation within a volume groupReport a problem with this question

15. 15. An RPM-based server logs XFS metadata corruption on /data, an XFS filesystem on /dev/vg0/data. The administrator unmounts /data, runs `xfs_growfs /data` and gets `xfs_growfs: /data is not a mounted XFS filesystem`. What is the correct handling?

    • A.Mount /data first and run `xfs_repair` on the mount point, because the tool needs live metadata to work.
    • B.Run `fsck.xfs /dev/vg0/data`, which performs the full metadata check that `xfs_repair` deliberately skips.
    • C.Repair with `xfs_repair /dev/vg0/data` while it stays unmounted; only growing requires it mounted.✓ Answer
    • D.Shrink the filesystem with `xfs_growfs -D` to drop the damaged region, then grow it again once mounted.

    The two operations have opposite requirements, which is where the mistake comes from: a repair rewrites metadata and must own the filesystem exclusively, so it runs against the device with nothing mounted, while growing is an online operation performed through a mount point on a live filesystem. XFS also grows only in one direction and cannot be shrunk at all, and the `fsck.xfs` helper exists merely to satisfy boot-time checking and does nothing.

    Source: xfs_repair(8), xfs_growfs(8) and fsck.xfs(8) manual pages: mount-state requirementsReport a problem with this question

16. 16. A new volume was partitioned as /dev/sdc1 on a dpkg-based server. `mount /dev/sdc1 /srv/data` returns `mount: /srv/data: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error`, and `blkid /dev/sdc1` prints nothing at all. What is the most likely cause?

    • A.The partition table is MBR and the volume is larger than MBR addresses, so it must be converted to GPT.
    • B.The mount point /srv/data does not exist, and mount reports a missing directory as a bad superblock.
    • C.No filesystem has been created on the partition, so there is no superblock or type for mount to find.✓ Answer
    • D.The kernel module for the filesystem is not loaded, so `modprobe` has to insert it before mounting works.

    The decisive evidence is the silent `blkid`: that tool reports the signature a filesystem writes into its superblock, so no output means no signature and therefore no filesystem on the partition at all. Partitioning only carves out space; a filesystem has to be created on the partition with the appropriate `mkfs` command before any mount can succeed, and a missing mount point produces a different message naming the directory.

    Source: mount(8), mkfs(8) and blkid(8) manual pages: superblock detection and filesystem signaturesReport a problem with this question

17. 17. A member of the analysts group reports a failure: ``` $ ls -l /data/reports/q3.csv -rw-r--r--. 1 root analysts 18422 Sep 2 09:11 /data/reports/q3.csv $ ls -ld /data/reports drw-r-----. 2 root analysts 4096 Sep 2 09:10 /data/reports $ cat /data/reports/q3.csv cat: /data/reports/q3.csv: Permission denied ``` What is the cause?

    • A.The group has no execute permission on the directory, so the path cannot be traversed to the file.✓ Answer
    • B.An SELinux context on the file blocks the read, and `restorecon -v` on that file would repair it.
    • C.The file is world-readable but not group-readable, so the group entry denies members of analysts.
    • D.The immutable attribute is set on the directory, which `lsattr` shows and `chattr -i` would clear.

    On a directory the execute bit means the right to traverse it and resolve a name inside it, and it is separate from read, which only allows listing the names. The group field on the directory here is `r--`, so a member of analysts may list the directory but cannot walk through it, and the file's own generous mode never comes into play; the traversal check applies to every directory along the path.

    Source: chmod(1) manual page and POSIX file permission semantics: directory search (execute) permissionReport a problem with this question

18. 18. On an RPM-based web server with SELinux enforcing, /srv/www/upload is mode 0777 and owned by apache:apache, yet uploads fail with `Permission denied`. /var/log/audit/audit.log contains `avc: denied { write } for pid=2210 comm="httpd" name="upload" scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir`. What is the correct fix?

    • A.Run `chcon -t httpd_sys_rw_content_t` on the directory, the only change that survives the next policy relabel.
    • B.Run `setenforce 0` to stop the denial, and record that setting in /etc/selinux/config so it survives a reboot.
    • C.Record the expected context with `semanage fcontext -a -t`, then apply it using `restorecon -Rv` on that path.✓ Answer
    • D.Widen the mode recursively and add the apache account to the wheel group so that the write is permitted.

    A wide mode with the right owner and a denial anyway is the signature of mandatory access control, and the audit record says exactly which pairing was refused: a process in the web server domain writing to a directory left with a default type. The durable fix names the expected type for that path in the local policy and then relabels the path, because a manual relabel alone is discarded the next time the filesystem is relabelled, and turning enforcement off removes the protection instead of fixing the label.

    Source: semanage-fcontext(8) and restorecon(8) manual pages; SELinux audit AVC denial recordsReport a problem with this question

19. 19. Working as root on an RPM-based server: ``` # echo "nameserver 10.0.0.53" >> /etc/resolv.conf -bash: /etc/resolv.conf: Operation not permitted # lsattr /etc/resolv.conf ----i---------e------- /etc/resolv.conf ``` What explains this, and what clears it?

    • A.The file belongs to another user, so ownership must be corrected with `chown root:root` before writing.
    • B.The immutable attribute is set, and it blocks even root until `chattr -i` removes it from the file.✓ Answer
    • C.An SELinux denial is in effect, and `restorecon -v` on the file returns it to the context policy expects.
    • D.The root filesystem is mounted read-only, and `mount -o remount,rw /` restores write access to the file.

    Two clues rule out the permission model entirely: the error is `Operation not permitted` rather than `Permission denied`, and `lsattr` shows the `i` flag in the attribute string. An immutable file cannot be modified, renamed, deleted or given new links by any user including root, and only a process holding the capability to change file attributes can clear the flag, which is what `chattr -i` does before the edit is retried.

    Source: chattr(1) and lsattr(1) manual pages: the immutable attributeReport a problem with this question

20. 20. The deploy account cannot write a file whose ACL reads: ``` $ getfacl /srv/app/config.yml # owner: root # group: root user::rw- user:deploy:rw- #effective:r-- group::r-- mask::r-- other::r-- ``` What explains it, and what fixes it?

    • A.The named entry was never applied, so `setfacl -m u:deploy:rw` has to be run against the file again.
    • B.A default ACL is missing on the parent, so `setfacl -d -m u:deploy:rw` must be set on that directory.
    • C.The `other` entry overrides named entries, so `chmod o+w` on the file is what grants deploy write.
    • D.The ACL mask caps named entries at read, so raise it with `setfacl -m m::rw /srv/app/config.yml`.✓ Answer

    The mask is an upper bound on every named user entry, every named group entry and the owning group entry, so a granted permission that the mask does not include is recorded but not usable. `getfacl` spells that out with the `#effective:` comment, which here shows write granted to deploy and then stripped by a read-only mask, so raising the mask is what makes the existing grant take effect.

    Source: acl(5) and setfacl(1) manual pages: the mask entry and effective permissionsReport a problem with this question

21. 21. On an RPM-based server a vendor program must run with its owner's privileges, but it runs unprivileged: ``` $ ls -l /opt/tools/bin/netcheck -rwsr-xr-x. 1 root root 48120 Aug 14 10:02 /opt/tools/bin/netcheck $ findmnt /opt TARGET SOURCE FSTYPE OPTIONS /opt /dev/mapper/vg0-opt xfs rw,nosuid,nodev,relatime ``` What is the cause?

    • A.The set-user-ID bit is missing from the program and has to be restored with `chmod u+s` on the file.
    • B.The filesystem is mounted `nosuid`, and that option makes the kernel ignore the set-user-ID bit.✓ Answer
    • C.SELinux is confining the program, and `setsebool -P` on the matching boolean would allow it to run.
    • D.The program sits on XFS, and XFS keeps no set-user-ID bit in the metadata it stores for a file.

    The `s` in the owner field proves the bit is set on the file, so the bit is not what is missing; the decision is being made one level up, at the mount. A filesystem mounted `nosuid` tells the kernel to disregard set-user-ID and set-group-ID bits on everything it contains, which is a deliberate hardening choice, so the program must either move to a mount without that option or the mount must be changed by policy.

    Source: mount(8) manual page: the nosuid mount option and set-user-ID handlingReport a problem with this question

22. 22. Key-based login to an RPM-based server drops back to a password prompt. /var/log/secure records `Authentication refused: bad ownership or modes for directory /home/deploy/.ssh`. `ls -ld` on that directory shows `drwxrwxr-x` and `authorized_keys` shows `-rw-rw-r--`. What should be corrected?

    • A.Generate a longer key pair for the account, because the server rejected the algorithm the client offered.
    • B.Set PasswordAuthentication to no in sshd_config, which makes the server accept the key it just refused.
    • C.Set the directory to 700 and authorized_keys to 600, because StrictModes refuses group-writable paths on the server.✓ Answer
    • D.Add the account to AllowUsers in sshd_config, because the server refuses keys from accounts not listed.

    The log line names the check that failed rather than the key itself: with strict mode checking enabled the server refuses to trust a key file whose directory or ownership could be altered by anyone but the owner, because a group-writable path would let another account install its own key. Tightening the directory and the key file to owner-only access restores the trust, and the fallback to a password prompt is the normal consequence of the key being ignored.

    Source: sshd_config(5) and sshd(8) manual pages: StrictModes ownership and mode checks on ~/.sshReport a problem with this question

23. 23. On an RPM-based server /etc/sudoers.d/devops.conf contains `%devops ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart app`. The file is mode 0440 owned by root, `visudo -c` reports no syntax error, and the user belongs to devops, yet `sudo -l` does not list the rule. What is the most likely cause?

    • A.The file name contains a dot, and sudo skips drop-in names that contain a dot or end in a tilde.✓ Answer
    • B.The group must be written `devops ALL=(ALL)` without the percent sign, which instead marks a host alias.
    • C.NOPASSWD cannot be paired with a specific command path, so the whole rule is parsed and then discarded.
    • D.The rule needs `systemctl daemon-reload` before sudo re-reads the drop-in directory into its own cache.

    The include of the drop-in directory deliberately ignores any file whose name contains a dot or ends with a tilde, so that package backups and editor leftovers cannot silently change privilege rules. The file here is syntactically valid and correctly owned, which is why the syntax checker is happy, but it is never read at all; renaming it without the dot makes the rule take effect and `sudo -l` then lists it.

    Source: sudoers(5) manual page: #includedir and drop-in file names that are ignoredReport a problem with this question

Practice questions written to the published CompTIA Linux+ exam objectives and to standard Linux administration practice. CompTIA and Linux+ are marks of CompTIA, and Linux is a registered trademark of Linus Torvalds; this site is not affiliated with or endorsed by CompTIA. The real exam mixes multiple-choice items with performance-based questions that ask you to carry out a task in a simulated environment — those cannot be reproduced in a four-option format, so this bank covers the knowledge half and you should practise on a real system alongside it. CompTIA revises and version-numbers the objectives periodically: confirm the current objectives, exam code and requirements with CompTIA before testing. About the CompTIA Linux+ certification →