Test yourself

Linux essentials

Final exam · 54 questions · answers explained as you pick

Linux, the shell and the filesystem

8 questions

01strace -e trace=openat cat /etc/hostname shows a line for /usr/share/coreutils/locales/cat/en-US.ftl ending in "= -1 ENOENT (No such file or directory)", yet cat prints web01 and the trace ends with "+++ exited with 0 +++". How do you read that?

Acat failed, and web01 came from a copy of the file held in a cache

Incorrect — The openat on /etc/hostname returned 3, a file descriptor, and cat read the real file. Exit status 0 confirms the run worked.

BThe kernel ran out of file descriptors and refused one of the opens

Incorrect — Running out of descriptors is a different error. ENOENT means nothing exists at that path.

Ccat looked for an optional message file, found it missing, and carried on

Correct — One refused openat matters only if the program needs that file; cat opened /etc/hostname (= 3) and finished with status 0.

DThe Rust coreutils package is damaged and needs reinstalling with apt

Incorrect — Programs probe for optional files all the time. The trace shows cat finishing normally, so nothing points at a damaged package.

02You need a command that lists block devices, but you do not know its name. Which help source can find it for you?

Aapropos, which searches the one-line descriptions of the manual pages

Correct — apropos "list block devices" printed lsblk (8), the command you were after.

Bman -f, which takes a description and returns the matching commands

Incorrect — man -f needs a page's exact name and lists the sections it appears in, as man -f passwd did. It does not search descriptions.

Chelp, which prints a summary of the programs installed on the server

Incorrect — help describes commands built into bash, such as cd and export, not programs on disk.

D--help given without a command name, which lists every installed tool

Incorrect — --help is an option of a particular command. With no command in front of it there is nothing to ask.

03An old script starts with #!/bin/bash. On Ubuntu 26.04, ls -l / shows "bin -> usr/bin". Which program runs the script?

AA small copy of bash kept in /bin so that old scripts keep working

Incorrect — /bin holds no files of its own: the l at the start of its line marks a symbolic link.

BNone, because the usr merge removed /bin and the script now fails

Incorrect — The path still works. The link exists so that paths such as /bin/bash stay valid.

CWhichever bash comes first in the PATH of the user who starts it

Incorrect — A #! line with a full path is used as written; PATH is searched only for names without a slash.

D/usr/bin/bash, reached through the /bin link into /usr

Correct — Since the usr merge, programs live under /usr, and /bin, /sbin and /lib are links kept so old paths resolve.

04ls -l /proc/sys/kernel/hostname shows a size of 0, yet cat on the same file prints web01. Why?

AThe name is stored in a compressed form that ls cannot measure

Incorrect — Nothing in /proc is stored or compressed. The size is 0 because there is no stored data at all.

BThe kernel builds the content at the moment the file is read

Correct — /proc and /sys are the kernel's live view presented as files; they take no disk space and show a size of 0.

CIt is a symbolic link to /etc/hostname, where the text really lives

Incorrect — The line starts with -, a regular file, not l. The kernel generates /proc; it does not link into /etc.

DFiles under /proc are cached in RAM, and ls counts only bytes on disk

Incorrect — There is no copy anywhere, in RAM or on disk. The kernel writes the text out each time a program reads the file.

05deploy made /tmp/cmd-files-link, a symbolic link to a file in deploy's home. cat /tmp/cmd-files-link works for deploy, but sudo cat /tmp/cmd-files-link prints "Permission denied", and /proc/sys/fs/protected_symlinks contains 1. Why is root refused?

Asudo-rs refuses to open symbolic links, the same way sudoedit does

Incorrect — sudoedit refuses to edit links, but sudo cat simply runs cat as root. The refusal came from the kernel when cat opened the link.

BThe kernel will not follow another user's link in a sticky shared directory

Correct — With protected_symlinks at 1, a link in /tmp is followed only by its owner or the directory's owner, which blocks the classic /tmp link attack.

CThe target sits in a home directory with mode 0750, which root may not read

Incorrect — root is not bound by permission bits, so the home directory's mode does not stop it. The link is the problem.

D/tmp is mounted nosuid, which stops root reading the files stored there

Incorrect — nosuid makes the kernel ignore set-user-ID bits. It does not limit what root may read.

06A cleanup script runs rm -rf "${BUILD_DIR:?}"/* and stops with "BUILD_DIR: parameter null or not set". What was deleted?

AEverything under /, because the empty variable turned the path into /*

Incorrect — That is what the unprotected rm -rf "$BUILD_DIR"/* would have done. The :? form exists to stop it.

BThe files in the current directory, which the leftover * matched

Incorrect — The shell stopped before it built any path, relative or absolute.

CNothing yet, since rm asks for confirmation when its path looks wrong

Incorrect — rm -rf never asks. The protection comes from the shell, not from rm.

DNothing: the shell stopped at the empty variable before rm started

Correct — ${VAR:?} makes the shell stop with an error when the variable is empty or unset, so the command is never run.

07You leave tail -f /var/log/app.log running overnight. The application kept logging, but after the log was rotated at midnight no new lines appeared and tail printed no warning. What happened, and what should you have run?

Atail kept watching the renamed file, which stopped growing; use tail -F

Correct — tail -f follows the file it opened, which rotation renamed to app.log.1. tail -F follows the name and opens the new file when it appears.

BRotation deleted the file tail was reading and killed tail; use less instead

Incorrect — tail was still running, watching a file nobody wrote to any more. less pressed into follow mode with F behaves like tail -f.

CThe application stopped logging at midnight; restart it and run tail again

Incorrect — The application kept logging, to the new app.log. The follow was on the wrong file.

Dtail -f holds output back until Ctrl-C; add -n 0 so lines appear as they arrive

Incorrect — tail -f prints each new line as it is written. -n only sets how many old lines are shown first.

08On a Rocky Linux 10 server you add an sshd drop-in with a typo and run sudo systemctl reload sshd without testing it. On Ubuntu 26.04 the same mistake leaves the old settings in force. What can happen on RHEL?

ANothing, because RHEL's reload also runs sshd -t and refuses the file

Incorrect — RHEL's sshd.service has no test step; its ExecReload only sends the hangup signal.

BThe reload is refused until systemctl daemon-reload picks up the drop-in

Incorrect — daemon-reload re-reads unit files. sshd reads its own configuration when it is told to reload.

Csshd restarts itself on the hangup, cannot start, and the listener is gone

Correct — With no test step, HUP makes sshd start again with the broken file; it fails, and new logins are refused until the file is fixed.

DOpen sessions are closed at once, while new logins keep the previous settings

Incorrect — Existing sessions carry on after a reload. It is the listener for new connections that is lost.

8 questions · explanations appear as you answer

Working in the shell

9 questions

01To sort a host list in place you run sort hosts.txt > hosts.txt. Afterwards wc -c hosts.txt prints 0. What happened?

AThe shell emptied hosts.txt for > before sort read it

Correct — Redirections are set up before the command starts, so sort read an empty file. Use sort -o, or write a new file and rename it.

Bsort needs -u before it writes anything when the input has duplicates

Incorrect — sort writes every line by default; -u only drops duplicates. The input was already empty when sort read it.

Csort cannot read and write one file, so it stopped with an error first

Incorrect — sort never knew about the output file, because the shell opened it. It read an empty file without any error.

DThe file was locked while sort read it, so the shell threw the output away

Incorrect — Nothing locked the file. The shell cut it to zero bytes when it set up the redirection.

02ls -l /etc/hostname /etc/nope | wc -l prints the "cannot access" error on the screen and then 1. You want wc to count the error line too. Which command does that?

Als -l /etc/hostname /etc/nope | wc -l 2>&1

Incorrect — This redirects wc's own stderr. The error from ls still bypasses the pipe.

Bls -l /etc/hostname /etc/nope 2>/dev/null | wc -l

Incorrect — This throws the error away, and wc still counts 1.

Cls -l /etc/hostname /etc/nope 2>&1 | wc -l

Correct — 2>&1 points ls's stderr where its stdout goes, into the pipe, so wc counts 2. |& is the short form.

Dls -l /etc/hostname /etc/nope > wc -l

Incorrect — > writes ls's output to a file named wc, and -l is passed to ls as one more option. Nothing is counted.

03As deploy you run find /etc -name "sshd_config*". It prints /etc/ssh/sshd_config.d and /etc/ssh/sshd_config among several "Permission denied" lines, and exits with status 1. How should you read the result?

AThe search failed, so neither of the two printed paths can be trusted

Incorrect — The two paths are real matches. The status reports that part of the tree was not searched, not that the results are wrong.

BThe matches are real, but unreadable directories may hold more

Correct — find exits 1 when part of the tree could not be searched, so an ordinary user's answer may be incomplete; sudo searches everything.

CStatus 1 means no regular file matched, only the directory did

Incorrect — find's status reports errors during the walk, not the number of matches. /etc/ssh/sshd_config is a regular file.

DThe quotes around the pattern caused the errors and should be dropped

Incorrect — Quoting is correct: it stops the shell expanding the pattern. The errors name directories deploy may not open.

04grep 192.0.2.1 allowlist.txt prints three lines: 192.0.2.1 gateway, 192.0.2.10 backup and 192.0.2.100 monitoring. Which command prints only the gateway line?

Agrep -i 192.0.2.1 allowlist.txt

Incorrect — -i ignores case, which digits do not have. The two extra matches remain.

Bgrep "192.0.2.1$" allowlist.txt

Incorrect — $ anchors the pattern at the end of the line, and every line ends with a name, so nothing matches.

Cgrep -c 192.0.2.1 allowlist.txt

Incorrect — -c counts matching lines and prints 3. It does not narrow the match.

Dgrep -Fw 192.0.2.1 allowlist.txt

Correct — -F makes the dots plain dots, and -w requires the address to stand as a whole word, so 192.0.2.10 no longer matches.

05On the sample access log, grep -c 401 access.log prints 41, but awk '$9 == 401' access.log | wc -l prints 40. Which count of refused requests is right?

A41, because awk skips lines that have fewer than ten fields

Incorrect — Every line of this log has the same fields, and awk tested field 9 on all 81 of them.

B41, because awk compares the status as text and misses some forms of it

Incorrect — The status field holds the number and nothing else. awk's count is the accurate one.

C40, because grep also matched a 200 response whose size was 4012

Correct — grep matches 401 anywhere on the line, and one successful page was 4012 bytes long. awk tests the status field only.

D40, because grep -c also counts the header line at the top of the log

Incorrect — An access log has no header line. The extra match is a line that contains 401 somewhere else.

06In the sample log, awk shows 40 refused logins (status 401) from 198.51.100.23, one every five seconds. The same address then has one POST /login answered with 302. What should you conclude, and do next?

AA password was probably accepted; find the account in the application's log

Correct — A login form usually answers a correct password with a redirect, so treat that account's password as known.

BThe client gave up and was sent to an error page, so no action is needed

Incorrect — After forty refusals, assuming the redirect is harmless ignores how login forms usually answer success.

CThe attack failed, because a successful login would have returned a 200

Incorrect — Looking for 200 misses the usual success signal. A redirect after a POST to /login is typically an accepted password.

DThe 302 is a caching effect, so report only the 401 lines to the team

Incorrect — 302 is the answer the server chose for that request. Leaving it out hides the one line that matters.

07A directory holds notes.txt and a file named -l. ls * prints one long-format line for notes.txt and never lists -l. Which command lists both names?

Als "*"

Incorrect — Quoting stops the expansion, so ls looks for a file literally named *.

Bls -a *

Incorrect — -a adds dotfiles; the expanded -l is still read as an option.

Cls *.txt -l

Incorrect — This matches only notes.txt, and -l is the long-format option again.

Dls -- *

Correct — -- ends the options, so the -l that follows is a file name; ls ./* works too.

08deploy has ~/bin at the front of PATH and a script there named uptime. What runs when deploy types sudo uptime?

AThe script in ~/bin, as root, because sudo keeps the caller's PATH

Incorrect — sudo replaces PATH with secure_path from /etc/sudoers, so your own directories are not searched.

B/usr/bin/uptime, because sudo looks it up in secure_path

Correct — sudo and sudo-rs both search secure_path, a fixed list of root-owned directories.

CNothing, because sudo refuses a name found in two PATH directories

Incorrect — sudo does not look for duplicates. It searches its own list and runs the first match there.

DThe script in ~/bin, but as deploy, since sudo drops root for home files

Incorrect — sudo does not change user because of where a file lives, and it never looks in ~/bin.

09A nightly job on a shared Ubuntu 26.04 server runs mysql -pSecret to take a backup. Another ordinary user, with no sudo rights, says they saw the password. How?

Aps shows other users' command lines, arguments included, while they run

Correct — /proc/PID/cmdline is readable by everyone because /proc is mounted without hidepid, so a password on the command line is visible while the job runs.

BAny user may read /proc/PID/environ for every process on the machine

Incorrect — environ is readable only by the process's owner and root, as cat /proc/1/environ showed. Command lines are not protected that way.

Cmysql copies its options to /var/log/syslog, which every account can read

Incorrect — /var/log/syslog is readable only by its owner and the adm group, and the password did not need a log to leak.

DThe job's ~/.bash_history is world-readable by default on Ubuntu 26.04

Incorrect — A job does not write shell history, and home directories on Ubuntu 26.04 are mode 0750.

9 questions · explanations appear as you answer

Permissions and ownership

7 questions

01report.txt is -rw-rw-r--. You run chmod u+x,go-w report.txt. What does ls -l show afterwards?

A-rwxrw-r--

Incorrect — go-w removes write from the group as well, so the group's w would be gone.

B-rwxr-xr-x

Incorrect — u+x adds execute for the owner only; the group and others gain nothing.

C-rw-r--r--

Incorrect — This misses u+x: the owner gains execute.

D-rwxr--r--

Correct — The owner gains x, the group and others lose w, and every other switch keeps its value.

02On a server that holds customer data you set umask 027 in your shell. What modes do touch and mkdir give a new file and a new directory?

AFile 644, directory 755

Incorrect — That is the result of umask 022, which makes new files world-readable.

BFile 640, directory 750

Correct — The umask clears group write and all of the others bits: 666 becomes 640 and 777 becomes 750.

CFile 750, directory 640

Incorrect — Files start from 666 and never gain execute from the umask; directories start from 777.

DFile 664, directory 775

Incorrect — That is Ubuntu's login umask 0002, which withholds only write from others.

03To give a team access to an existing tree under /srv, why run sudo chmod -R g+rwX,o-rwx rather than sudo chmod -R 2770?

AX sets execute on every file, but for the group alone, not the owner

Incorrect — X is selective: regular files that are not already executable gain nothing.

BX keeps the setgid bit on the directories that already carry it

Incorrect — X concerns execute, not setgid. setgid is added to directories separately, with find -type d.

CX adds execute to directories and to files that already have it

Correct — Data files do not become executable, while directories get the x they need to be entered.

DX extends the change to hidden files, which -R by itself would skip

Incorrect — chmod -R already includes dotfiles. X decides which entries get execute.

04sudo find /srv/ess-own-app -xdev $ -nouser -o -nogroup $ -ls prints a line for orphan.dat showing 1504 1504 where the owner and group names should be. What does that tell you?

ANo account or group with the number 1504 exists on this machine

Correct — find and ls print a name when they can look the number up; a bare number means the account was deleted or the file came from elsewhere.

BThe file belongs to root, and 1504 is its size in bytes, printed twice

Incorrect — The size has a column of its own (2 here). The two 1504 columns are the owner and the group.

Cfind prints raw numbers for every file whenever it runs with -xdev

Incorrect — -xdev only keeps find on one filesystem. Files with known owners show their names.

DThe account exists but is locked, so find hides its name

Incorrect — Locking changes /etc/shadow, not the name lookup. A locked account's name is still shown.

05You add bob to the devs group with sudo usermod -aG devs bob. In the SSH session bob already had open, id does not list devs, and he still gets "Permission denied" in the team directory. What is the fix?

ARun usermod again with plain -G, which applies the group at once

Incorrect — -G without -a replaces bob's supplementary groups, and it still does not change a running session.

BGive the team directory mode 777 so that the group check is not needed

Incorrect — That opens the directory to every account on the machine, which the shared group was meant to avoid.

CRestart the SSH service so that it rereads /etc/group for open sessions

Incorrect — Existing sessions keep the group list they were given at login; restarting sshd does not change them.

Dbob logs out and in again, since group membership is read at login

Correct — A new login gets the new list; shells that are already open keep the one they started with.

06After chmod 4644 on a file, ls -l shows -rwSr--r--. What does the capital S mean?

AThe SUID bit is live, and the program runs as the file's owner

Incorrect — That is the lowercase s, as in -rwsr-xr-x. The capital S appears when execute is off.

BThe file is a socket, which ls marks with an S in the permissions

Incorrect — The file type is the first character, here -, a regular file. The S sits in the owner's execute position.

CThe SUID bit is set, but without execute it has no effect

Correct — Nothing can run elevated when the owner cannot execute the file at all; the file is simply misconfigured.

DThe setgid bit is set on this file instead of the SUID bit

Incorrect — setgid shows in the group's execute position. This letter is in the owner's.

07getcap -r /usr/bin shows /usr/bin/ping cap_net_raw=ep, and ping has no SUID bit. Why is that the better design?

Aping then runs as root only for the moment it waits for a reply

Incorrect — A capability never makes ping root. It grants one privilege for the whole run.

Bping gets the one privilege it needs rather than root's identity

Correct — cap_net_raw lets it open a raw socket and nothing more, so a flaw in ping cannot become a root shell.

CCapabilities still work on nosuid mounts, where SUID bits are ignored

Incorrect — The reverse is true: nosuid makes the kernel ignore file capabilities as well as SUID and SGID bits.

DOnly root can run ping now, which stops ordinary users sending packets

Incorrect — Any user can still run ping; the capability is what lets it open a raw socket without being root.

7 questions · explanations appear as you answer

Users and privilege

6 questions

01On a server you have just inherited, the UID 0 check awk -F: '($3 == 0) {print $1}' /etc/passwd lists a second account, backup, besides root. What does that mean?

Abackup has UID 0, so it is a second superuser

Correct — Root is defined by UID 0, not by the name, and an extra UID 0 account is a classic backdoor that needs explaining.

Bbackup is a system account whose files all belong to root

Incorrect — The check prints accounts whose own UID is 0, not accounts that own root's files. System accounts have their own low UIDs.

Cbackup has an empty password, which awk shows as the value 0

Incorrect — Field 3 is the UID. Empty passwords are found in field 2 of /etc/shadow.

Dbackup is in the root group, which gives it read access and no more

Incorrect — The primary group is field 4. A 0 in field 3 means the account is root itself.

02You create a user on Ubuntu 26.04 with sudo useradd -m carol. When carol logs in, the arrow keys print odd characters and there is no command history. Why?

Auseradd skipped /etc/skel, so carol has no .bashrc to set things up

Incorrect — -m creates the home directory and copies /etc/skel into it. The shell is the difference.

Bcarol is not in the sudo group, so bash starts her in a restricted mode

Incorrect — Group membership does not choose the shell, and no restricted mode is tied to sudo.

CHome directories made with -m are mode 0750, which blocks the history file

Incorrect — 0750 gives the owner full access, so carol can write her own history.

Duseradd gives new accounts /bin/sh on Ubuntu 26.04; pass -s /bin/bash

Correct — useradd -D shows SHELL=/bin/sh, and Ubuntu's sh has no history or arrow-key editing; create users with -s /bin/bash or fix it with usermod -s.

03In /etc/shadow a service account has * in the password field, and a former employee's entry starts with !$y$. What do these mean?

A* accepts any password, and ! marks an account that has expired

Incorrect — * means no usable password, not any password. Expiry lives in the expire field, set with chage -E.

B* means no usable password was set; a ! before a hash means locked

Correct — $y$ marks a yescrypt hash, and passwd -l adds the ! that disables password logins.

C* hides the hash from ordinary users, and ! marks a yescrypt hash

Incorrect — /etc/shadow is already unreadable to ordinary users. The algorithm marker is $y$, and ! is a lock.

DBoth mean the account cannot log in at all, SSH keys included

Incorrect — Neither affects key logins: a locked password still lets an SSH key in. Expiring the account blocks every method.

04sudo visudo -cf ~/bad-rule prints "syntax error: fully qualified path needed" with a caret under the command in ess-sudo-ops ALL=(root) systemctl restart ess-sudo-app.service. What do you change?

AAdd NOPASSWD: in front, because sudo-rs needs a tag before any command

Incorrect — Tags are optional. The caret points at the command, which has no path.

BPut the command in quotes, because sudo-rs splits unquoted arguments

Incorrect — Commands in sudoers are not quoted. The caret points at a command with no path.

CWrite the command with its absolute path, /usr/bin/systemctl

Correct — sudo-rs requires every command in a rule to be fully qualified, so a bare name is refused before the file is installed.

DInstall the file first, since visudo -cf cannot check a new file

Incorrect — -cf exists to check a candidate file before it is installed. Installing a broken file is what it prevents.

05The service account ess-sudo-svc must be able to read /etc/ess-sudo/app.conf, and you want to prove it before the service starts. Which command tests exactly that?

Asudo -u ess-sudo-svc cat /etc/ess-sudo/app.conf

Correct — The read happens as the service account, with its groups, so you get the answer the service will get.

Bsudo cat /etc/ess-sudo/app.conf

Incorrect — That reads the file as root, which bypasses the very check you want to test.

Cls -l /etc/ess-sudo/app.conf

Incorrect — ls shows the owner and mode, which you then have to interpret; nothing is read as the service account.

Dsu - ess-sudo-svc -c "cat /etc/ess-sudo/app.conf"

Incorrect — su asks for the target account's password, which a service account does not have. sudo -u needs none.

06For routine administration, why is sudo COMMAND, repeated for each task, preferred to working in a root shell opened with sudo -i?

Asudo -i asks for root's password, which Ubuntu does not set

Incorrect — sudo -i asks for your own password like any sudo command. su - is the one that wants the target's password.

Bsudo -i is refused by sudo-rs, so it works on RHEL alone

Incorrect — sudo-rs supports sudo -i, which starts root's login shell.

CCommands typed inside sudo -i do not run with full root rights

Incorrect — A root shell has every root right, which is exactly what makes it risky.

DEach sudo command leaves its own log line with your name

Correct — Inside a root shell the log records only that the shell started; everything after runs with full rights and no record of its own.

6 questions · explanations appear as you answer

Processes and services

9 questions

01A monitoring check shows the zombie count on a server rising from 1 to 400 over a week, all with the same parent PID. What is the right fix?

Akill -9 each zombie, since the KILL signal cannot be ignored

Incorrect — A zombie has already exited, so there is nothing left to kill; it is an entry waiting to be collected.

BFix or restart the parent, which is not collecting its children

Correct — A zombie goes away when its parent collects its status, or when the parent exits and PID 1 adopts and collects it.

CAdd memory, because each zombie keeps its memory until it is reaped

Incorrect — A zombie uses no CPU and no memory, only an entry in the process table.

DReboot straight away, because the zombies are using all the CPU time

Incorrect — Zombies use no CPU. A reboot hides the bug in the parent until the count builds up again.

02ps -o pid,user,unit,cmd shows a runaway worker in app-worker.service. You kill -9 it, and seconds later the same command is running again with a new PID. Why, and what should you do instead?

AKILL only pauses a process; send TERM to end it for good

Incorrect — KILL ends a process at once. The new PID belongs to a new process that something else started.

BThe kernel restarts processes killed by signal 9; use kill -15

Incorrect — The kernel never restarts a process. systemd, which supervises the unit, did.

Csystemd started the unit's process again; use systemctl to stop it

Correct — A process in a service is supervised by systemd, and a unit with Restart= starts it again; stop the service, then investigate.

DAnother user started it again, so lock their account with passwd -l

Incorrect — ps showed the same unit, so the service manager restarted it, not a login.

03You want to end the rsync jobs that the user bob started, and nothing else. What do you run before any pkill?

Apgrep -a -u bob -x rsync, to read exactly what would match

Correct — -u limits the match to bob, -x to the exact name, and -a prints each command line so you can check the list first.

Bpgrep rsync, since pkill matches whole names in any case

Incorrect — pgrep and pkill match part of a name by default, as the pattern ssh caught both an ssh-agent and an sshd-session.

Ckill -l rsync, which lists the PIDs of every running rsync process

Incorrect — kill -l lists signal names and numbers; it does not look for processes at all.

Dpkill -KILL -u bob, so that none of the jobs can ignore the signal

Incorrect — That signals every process bob owns, his shell included, with no preview and no chance to clean up.

04A batch job's wrapper logs "exit status: 137". What does that number tell you?

AThe job ran out of disk space, which the shell reports as 137

Incorrect — A full disk shows as "No space left on device" from the program itself. 137 is how the shell reports a signal.

BThe job received TERM and shut down cleanly on its own

Incorrect — TERM without a handler gives 143 (128 plus 15); a handled TERM gives whatever the program chose.

CThe command was not found, so the job never started at all

Incorrect — That is 127, the shell's status for a name it could not find.

DIt was ended by KILL (128 plus 9) with no chance to clean up

Correct — A person, systemd's stop timeout or the out-of-memory killer forced it; journalctl -k and the unit's log say which.

05free -h on the lab server shows total 3.8Gi, used 540Mi, free 765Mi, buff/cache 2.7Gi and available 3.3Gi. A colleague says new programs can get only 765 MiB. What is the better estimate?

AAbout 765 MiB, because cached file data cannot be handed back

Incorrect — Most of the cache is released as soon as a program needs the memory; that is why available is higher than free.

BAbout 3.3 GiB, the kernel's estimate in the available column

Correct — available counts free memory plus the cache the kernel can reclaim without swapping, and it is the number to read.

CAbout 3.8 GiB, because with no swap the total is what counts

Incorrect — The total includes memory that programs already use. With no swap, available matters more, not less.

DAbout 3.4 GiB, adding the free and buff/cache columns together

Incorrect — Not all cache can be reclaimed, and the kernel already does this sum properly in available.

06What is the difference between systemctl disable NAME and systemctl mask NAME?

Adisable removes the boot link; mask also blocks starts by hand

Correct — A disabled unit can still be started by hand or by another unit; a masked one fails every start with "Unit ... is masked" until you unmask it.

Bdisable stops the service now, while mask applies from the next boot

Incorrect — disable does not stop a running service, and mask blocks every start from that moment, not just at boot.

CThey do the same; mask is an older name kept for compatibility

Incorrect — They differ: after mask, sudo systemctl start rsync failed with "Unit rsync.service is masked".

Dmask deletes the packaged unit file, and unmask downloads it again

Incorrect — mask puts a link to /dev/null in /etc/systemd/system that hides the packaged file. Nothing is deleted or downloaded.

07To change a service's command you write a drop-in holding [Service] and a single line, ExecStart=/usr/bin/python3 -m http.server 9090. After the reload, systemd refuses the unit. What is missing from the drop-in?

AA reboot, because systemd reads drop-in files only at boot time

Incorrect — Drop-ins are read at every daemon-reload, and systemctl edit reloads for you.

BA copy of the [Unit] section, which every drop-in has to repeat

Incorrect — A drop-in holds only the lines it changes, in their own sections.

CAn empty ExecStart= line first, to clear the inherited command

Correct — ExecStart= adds to a list; the empty assignment clears the main file's command so the drop-in's is the only one.

DA Restart= line, because a drop-in resets the unit's restart policy

Incorrect — Settings the drop-in does not mention keep their values from the main file.

08After an unexpected reboot you need the previous boot's logs. journalctl -b -1 finds nothing, journalctl --list-boots lists only the current boot, and this minimal image has no /var/log/journal directory. What happened?

Ajournalctl needs sudo to show earlier boots, even to members of adm

Incorrect — Members of adm and systemd-journal read every boot the journal holds. The earlier boot was never kept.

Blogrotate deleted the older journal files at its first rotation

Incorrect — logrotate handles the text logs. journald manages its own files.

CThe crash corrupted the journal, as happens after every crash

Incorrect — A journal stored on disk keeps earlier boots across crashes and reboots. Here nothing was written to disk.

DWithout that directory the journal lived in /run, in memory, and was lost

Correct — With Storage=auto (RHEL's default), journald writes to disk only if /var/log/journal exists; otherwise it uses /run/log/journal, which a reboot empties.

09A crontab line reads * * * * * echo "ran at $(date +%H:%M)" >> $HOME/cron/percent.log. journalctl -t CRON shows CMD (echo "ran at $(date +), and percent.log never appears. What is wrong?

Acron runs /bin/sh, which does not support $( ) substitution

Incorrect — /bin/sh supports $( ). The command was cut short before any shell saw it whole.

Bcron's PATH has no date command, so the substitution fails

Incorrect — date is in /usr/bin, which is in cron's PATH from /etc/environment.

Ccron ends the command at the first %; write it as \%

Correct — cron turns the first % into the end of the command and sends the rest as input, so the shell received an unfinished line.

DThe log shortens long lines for display, and the job ran normally

Incorrect — percent.log never appeared, so the job did not run as written. The CMD line shows what cron passed on.

9 questions · explanations appear as you answer

Storage and networking

9 questions

01You need to detach /mnt/ess-data. sudo umount /mnt/ess-data answers "target is busy", and sudo fuser -vm /mnt/ess-data lists deploy with ACCESS F.... and COMMAND app.sh. What do you do?

ARun umount again from sudo -i, since busy means too little privilege

Incorrect — umount already ran as root. Busy means a process is using the filesystem.

BStop the app.sh service, which has a file open there, then unmount

Correct — F is a file open for writing; once the process stops or moves elsewhere, umount succeeds.

CRun e2fsck on the device first, because busy means the filesystem is dirty

Incorrect — e2fsck must not run on a mounted filesystem, and busy is about processes, not damage.

DDelete the open file, which releases the mount straight away

Incorrect — The process keeps the deleted file open, so the mount stays busy and the space stays used.

02Why do /etc/fstab lines name filesystems with LABEL= or UUID= rather than device names such as /dev/vdb1?

ADevice names need root to read, while labels are readable by any user

Incorrect — Both are readable. The difference is whether the name stays attached to the filesystem.

Bsystemd reads UUIDs at boot and ignores lines that use device names

Incorrect — Device names work in fstab. They are just unreliable.

CLabels mount faster, because the kernel can skip probing the disk

Incorrect — The label or UUID still has to be found on a device, so speed is not the reason.

DThe kernel names disks in the order it finds them, which can change

Correct — Adding or removing a disk can renumber devices, while a label or UUID is stored in the filesystem and moves with it.

03A server has a VPN interface as well as eth0, and you need to know which way traffic to 9.9.9.9 leaves. Which command answers that directly?

Aip route get 9.9.9.9

Correct — It prints the route the kernel would pick, with the gateway, the interface and the source address.

Bping -c 2 9.9.9.9

Incorrect — ping shows whether replies come back, not which interface or gateway the packets used.

Cip -br address

Incorrect — This lists the addresses on each interface; it says nothing about the route to a destination.

Dss -tnp state established

Incorrect — This lists connections in progress, and only once one exists.

04A new server should be at 192.0.2.99 on your local network. nc -zv -w 5 192.0.2.99 8080 prints "No route to host", and ping shows "From 192.0.2.1 icmp_seq=1 Destination Host Unreachable". What is the most likely cause?

AA firewall on the new server drops the packets sent to port 8080

Incorrect — A dropping firewall gives a timeout, and ping would still get replies from a running host.

BNothing listens on port 8080 yet on the new server

Incorrect — A missing listener gives "Connection refused", which needs a host that answers.

CNo machine answered for that address on the local network

Correct — No host replied to the ARP request for 192.0.2.99, so it is down, not configured yet, or has another address.

DThe name did not resolve, so nc never learned which address to use

Incorrect — An IP address needs no name lookup. A resolution failure says "Could not resolve" or "Name or service not known".

05On Ubuntu 26.04, /etc/resolv.conf lists only nameserver 127.0.0.53. Where do you see the DNS server your queries actually go to?

AIn /etc/hosts, where cloud-init records the upstream server

Incorrect — /etc/hosts maps names to addresses. It does not name DNS servers.

BIn /etc/nsswitch.conf, on the hosts line after the word dns

Incorrect — nsswitch.conf lists the sources in order (files dns); it names no servers.

CNowhere else, because 127.0.0.53 is the upstream server itself

Incorrect — 127.0.0.53 is systemd-resolved's stub listener on the loopback interface, which forwards the queries.

DIn resolvectl status, on the Current DNS Server line

Correct — systemd-resolved takes the queries on 127.0.0.53 and forwards them to the servers it learned, here from DHCP.

06dig @9.9.9.9 dnssec-failed.org returns status: SERVFAIL, with "EDE: 7 (Signature Expired)". What does that tell you?

AThe name does not exist, which is what SERVFAIL reports

Incorrect — A missing name is NXDOMAIN. SERVFAIL means the resolver could not produce a trustworthy answer.

BThe resolver rejected the domain's DNSSEC signatures and gave no answer

Correct — Quad9 validates DNSSEC, the signatures had expired, and it refused to answer; the fix lies with the domain's operators.

CYour own resolver is down, so no DNS server answered the query

Incorrect — 9.9.9.9 answered with a status and an extended error. A server that does not answer gives "no servers could be reached".

DThe record sits in a cache with an expired TTL, and flushing fixes it

Incorrect — Signature Expired is about DNSSEC signatures, not the TTL, and flushing your cache does not change Quad9's validation.

07Why should you forward your SSH agent with ssh -A only to servers you trust?

ARoot on that server can use your keys while you are connected

Correct — The forwarded agent signs for whoever can reach its socket on the server, and root there can.

BForwarding copies your private key file into the server's ~/.ssh

Incorrect — The key never leaves your machine; the agent signs requests sent back through the connection, which is still enough for misuse.

CThe agent sends your passphrase to the server each time you log in

Incorrect — The passphrase unlocks the key on your own machine and is never sent anywhere.

DA forwarded agent turns off host key checking for the next hops

Incorrect — -A does not change host key checking; each connection still checks known_hosts.

08You meant to copy the contents of webapp into backup01:webapp/, but the dry run rsync -avn webapp backup01:webapp/ lists webapp/, webapp/config/ and so on. What would the real run have done?

AThe same as with webapp/, because rsync ignores a trailing slash

Incorrect — The trailing slash on the source is exactly what changes the result.

BRefused to run, because the destination directory already exists

Incorrect — rsync merges into an existing destination; it does not refuse.

CCopied the directory itself, creating webapp/webapp/ on the backup

Correct — Without a slash the source directory is copied into the destination; webapp/ means its contents.

DDeleted the backup's files first, because -n turns on --delete

Incorrect — -n is a dry run and changes nothing. Only --delete removes files, and it was not given.

09dpkg --verify ncdu prints ??5?????? /usr/bin/ncdu and exits with status 0. What does the line mean?

AThe file is fine, and 5 is the number of checks that passed

Incorrect — dpkg prints only files that differ, and the 5 is in the checksum position.

BThe file's checksum no longer matches what the package installed

Correct — 5 marks a checksum mismatch and the question marks are checks dpkg does not make; the status is 0 either way, so read the output.

CThe package has 5 pending updates, as apt list --upgradable would show

Incorrect — dpkg --verify compares files on disk with dpkg's records. It knows nothing about updates.

DThe file was deleted, and dpkg will restore it at the next upgrade

Incorrect — A missing file is reported as missing. This one exists with different contents.

9 questions · explanations appear as you answer

Putting it together

6 questions

01After a restore, ts-inventory.service fails with "cannot create /var/lib/ts-inventory/starts.log: Permission denied". namei -l shows drwxr-xr-x root root for the ts-inventory directory, and sudo -u ts-inventory touch on the same file is refused. What is the fix?

ARun the service as root by removing User= from the unit file

Incorrect — That trades a permission error for a service with full root rights; the directory's owner is what changed.

BGive /var/lib/ts-inventory mode 777 so that every account can write there

Incorrect — That lets every account on the machine write the service's state.

CRun systemctl reset-failed, since the error is left over from the restore

Incorrect — The denial is current: the touch as ts-inventory fails right now. Nothing changes until the owner is fixed.

Dchown the directory back to ts-inventory, or set StateDirectory=

Correct — The restore recreated it as root; returning ownership fixes it, and StateDirectory= makes systemd set the owner at every start.

02After you remove a drop rule, curl -sS http://app01.internal:8080/ changes from "(28) Connection timed out" to "(7) Failed to connect to app01.internal port 8080 after 2 ms: Could not connect to server". What do you check next?

AWhether anything listens on 8080 on app01: ss -tln, then the unit

Correct — A refusal within milliseconds means app01 answered and nothing listens on the port; check the listener and the service behind it.

BThe firewall again, since error 7 means a second drop rule remains

Incorrect — A drop rule produces a timeout. An answer within 2 ms means the host replied.

CDNS, because error 7 means the name resolved to the wrong address

Incorrect — Name resolution failures are error 6. The name resolved and the host answered.

DThe application's own log, since the service answered with an error

Incorrect — An application answer would be an HTTP response. Error 7 means no connection was made.

03A manager reports "the site is down". Following the troubleshooting method, what do you establish before you look at any layer?

AWhich firewall rules changed today, since most outages are network changes

Incorrect — Changes come after the symptom and scope, and they are not limited to firewalls.

BWhether a reboot fixes it, because that rules out most causes quickly

Incorrect — A reboot destroys evidence, such as running processes and a journal kept in memory, and fixes nothing that caused the failure.

CThe exact failing command and message, and how widely it fails

Correct — A copied symptom and its scope (one client or all, one server or several, since when) tell you where to start.

DThe server's load average, since slow servers cause most reports

Incorrect — Resources are one layer among several; checking them first is guessing.

04Looking for what holds space on /srv/ts-data, sudo lsof +L1 /srv/ts-data also lists systemd, PID 1, with /memfd:systemd-udevd (deleted). Should you restart it?

AYes: every deleted file that is still open holds disk space until its process restarts

Incorrect — That memfd lives in memory, not on this disk, so restarting PID 1 would free nothing here.

BNo: +L1 by itself matches deleted files anywhere; add -a for the mount

Correct — lsof combines its selections with "or" unless -a is given, so lsof +aL1 /srv/ts-data lists only files on that filesystem.

CNo: systemd's files are never really deleted, so the line is a display error

Incorrect — The file really is deleted. It is an in-memory file that has nothing to do with this disk.

DYes, by rebooting the server, since PID 1 cannot be restarted any other way

Incorrect — Nothing about this line calls for a reboot. The process holding space on this disk is ts-applog.

05On a fresh Ubuntu 26.04 cloud server, sudo sshd -T prints permitrootlogin prohibit-password and passwordauthentication no. What do those two lines allow?

ANobody may log in as root, and every user has to type a password

Incorrect — prohibit-password still lets root in with a key, and passwordauthentication no turns password logins off.

Broot may log in with a password, but from the console alone

Incorrect — prohibit-password forbids root's password logins over SSH; sshd has no say over the console.

CEvery account, root included, may use either a password or a key

Incorrect — passwordauthentication no disables password logins for every account.

DKeys are required for everyone, and root may log in with a key

Correct — The cloud image turns password logins off in 60-cloudimg-settings.conf, and root is limited to keys.

06On a default Ubuntu 26.04 server, systemctl status auditd answers "Unit auditd.service could not be found". What does that mean for the records you have?

Aauditd is not installed; sudo, sshd and useradd still log

Correct — Programs log their own actions; what is missing are the kernel's records, such as every program executed. RHEL installs and enables auditd.

BLogging is broken, so no logins or sudo commands are recorded

Incorrect — sudo, useradd and sshd-session all write to the journal and auth.log without auditd.

Cauditd was removed by an intruder, since every Linux server ships it

Incorrect — Ubuntu does not install auditd by default, so its absence on a fresh server is normal.

Dauditd runs under another name on Ubuntu, systemd-journald

Incorrect — journald stores the messages programs send; it does not produce kernel audit records.

6 questions · explanations appear as you answer