Knowledge + Practice

CCNA Essential Tools Questions

15 questions · Essential Tools · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQhard

During boot, a server fails to mount an NFS filesystem listed in /etc/fstab. Which troubleshooting step should be taken first to isolate the issue?

A.Check the status of remote-fs.target with 'systemctl status remote-fs.target'

B.Check the status of nfs-client.target with 'systemctl status nfs-client.target'

C.Try to manually mount the NFS share with 'mount /mnt/nfs'

D.View kernel messages with 'dmesg | grep -i nfs'

AnswerA

Checking 'systemctl status remote-fs.target' is the correct first step because systemd uses this target to synchronize the activation of all remote filesystem mounts, including NFS, during the boot sequence. If the target is in a 'failed' or 'degraded' state, the status output will directly show which mount unit failed and why, allowing you to then inspect that specific unit's logs or configuration rather than guessing. This target is explicitly ordered after network-online.target and pulls in the mount units, so its state is the authoritative indicator of whether boot-time NFS mounting was attempted and completed.

Why this answer

When an NFS filesystem fails to mount during boot, the first step is to check whether the remote-fs.target unit is active. This target is responsible for triggering the mounting of all remote filesystems (including NFS) after the network is available. If remote-fs.target is not active or has failed, the NFS mount will not be attempted, and troubleshooting should start here before investigating the NFS share itself.

Exam trap

Red Hat often tests the misconception that NFS client services (nfs-client.target) are responsible for mounting NFS filesystems, when in fact the mounting is orchestrated by remote-fs.target, and troubleshooting should start there.

How to eliminate wrong answers

Option B is wrong because nfs-client.target is a target that only ensures NFS client services (like rpcbind and nfs-idmapd) are started, but it does not directly control the mounting of filesystems listed in /etc/fstab; the actual mount is governed by remote-fs.target. Option C is wrong because attempting to manually mount the share with 'mount /mnt/nfs' assumes the issue is with the share or network, but if the boot failure is due to a missing or misconfigured remote-fs.target, the manual mount might succeed and mislead the troubleshooting; the correct first step is to check the target status. Option D is wrong because viewing kernel messages with 'dmesg | grep -i nfs' can provide useful details after the target status is verified, but it is not the first step; the boot failure may be caused by a target dependency issue that dmesg would not directly reveal.

Practice this question →

2

MCQhard

A Red Hat Enterprise Linux server has been configured with a custom repository for offline updates. The administrator runs 'yum repolist' and the custom repository is not listed. Which command should be used to verify that the repository configuration file is valid and located in the correct directory?

A.yum repoinfo

B.cat /etc/yum.repos.d/custom.repo

C.yum check-repo

D.yum-config-manager --dump

AnswerB

Running cat /etc/yum.repos.d/custom.repo will print the exact bytes of the file to stdout, confirming both that the file exists in the proper /etc/yum.repos.d directory and what its repository configuration lines contain. If the file is missing, cat returns a nonzero exit status with a 'No such file or directory' error, so it provides an unambiguous, immediate pass/fail verification for this specific path.

Why this answer

The most direct way to verify that a repository configuration file is valid and located in the correct directory is to check its presence and syntax using 'cat /etc/yum.repos.d/custom.repo'. The repository configuration files must reside in /etc/yum.repos.d/ and have a .repo extension; if the file is missing or malformed, 'yum repolist' will not list the repository. This command simply reads the file, allowing the administrator to confirm its location and inspect its contents for errors.

Exam trap

The trap here is that candidates may assume a specialized yum subcommand exists for repository validation (like 'yum repoinfo' or 'yum check-repo'), when in fact the simplest and most reliable method is to directly inspect the configuration file with 'cat' or 'vim'.

How to eliminate wrong answers

Option A is wrong because 'yum repoinfo' is not a valid yum command; the correct command is 'yum repoinfo <repoid>' to display details about a repository that is already recognized, not to verify the configuration file's existence or validity. Option C is wrong because 'yum check-repo' is not a valid yum command; yum does not have a built-in 'check-repo' subcommand for validating repository configuration files. Option D is wrong because 'yum-config-manager --dump' is used to display the current yum configuration settings, not to verify the location or validity of a specific repository configuration file; it requires the repository to already be recognized.

Practice this question →

3

MCQmedium

An administrator receives an alert that a process named 'apache2' is consuming excessive CPU. The administrator needs to identify the PID of the process and then change its priority to the lowest possible value (least favorable scheduling). Which sequence of commands should be used?

A.pidof apache2; renice -n 20 -p <PID>

B.pidof apache2; renice -n 19 -p <PID>

C.ps -C apache2 -o pid=; renice -n -20 -p <PID>

D.ps aux | grep apache2; nice -n 19 <PID>

AnswerB

The pidof apache2 command directly outputs the PID(s) of the apache2 process, which can be passed to renice using -p. The renice -n 19 -p <PID> command sets the niceness of the existing process to 19, the lowest possible priority (often called 'most nice'). This is the correct way to reduce a running process's CPU priority on Linux; note that lowering priority (raising nice value) can be done by the process owner without root.

Why this answer

`pidof apache2` retrieves the PID of the apache2 process, and `renice -n 19 -p <PID>` sets the priority to the lowest possible (least favorable) scheduling value. In Linux, `renice` accepts nice values from -20 (highest priority) to 19 (lowest priority), so 19 is the correct value for the least favorable scheduling.

Exam trap

Red Hat often tests the exact range of nice values (0-19 for non-root users, -20 to 19 for root) and the distinction between `nice` (for starting processes) and `renice` (for changing priority of running processes), leading candidates to confuse the two or use out-of-range values.

How to eliminate wrong answers

Option A is wrong because it uses `renice -n 20`, but the valid nice range is -20 to 19; a value of 20 is out of range and will be rejected or clamped. Option C is wrong because it uses `renice -n -20`, which sets the highest priority (most favorable scheduling), not the lowest. Option D is wrong because `nice` is used to start a new process with a given priority, not to change the priority of an existing process; also, the syntax `nice -n 19 <PID>` is incorrect as `nice` expects a command, not a PID.

Practice this question →

4

MCQeasy

A system administrator has created a new group named 'ops'. The administrator wants to add the existing user 'alice' to this group as a supplementary group without affecting her current group memberships. Which command should be used?

A.usermod -aG ops alice

B.usermod -G ops alice

C.groupadd ops alice

D.usermod -g ops alice

AnswerA

usermod -aG ops alice explicitly appends alice to the supplementary group ops while preserving any existing supplementary group memberships. The -a (append) flag works in conjunction with -G (supplementary groups) to add the specified group to the user's current group set rather than replacing it. This is the correct, non-destructive way to grant a user access to an additional secondary group.

Why this answer

The `-a` (append) flag combined with `-G` (supplementary groups) in `usermod` adds the user 'alice' to the 'ops' group without removing her from any existing supplementary groups. Without `-a`, the `-G` flag alone would replace the user's current supplementary group list with only the specified groups, which would remove her from any other groups she already belongs to.

Exam trap

The trap here is that candidates often forget the `-a` flag and choose `usermod -G ops alice`, mistakenly thinking it adds the user to the group, when in fact it replaces all supplementary group memberships.

How to eliminate wrong answers

Option B is wrong because `usermod -G ops alice` without the `-a` flag sets the user's supplementary groups to exactly 'ops', overwriting and removing all other supplementary group memberships. Option C is wrong because `groupadd` creates a new group, not a user; the syntax `groupadd ops alice` is invalid and would fail or be misinterpreted. Option D is wrong because `usermod -g ops alice` changes the user's primary group (the group listed in /etc/passwd) to 'ops', not a supplementary group, and would alter the default group ownership for files created by alice.

Practice this question →

5

MCQmedium

An administrator needs to schedule a script to run every Monday, Wednesday, and Friday at 2:30 PM. Which cron expression should be used?

A.30 14 * * 1,3,5

B.30 14 * * 1-5

C.14 30 * * 1,3,5

D.30 14 * * 0,2,4

AnswerA

The cron expression has the correct field order: minute (30), hour (14), day of month (*), month (*), and day of week (1,3,5). Numeric day-of-week values start at 0 for Sunday, so 1 is Monday, 3 is Wednesday, and 5 is Friday. Because the day-of-month and month fields are wildcards, the job would run solely on those weekdays at 2:30 PM.

Why this answer

Cron uses five fields (minute, hour, day-of-month, month, day-of-week). 2:30 PM is 14:30 in 24-hour format, so minute=30 and hour=14. The day-of-week field uses 0-7 (0 and 7 = Sunday), with Monday=1, Wednesday=3, Friday=5. The asterisks for day-of-month and month mean 'every day' and 'every month', so the expression `30 14 * * 1,3,5` runs the script at 2:30 PM on Monday, Wednesday, and Friday.

Exam trap

Red Hat often tests the 24-hour time format and the correct ordering of minute and hour fields, causing candidates to swap them (as in Option C) or to confuse the day-of-week numbering (Sunday=0 vs Monday=1) as seen in Option D.

How to eliminate wrong answers

Option B is wrong because `1-5` in the day-of-week field specifies Monday through Friday (days 1,2,3,4,5), which includes Tuesday and Thursday, not just Monday, Wednesday, and Friday. Option C is wrong because the fields are reversed: `14 30` would mean minute=14 and hour=30, which is invalid (hour 30 does not exist) and would never run at 2:30 PM. Option D is wrong because `0,2,4` in the day-of-week field corresponds to Sunday (0), Tuesday (2), and Thursday (4), which is the wrong set of days.

Practice this question →

6

MCQhard

A system administrator wants to find all files in /var that are larger than 100MB and have been modified within the last 7 days. The output should be a list of file paths with sizes in human-readable format, sorted by size descending. Which command pipeline accomplishes this?

A.find /var -type f -size +100M -mtime -7 -ls | sort -k7 -n

B.find /var -type f -size +100M -mtime -7 -exec ls -lh {} \; | sort -k5 -h

C.find /var -type f -size +100M -mtime -7 -exec du -h {} + | sort -rh

D.find /var -type f -size +100M -mtime -7 -printf '%s %p\n' | sort -n -r | head -20

AnswerC

du -h gives human-readable sizes, sort -rh sorts by size descending correctly.

Why this answer

It uses `find` with `-size +100M` and `-mtime -7` to match files larger than 100MB modified within 7 days, then `-exec du -h {} +` aggregates sizes in human-readable format, and `sort -rh` sorts by the first field (size) in reverse human-numeric order, producing the required descending list.

Exam trap

Red Hat often tests the distinction between `-exec ls -lh` and `-exec du -h` for human-readable sizes, and the requirement for `sort -rh` (reverse human-numeric) versus `sort -n` (plain numeric) to correctly sort sizes with suffixes like 'M' or 'G'.

How to eliminate wrong answers

Option A is wrong because `-ls` outputs a detailed listing with size in the 7th column, but `sort -k7 -n` sorts numerically on that column, which does not handle human-readable suffixes (e.g., 'M', 'G') and would sort incorrectly. Option B is wrong because `-exec ls -lh {} \;` runs `ls` per file, but `sort -k5 -h` sorts by the 5th column (size), which works for human-readable sizes; however, `ls -lh` output includes multiple columns and the size column may vary in position (e.g., with symlinks or ACLs), and the pipeline lacks `-r` for descending order, so it would sort ascending, not descending. Option D is wrong because `-printf '%s %p\n'` prints size in bytes (not human-readable) and `sort -n -r` sorts numerically descending, but the output is not in human-readable format as required, and `head -20` limits output to 20 lines, which is not requested.

Practice this question →

7

MCQhard

A system administrator notices that a server is responding slowly. The administrator runs `top` and sees a process named `backup_script` consuming 95% CPU. The process runs as root and is supposed to run nightly backups. However, the system load average is low. The administrator wants to investigate without killing the process. Which of the following is the best course of action?

A.Use `renice -n 19 -p <PID>` to lower the priority of the process.

B.Use `nice -n 19 ./backup_script` to start the process with lower priority next time.

C.Use `chrt -i 0 <PID>` to set the scheduling policy to idle.

D.Use `kill -STOP <PID>` to pause the process and then resume later.

AnswerA

renice changes the nice value of an already-running process; specifying -n 19 with -p <PID> sets it to the lowest dynamic priority while leaving the process in a Running (or sleepable) state. This reduces its CPU scheduler share so interactive workloads are less affected, and the backup continues making progress rather than being suspended or restarted.

Why this answer

`renice -n 19 -p <PID>` lowers the CPU scheduling priority of the running `backup_script` process to the lowest possible value (19), which reduces its CPU consumption without killing it. This allows the administrator to investigate the cause of the high CPU usage while minimizing the impact on other processes and system responsiveness.

Exam trap

Red Hat often tests the distinction between `nice` (for starting a new process) and `renice` (for adjusting an existing process), and candidates may confuse the two or think `nice` can be applied to a running process.

How to eliminate wrong answers

Option B is wrong because `nice` sets the priority of a new process, not an already running one; the administrator needs to adjust the priority of the currently running `backup_script`, not start a new instance. Option C is wrong because `chrt -i 0 <PID>` sets the scheduling policy to SCHED_IDLE, which is an idle scheduling class that only runs when no other process needs the CPU, but this is a more drastic change than needed and may not be appropriate for a backup script that should eventually complete; also, the `-i` option is for SCHED_IDLE, but the correct syntax for setting idle policy is `chrt -i 0 <PID>` (though `chrt` typically uses `-i` for idle, but the policy value 0 is for SCHED_OTHER, not idle — the trap is that `chrt -i` expects a priority argument, and 0 is not valid for idle). Option D is wrong because `kill -STOP` pauses the process, which would halt the backup entirely, preventing it from completing its work and potentially leaving data in an inconsistent state; the administrator wants to investigate without killing or stopping the process.

Practice this question →

8

MCQmedium

An administrator notices that the /tmp directory is filling up quickly. They want to find all files in /tmp that are larger than 100 MB and owned by user 'ftp', then delete them. The administrator runs: find /tmp -type f -size 100M -user ftp -exec rm {} \;. However, this command deletes only files that are exactly 100 MB, not larger. Which find expression should be used instead?

A.find /tmp -type f -size 100M -user ftp -exec rm {} \;

B.find /tmp -type f -size +100M -user ftp -exec rm {} \;

C.find /tmp -type f -size +100M ! -size 100M -user ftp -exec rm {} \;

D.find /tmp -type f -size +100M -size -100M -user ftp -exec rm {} \;

AnswerB

The + in -size +100M correctly selects every regular file in /tmp owned by the ftp user whose size is greater than 100 MiB, because the plus sign means 'greater than' in find's size test. Combined with -type f to ensure only regular files are considered and -user ftp to restrict ownership, the -exec rm {} \; safely removes each matching file, replacing {} with the pathname. This is the simplest and most precise way to express the administrator's intention.

Why this answer

The `find` command uses `+` before a size value to match files larger than that size, not exactly equal. The original command omitted the `+`, so it matched only files exactly 100 MB. Adding `+100M` correctly selects files larger than 100 MB.

Exam trap

Red Hat often tests the subtle difference between exact size matching and size range matching using the `+` and `-` prefixes, trapping candidates who assume `-size 100M` means 'greater than or equal to' instead of 'exactly equal to'.

How to eliminate wrong answers

Option A is wrong because `-size 100M` matches files exactly 100 MB, not larger, so it fails to delete files exceeding that size. Option C is wrong because `-size +100M ! -size 100M` is redundant and incorrect; `-size +100M` already excludes files exactly 100 MB, and the negation adds no benefit while potentially causing confusion. Option D is wrong because `-size +100M -size -100M` is contradictory and matches no files, as a file cannot be both larger than 100 MB and smaller than 100 MB simultaneously.

Practice this question →

9

Multi-Selecteasy

Which TWO commands can be used to display the current date and time in a format like '2023-10-05 14:30:00'?

Select 1 answer

A.date '+%Y-%m-%d %H:%M:%S'

B.cal

C.timedatectl

D.date -Iseconds

E.hwclock

AnswersA

Formats date as required.

Why this answer

The `date` command with the format string `'+%Y-%m-%d %H:%M:%S'` explicitly outputs the current date and time in the requested 'YYYY-MM-DD HH:MM:SS' format. Option D (`date -Iseconds`) outputs date and time in ISO 8601 format (e.g., 2023-10-05T14:30:00+00:00) with a 'T' separator and timezone, not the requested format. Therefore, only option A is correct.

Exam trap

Red Hat often tests the distinction between commands that display time in a raw format versus those that require explicit formatting; candidates may mistakenly choose `timedatectl` because it shows the current time, but it does not output in the exact 'YYYY-MM-DD HH:MM:SS' format without additional parsing.

Practice this question →

10

MCQmedium

A script needs to be run at system boot for a specific user. Which method ensures the script runs with that user's environment?

A.Place the script in /etc/rc.d/rc.local

B.Add an entry to ~/.xprofile

C.Create a systemd user unit in ~/.config/systemd/user/

D.Add the script to the user's crontab with @reboot

AnswerC

A systemd user unit placed in ~/.config/systemd/user/ is managed by the per-user systemd manager and runs in the user's own runtime context, with access to the user's environment, PATH, and systemd user D-Bus. To have it launch at boot rather than only after login, the user must be enabled for lingering (loginctl enable-linger username), after which the user manager starts automatically at boot. This makes it the correct choice for boot-time per-user scripts.

Why this answer

Systemd user units, placed in ~/.config/systemd/user/, are executed in the user's own session context, inheriting the user's environment variables, PATH, and D-Bus session. This ensures the script runs with the specific user's environment at boot, as systemd starts the user manager (systemd --user) early in the boot process for each enabled user.

Exam trap

The trap here is that candidates often assume @reboot in crontab runs with the full user environment, but in reality cron provides a stripped-down environment (e.g., no D-Bus, no systemd user session), making it unsuitable for scripts that depend on user-specific services or graphical session variables.

How to eliminate wrong answers

Option A is wrong because /etc/rc.d/rc.local runs as root during system boot, not as a specific user, so it does not load the target user's environment (e.g., $HOME, $USER, or desktop session variables). Option B is wrong because ~/.xprofile is sourced only when the X display server starts (e.g., via a display manager), not at system boot, and it depends on a graphical session being available. Option D is wrong because @reboot in a user's crontab runs the script under the cron daemon's minimal environment, which lacks the full user session context (e.g., D-Bus, systemd user services, or graphical session variables), and cron may not start until after the user logs in.

Practice this question →

11

MCQeasy

Refer to the exhibit. What does the file permission -rw------- indicate about /etc/shadow?

A.Root user can read, write, and execute; group and others have no access.

B.Owner can read and write; group can read; others can read.

C.Owner can read; group can read; others cannot access.

D.Only root user can read and write; others have no access.

AnswerD

The permission string begins with a hyphen indicating a regular file, followed by 'rw-' for the owner, which is root (or the file's owning user). The subsequent '---' for group and '---' for others show those classes have zero access, so only the owner can read and write (and not execute). This matches typical root-owned file permissions.

Why this answer

The permission string `-rw-------` breaks down as: owner (root) has read (4) and write (2) permissions, and no execute (0); group has no permissions (---); others have no permissions (---). Since `/etc/shadow` is owned by root, only the root user can read and write the file, while all other users (including group members and others) have zero access. Option D correctly states this.

Exam trap

Red Hat often tests the misconception that `-rw-------` means the owner can execute, or that the hyphen in the execute position is easily overlooked, causing candidates to incorrectly assume execute permission is present.

How to eliminate wrong answers

Option A is wrong because the permission string shows no execute bit for the owner (the third character is `-`, not `x`), so the root user cannot execute the file; also, group and others have no access, but the statement incorrectly includes execute. Option B is wrong because it claims group and others can read, but the permission string shows `---` for both group and others, meaning no read access. Option C is wrong because it says the owner can only read, but the owner actually has both read and write permissions (the second character is `w`).

Practice this question →

12

MCQmedium

A developer needs to search for the string 'ERROR' in all files under /var/log, but wants to exclude files ending with '.gz'. Which command is correct?

A.grep -r --exclude='*.gz' 'ERROR' /var/log

B.grep -R --exclude='*.gz' 'ERROR' /var/log

C.grep -l 'ERROR' /var/log/*.gz

D.grep -v '*.gz' -r 'ERROR' /var/log

AnswerA

The -r flag makes grep recursively descend into /var/log and all of its subdirectories, while --exclude='*.gz' instructs grep to skip any file whose basename matches that glob, thereby avoiding compressed log files. This precisely implements the requested search: only uncompressed files under /var/log are examined for the string 'ERROR'. Using -r rather than the similar -R is also safer because -r does not dereference symbolic links, keeping the search confined to the named directory tree.

Why this answer

`grep -r` performs a recursive search through all files under /var/log, and the `--exclude='*.gz'` option tells grep to skip any files matching the glob pattern '*.gz'. This combination ensures that only non-compressed log files are searched for the string 'ERROR', meeting the requirement exactly.

Option B uses `-R` instead of `-r`. In GNU grep, `-R` implies `--dereference-recursive`, which follows symbolic links into other directories. This could lead to searching outside `/var/log` if any symlinks point elsewhere, making it less precise for the stated requirement. While `-r` and `-R` are often conflated, `-R` is not equivalent to `-r` when symlinks are present, and the standard recursive option is `-r`. Therefore, B is incorrect.

Exam trap

Red Hat often tests the distinction between `--exclude` (which filters files by name) and `-v` (which inverts line matches), leading candidates to mistakenly use `-v` with a glob pattern to try to exclude files.

How to eliminate wrong answers

Option B is wrong because `grep -R` is equivalent to `grep -r` in most implementations, but the key issue is that the `--exclude` pattern is incorrectly quoted with single quotes inside double quotes or vice versa; however, the primary flaw is that `-R` is not a standard grep option (it is often used for dereferencing symlinks, but the correct recursive flag is `-r`). Option C is wrong because `grep -l 'ERROR' /var/log/*.gz` only lists files matching 'ERROR' that end with '.gz', which is the opposite of what is needed (it excludes non-.gz files). Option D is wrong because `grep -v '*.gz'` treats '*.gz' as a regex pattern to invert matches on lines, not as a file exclusion pattern, and the `-r` flag is misplaced after the pattern; this command would search recursively but exclude lines containing the literal string '*.gz', not files ending with '.gz'.

Practice this question →

13

MCQeasy

A user wants to run a command in the background after logging out of an SSH session. Which method ensures the process continues even after logout?

A.Run 'nohup command &' before logout

B.Run 'command', press Ctrl+Z, then type 'bg' and logout

C.Run 'command &' and then exit

D.Run 'command & disown' then logout

AnswerA

nohup ignores SIGHUP, allowing the process to continue.

Why this answer

`nohup` ignores the SIGHUP signal that the shell sends to its child processes when the parent shell exits (e.g., upon logout). By running `nohup command &`, the command is placed in the background and will continue running even after the SSH session terminates, as it is immune to the hangup signal.

Exam trap

The trap here is that candidates often think `&` alone or `bg` is sufficient to keep a process running after logout, but they miss that the shell sends SIGHUP to all child processes (including background jobs) upon exit unless explicitly ignored with `nohup` or handled with `disown` in a shell that supports `huponexit` off.

How to eliminate wrong answers

Option B is wrong because suspending a job with Ctrl+Z and then resuming it in the background with `bg` does not protect the process from SIGHUP; when the shell exits, the background job will still receive SIGHUP and terminate. Option C is wrong because running `command &` alone does not prevent SIGHUP; the background job is still a child of the shell and will be killed when the shell exits. Option D is wrong because `disown` removes the job from the shell's job table, but it does not prevent the shell from sending SIGHUP to the process on logout; the process may still receive SIGHUP depending on the shell implementation (e.g., bash sends SIGHUP to disowned jobs by default unless `huponexit` is disabled).

Practice this question →

14

MCQmedium

An administrator needs to compress a directory containing subdirectories and files into a single archive file, with maximum compression, and exclude all '*.tmp' files. Which command should be used?

A.tar -czvf archive.tar.gz --exclude='*.tmp' /path/to/dir

B.tar -czvf archive.tar.gz /path/to/dir --exclude='*.tmp'

C.tar -cjvf archive.tar.bz2 --exclude='*.tmp' /path/to/dir

D.tar -czvf archive.tar.gz /path/to/dir

AnswerC

The -j flag invokes bzip2, which provides a considerably higher compression ratio than gzip, satisfying the 'maximum compression' requirement. Placing --exclude='*.tmp' before the source directory ensures the pattern is active before tar reads the files, so temporary files are omitted. The output suffix .tar.bz2 matches the flag and makes the archive self-descriptive.

Why this answer

The question specifies 'maximum compression'. Among common tar compression methods, bzip2 (via the -j flag) typically provides better compression ratios than gzip (-z), though it is slower. Option C uses `tar -cjvf` with the `--exclude` option placed correctly before the source directory, which is the proper syntax for tar exclusions.

This command creates a .tar.bz2 archive with maximum compression while excluding all *.tmp files. Option A uses gzip, which offers faster compression but lower ratios, making it incorrect for 'maximum compression'. Options B and D also fail: B has incorrect syntax (--exclude after the directory), and D omits the exclude option entirely.

Exam trap

Red Hat often tests the distinction between compression methods: gzip (-z) is faster but yields larger archives, while bzip2 (-j) provides better compression at the cost of speed. Candidates may assume -z is the default or best option, but for 'maximum compression', bzip2 is superior.

How to eliminate wrong answers

Option B is wrong because the `--exclude` option is placed after the source directory `/path/to/dir`, which causes tar to ignore the exclusion pattern — tar processes positional arguments in order, and the exclude pattern must precede the source path to take effect. Option C is wrong because it uses `-j` for bzip2 compression instead of `-z` for gzip; while bzip2 can achieve higher compression ratios, the question specifies 'maximum compression' in the context of the commonly used gzip format, and the output file extension `.tar.bz2` does not match the expected `.tar.gz` archive. Option D is wrong because it omits the `--exclude='*.tmp'` option entirely, so all `*.tmp` files will be included in the archive, failing the requirement to exclude them.

Practice this question →

15

MCQhard

Refer to the exhibit. The backup script runs every 5 minutes but generates errors. What is the most likely cause?

A.The script is owned by root.

B.The cron daemon is not running.

C.The script uses absolute paths.

D.The script is not executable.

AnswerD

This is the cause. The exhibit shows the script has permissions 644, meaning there is no execute bit set for the owner, group, or others. When cron encounters a script path in a crontab, it invokes that file directly via execve(), which requires at least one execute bit; otherwise the kernel returns EACCES and the job logs 'Permission denied' or sends a non-zero exit status. The file must be made executable, for example with 'chmod +x', for cron to run it successfully.

Why this answer

The cron job fails because the script lacks execute permissions. Cron requires that scripts specified in crontab entries have the executable bit set (chmod +x) for the user under whose crontab the job runs. Without this, the cron daemon cannot spawn the script as a process, resulting in errors.

Exam trap

Red Hat often tests the distinction between file ownership and file permissions, where candidates mistakenly assume root ownership is the problem, but the actual issue is the missing executable bit that cron strictly enforces.

How to eliminate wrong answers

Option A is wrong because ownership by root does not prevent a script from executing; root ownership is common and cron can run root-owned scripts if the crontab belongs to root or the script has appropriate permissions. Option B is wrong because if the cron daemon were not running, no cron jobs would execute at all, not just this one script — the question states the script runs but generates errors, implying the daemon is active. Option C is wrong because using absolute paths is actually a best practice in cron scripts to avoid PATH issues; absolute paths do not cause execution errors.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Essential Tools questions.

Start 20-question session