Scenario practice questions

A junior administrator needs to create a symbolic link named /usr/local/bin/editor that points to /opt/tools/vim.bin. The link must be created without overwriting any existing file at the destination. Which command accomplishes this?

Trap 1: ln /opt/tools/vim.bin /usr/local/bin/editor

Without the -s flag, ln creates a hard link, not a symbolic link. A hard link cannot span filesystems and shares the same inode as the target, so it does not satisfy the requirement for a symbolic link pointing at /opt/tools/vim.bin, and it would fail if /usr/local and /opt are separate filesystems.

Trap 2: ln -sf /opt/tools/vim.bin /usr/local/bin/editor

The -f flag forces removal of an existing destination file before creating the link. Since the requirement is to avoid overwriting any existing file, using -f is unnecessary and could destroy a file that happens to already exist at /usr/local/bin/editor, making this command unsafe for the stated goal.

Trap 3: cp -s /opt/tools/vim.bin /usr/local/bin/editor

cp does not have a -s option that creates symbolic links; the -s option in cp makes a symbolic link instead of copying, but the invocation shown is not the documented way to create a standalone symlink and is not equivalent to ln -s. It also risks copying behavior or errors depending on the distribution.

A
ln /opt/tools/vim.bin /usr/local/bin/editor
Why it fails: Without the -s flag, ln creates a hard link, not a symbolic link. A hard link cannot span filesystems and shares the same inode as the target, so it does not satisfy the requirement for a symbolic link pointing at /opt/tools/vim.bin, and it would fail if /usr/local and /opt are separate filesystems.
B
ln -sf /opt/tools/vim.bin /usr/local/bin/editor
Why it fails: The -f flag forces removal of an existing destination file before creating the link. Since the requirement is to avoid overwriting any existing file, using -f is unnecessary and could destroy a file that happens to already exist at /usr/local/bin/editor, making this command unsafe for the stated goal.
C
cp -s /opt/tools/vim.bin /usr/local/bin/editor
Why it fails: cp does not have a -s option that creates symbolic links; the -s option in cp makes a symbolic link instead of copying, but the invocation shown is not the documented way to create a standalone symlink and is not equivalent to ln -s. It also risks copying behavior or errors depending on the distribution.
D
ln -s /opt/tools/vim.bin /usr/local/bin/editor
The ln -s command creates a symbolic link, and because the destination path does not exist yet, the link is created cleanly without touching any existing file. This matches the requirement exactly: a symbolic link at the specified path pointing to the target binary, with no overwrite behavior needed.

Question 2mediummultiple choice

A temporary contractor 'contractor1' has left the company. The administrator needs to remove the user account and all associated files in the home directory. Which command accomplishes this?

Trap 1: userdel contractor1

userdel removes the account entry but leaves the home directory intact unless the -r flag is added, so contractor1's files would remain on disk. It is the right tool when the account should go while files are retained for auditing or transfer.

Trap 2: passwd -d contractor1

passwd -d deletes the account's password, leaving the account and its home directory fully present and loginable without authentication. It is used to blank a password for passwordless logins, not to remove a departing contractor's account or files.

Trap 3: deluser --remove-home contractor1

deluser --remove-home is Debian and Ubuntu specific; on RHEL-based systems the command does not exist, so it fails on the exam's target platform. It correctly deletes the account and home directory where the Debian toolset is installed.

A
userdel contractor1
Why it fails: userdel removes the account entry but leaves the home directory intact unless the -r flag is added, so contractor1's files would remain on disk. It is the right tool when the account should go while files are retained for auditing or transfer.
B
passwd -d contractor1
Why it fails: passwd -d deletes the account's password, leaving the account and its home directory fully present and loginable without authentication. It is used to blank a password for passwordless logins, not to remove a departing contractor's account or files.
C
userdel -r contractor1
`userdel -r contractor1` deletes the account and recursively removes the home directory with its mail spool, satisfying the requirement to erase all associated files. Plain `userdel` would leave `/home/contractor1` intact, so the `-r` flag is essential here.
D
deluser --remove-home contractor1
Why it fails: deluser --remove-home is Debian and Ubuntu specific; on RHEL-based systems the command does not exist, so it fails on the exam's target platform. It correctly deletes the account and home directory where the Debian toolset is installed.

Question 3mediummultiple choice

Scenario: You are managing a Linux server that hosts a web application. The application runs under the user 'webapp' and the group 'webgroup'. Recently, a new intern 'john' (username 'john') needs to be able to view and modify files in /var/www/html, which is owned by root:webgroup with permissions 775. John is currently a member of the group 'staff', but not 'webgroup'. The security policy requires that John must be able to edit files without using sudo, and his primary group must remain 'staff'. Which of the following actions should you take to meet the requirements?

Trap 1: Change the group ownership of /var/www/html to 'staff' and set the…

Changing group ownership to staff grants access to every staff member, not just John, violating least privilege. Setgid on a staff-owned directory is right for team-shared trees where all staff should have equal write access.

Trap 2: Change John's primary group to 'webgroup' with 'usermod -g webgroup…

Setting John's primary group to webgroup directly contradicts the stated requirement that his primary group remain staff. It is tempting because changing a user's primary group does grant group-based file access, and would be valid if the policy allowed altering his primary group rather than adding a supplementary one.

Trap 3: Set the setgid bit on /var/www/html with 'chmod g+s /var/www/html'.

The setgid bit only makes new files inherit the directory's group; it grants John no access, since he is not in webgroup. Setgid suits shared collaborative directories where members already belong to the owning group.

A
Add John to the 'webgroup' supplementary group with 'usermod -a -G webgroup john'.
Adding john to webgroup as a supplementary group grants him the group write permission on /var/www/html (775, root:webgroup) without sudo, while his primary group stays staff. This satisfies both the editing requirement and the policy that his primary group remain unchanged.
B
Change the group ownership of /var/www/html to 'staff' and set the setgid bit.
Why it fails: Changing group ownership to staff grants access to every staff member, not just John, violating least privilege. Setgid on a staff-owned directory is right for team-shared trees where all staff should have equal write access.
C
Change John's primary group to 'webgroup' with 'usermod -g webgroup john'.
Why it fails: Setting John's primary group to webgroup directly contradicts the stated requirement that his primary group remain staff. It is tempting because changing a user's primary group does grant group-based file access, and would be valid if the policy allowed altering his primary group rather than adding a supplementary one.
D
Set the setgid bit on /var/www/html with 'chmod g+s /var/www/html'.
Why it fails: The setgid bit only makes new files inherit the directory's group; it grants John no access, since he is not in webgroup. Setgid suits shared collaborative directories where members already belong to the owning group.

Question 4easymultiple choice

A junior administrator is troubleshooting a server and needs to inspect the manual page for the 'ip' command, but the system is a minimal install where the man pages for that package were not installed. The administrator still wants the short one-line usage summary for 'ip' printed directly to the terminal. Which command should they run?

Trap 1: info ip

info reads Texinfo documents, which are even less likely to be installed than man pages on a stripped-down system. It also presents an interactive pager-based interface rather than printing a short one-line usage summary directly to the terminal as the scenario requires.

Trap 2: whatis ip

whatis queries the man page database and prints only a single descriptive line such as the command's purpose. It does not show the option syntax or usage summary, and it also fails entirely when the man pages for that package have not been installed.

Trap 3: man ip

man ip depends on the man page files being present on disk. On a minimal install where documentation packages were deliberately excluded, this returns 'No manual entry for ip' rather than the usage summary, so it fails the stated requirement of getting output with no documentation installed.

A
ip --help
The --help flag is handled by the utility itself and prints a concise usage summary to standard output, which works even when man pages are absent. It requires no extra packages and exits immediately, making it ideal on a minimal system where documentation was stripped out.
B
info ip
Why it fails: info reads Texinfo documents, which are even less likely to be installed than man pages on a stripped-down system. It also presents an interactive pager-based interface rather than printing a short one-line usage summary directly to the terminal as the scenario requires.
C
whatis ip
Why it fails: whatis queries the man page database and prints only a single descriptive line such as the command's purpose. It does not show the option syntax or usage summary, and it also fails entirely when the man pages for that package have not been installed.
D
man ip
Why it fails: man ip depends on the man page files being present on disk. On a minimal install where documentation packages were deliberately excluded, this returns 'No manual entry for ip' rather than the usage summary, so it fails the stated requirement of getting output with no documentation installed.

Question 5mediummultiple choice

A Linux administrator is troubleshooting a custom systemd service named data-sync.service that repeatedly fails with the error 'start request repeated too quickly'. The unit file has Restart=always and RestartSec=5. Which command should the administrator use to reset the failed state and clear the restart counter so the service can be started again?

Trap 1: systemctl daemon-reload

This command reloads systemd's manager configuration and unit files after they have been modified on disk. It does not clear the failed state or restart counter of a service. While daemon-reload is necessary after editing a unit file, it will not resolve the 'start request repeated too quickly' error in this scenario.

Trap 2: systemctl restart data-sync.service

This command attempts to stop and then start the service. However, because the service is in a failed state due to hitting the start limit, systemd will reject the start request and return an error. The restart counter must be reset before the service can be started again, so this command alone will not work.

Trap 3: systemctl kill data-sync.service

This command sends a signal to the service's processes, but since the service is not running (it failed to start), there are no processes to kill. It does not reset the failed state or clear the restart counter. This command is used to stop a running service forcefully, not to recover from a start limit failure.

A
systemctl reset-failed data-sync.service
This command resets the failed state of the unit and clears the restart counter maintained by systemd. When a service hits the start limit (default: 5 starts within 10 seconds), systemd refuses further starts until the counter is reset. After running this, the administrator can successfully start the service again with systemctl start.
B
systemctl daemon-reload
Why it fails: This command reloads systemd's manager configuration and unit files after they have been modified on disk. It does not clear the failed state or restart counter of a service. While daemon-reload is necessary after editing a unit file, it will not resolve the 'start request repeated too quickly' error in this scenario.
C
systemctl restart data-sync.service
Why it fails: This command attempts to stop and then start the service. However, because the service is in a failed state due to hitting the start limit, systemd will reject the start request and return an error. The restart counter must be reset before the service can be started again, so this command alone will not work.
D
systemctl kill data-sync.service
Why it fails: This command sends a signal to the service's processes, but since the service is not running (it failed to start), there are no processes to kill. It does not reset the failed state or clear the restart counter. This command is used to stop a running service forcefully, not to recover from a start limit failure.

Question 6easymultiple choice

An administrator needs to change the group ownership of the directory /srv/project and all of its existing contents to the group developers, without altering the user ownership. Which command should be used?

Trap 1: chmod -R g+developers /srv/project

chmod modifies permission bits, not ownership, and the syntax g+developers is invalid because chmod expects permission symbols such as r, w, or x after the class selector. This command would produce an error and cannot change which group owns the files.

Trap 2: usermod -g developers /srv/project

usermod manages user account attributes, not file ownership, and it expects a username rather than a path. Passing a directory path would cause an error and could not affect the group ownership of files under /srv/project, making it entirely unsuitable for this task.

Trap 3: chown -R developers /srv/project

When chown is given a single name without a colon, it is interpreted as a user name, not a group. This command would attempt to change the user owner to developers, which does not exist as a user, and it would fail or behave incorrectly, so it does not change group ownership as required.

A
chmod -R g+developers /srv/project
Why it fails: chmod modifies permission bits, not ownership, and the syntax g+developers is invalid because chmod expects permission symbols such as r, w, or x after the class selector. This command would produce an error and cannot change which group owns the files.
B
usermod -g developers /srv/project
Why it fails: usermod manages user account attributes, not file ownership, and it expects a username rather than a path. Passing a directory path would cause an error and could not affect the group ownership of files under /srv/project, making it entirely unsuitable for this task.
C
chown -R developers /srv/project
Why it fails: When chown is given a single name without a colon, it is interpreted as a user name, not a group. This command would attempt to change the user owner to developers, which does not exist as a user, and it would fail or behave incorrectly, so it does not change group ownership as required.
D
chgrp -R developers /srv/project
chgrp changes group ownership and the -R flag applies the change recursively to the directory and all existing contents. It leaves user ownership untouched, which matches the requirement exactly, and it is the purpose-built command for changing group ownership on Linux systems.

Question 7hardmultiple choice

A Linux administrator is creating a custom systemd timer unit named backup.timer to schedule a daily backup script. The administrator wants the timer to trigger the backup service exactly at 2:00 AM every day, regardless of when the system was last booted. Which timer directive should be used in the [Timer] section of backup.timer?

Trap 1: OnStartupSec=2h

OnStartupSec is similar to OnBootSec but relative to when systemd was first started, not the system boot. It would trigger 2 hours after systemd started, which is not at 2:00 AM. This directive is typically used for early boot tasks and does not provide calendar-based scheduling.

Trap 2: OnUnitActiveSec=24h

OnUnitActiveSec triggers the timer relative to when the unit was last activated. It would run every 24 hours after the last activation, but not necessarily at 2:00 AM. The start time would drift based on when the service last ran. This does not meet the requirement of a fixed daily time.

Trap 3: OnBootSec=2h

OnBootSec specifies a delay relative to system boot. It would trigger the service 2 hours after boot, not at 2:00 AM. This is a monotonic timer and does not align with a specific time of day. It is used for tasks that should run after a certain uptime, not for daily scheduled backups at a fixed time.

A
OnStartupSec=2h
Why it fails: OnStartupSec is similar to OnBootSec but relative to when systemd was first started, not the system boot. It would trigger 2 hours after systemd started, which is not at 2:00 AM. This directive is typically used for early boot tasks and does not provide calendar-based scheduling.
B
OnCalendar=*-*-* 02:00:00
The OnCalendar directive defines a calendar-based schedule using systemd's calendar event format. Specifying *-*-* 02:00:00 means every day at 2:00 AM. This is independent of boot time and ensures the timer triggers at the exact wall-clock time. This is the correct directive for the scenario.
C
OnUnitActiveSec=24h
Why it fails: OnUnitActiveSec triggers the timer relative to when the unit was last activated. It would run every 24 hours after the last activation, but not necessarily at 2:00 AM. The start time would drift based on when the service last ran. This does not meet the requirement of a fixed daily time.
D
OnBootSec=2h
Why it fails: OnBootSec specifies a delay relative to system boot. It would trigger the service 2 hours after boot, not at 2:00 AM. This is a monotonic timer and does not align with a specific time of day. It is used for tasks that should run after a certain uptime, not for daily scheduled backups at a fixed time.