EX200 Create simple shell scripts — 10 Questions

Question 1

Which THREE of the following practices are recommended when creating simple shell scripts in a Red Hat Enterprise Linux environment to ensure reliability, security, and maintainability?

Accepted Answer

Quote variables when used in commands, e.g., "$file" instead of $file.. Quoting variables (e.g., "$file") prevents word splitting and glob expansion, which can cause commands to operate on unexpected arguments or filenames with spaces. This is a fundamental shell scripting best practice that directly improves reliability and security by preserving the intended value of the variable.

Answer

Use #!/bin/sh for compatibility, even if bash-specific features are needed.

Answer

Always run scripts by invoking the interpreter directly (e.g., bash script.sh) instead of making them executable.

Question 2

Refer to the exhibit. A junior admin runs this script as root, but it always prints 'httpd is running' even when httpd is stopped. What is the most likely cause?

Accepted Answer

The script uses the test command `[` instead of directly using the command as the condition, causing the condition to always be true.. When a command is used as a condition inside `[ ]`, the `test` builtin evaluates the exit status of the command inside the brackets, not the command itself. In this script, `[ systemctl is-active httpd ]` always returns true (exit code 0) because `[` treats the string "systemctl" as a non-empty string, which is always true. The correct syntax is to use the command directly as the condition: `if systemctl is-active httpd; then`.

Answer

The script is not executable and is run with `sh script.sh`, causing the shebang to be ignored.

Answer

The variable SERVICE is misspelled as "HTTPD" in the condition.

Answer

The `systemctl` command requires root privileges, and the script is run as a non-root user.

Question 3

You are a system administrator for a medium-sized company running Red Hat Enterprise Linux 8 on all servers. The development team has created a shell script that is supposed to be run nightly via cron to synchronize configuration files from a master server to multiple web servers. The script is located at /opt/scripts/sync_configs.sh and is owned by root. It uses rsync over SSH with key-based authentication. The script works perfectly when run manually by root, but when it runs via cron, the synchronization fails with the error 'Host key verification failed.' The script does not explicitly specify any SSH options. The cron job is configured in /etc/crontab as: `0 2 * * * root /opt/scripts/sync_configs.sh`. The SSH keys are stored in /root/.ssh/id_rsa and the known_hosts file contains the correct host key for the master server. What is the most likely cause of the failure, and what is the best course of action to resolve it?

Accepted Answer

The cron environment lacks the SSH agent or the key is not loaded. Modify the script to use `ssh -i /root/.ssh/id_rsa -o StrictHostKeyChecking=no` or add a line to load the key via `ssh-add`.. D is correct because cron runs in a minimal environment that does not automatically load the SSH agent or add keys to it. When the script runs manually as root, the SSH agent is typically running and the key is loaded, but cron does not have access to the agent's socket. The error 'Host key verification failed' is misleading; the actual issue is that SSH cannot authenticate because the private key is not available to the agent, not that the host key is unknown. Adding `ssh -i /root/.ssh/id_rsa` explicitly specifies the key file, bypassing the need for an agent, or using `ssh-add` in the script loads the key into an agent for the cron session.

Answer

The PATH variable in cron does not include /usr/bin/rsync. Add a full path to rsync in the script or set PATH in the crontab.

Answer

The script does not have execute permission for the root user. Run `chmod +x /opt/scripts/sync_configs.sh`.

Answer

The known_hosts file in /root/.ssh/ contains an incorrect host key for the master server. Remove the entry and reconnect manually to update it.

Question 4

Which TWO of the following are true about creating simple shell scripts in Red Hat Enterprise Linux?

Accepted Answer

The shebang line (e.g., #!/bin/bash) is used to specify the interpreter.. The shebang line (e.g., #!/bin/bash) tells the kernel which interpreter to use when executing the script. Without it, the shell may fall back to the default interpreter (often /bin/sh) or fail to run the script correctly. This is a fundamental requirement for any interpreted script in Linux.

Answer

Scripts must be stored in /usr/local/bin to be found by the shell.

Answer

A script must be compiled before it can be run.

Answer

A script must have a .sh file extension to be executable.

Question 5

You are a system administrator for a small company. The development team has created a shell script named 'deploy.sh' that automates deployment of a web application. The script is located at /home/devops/deploy.sh. The team reports that when they run the script with './deploy.sh' from the /home/devops directory, it fails with a 'Permission denied' error. However, running 'bash deploy.sh' works fine. Additionally, the script's first line is '#!/bin/bash' and the file permissions are '-rw-rw-r--'. The team wants to be able to run the script directly without typing 'bash'. Which of the following actions should you take to resolve the issue?

Accepted Answer

Add the execute permission to the script using 'chmod +x /home/devops/deploy.sh'.. The 'Permission denied' error when running './deploy.sh' indicates that the script lacks execute permission. The current permissions '-rw-rw-r--' show read/write for owner and group, and read-only for others, but no execute bit. Adding execute permission with 'chmod +x' allows the script to be run directly via its shebang line.

Answer

Change the shebang line to '#!/bin/sh' because bash is not the default shell.

Answer

Move the script to /usr/local/bin so it can be found in the PATH.

Answer

Change the owner of the script to root using 'chown root:root /home/devops/deploy.sh'.

Question 6

Arrange the steps to configure a logical volume snapshot named 'snap_lv_data' of logical volume 'lv_data'.

Accepted Answer

Create snapshot using lvcreate -s, Mount snapshot to a directory, Perform operations on snapshot, Unmount snapshot, Remove snapshot. The correct sequence for configuring a logical volume snapshot is to first create the snapshot with lvcreate -s, mount it to access its contents, perform necessary operations (such as backups), unmount the snapshot, and finally remove it to clean up. Common mistakes include mounting or operating on the snapshot before it exists, or removing it prematurely.

Answer

Mount snapshot to a directory, Create snapshot using lvcreate -s, Perform operations on snapshot, Unmount snapshot, Remove snapshot

Answer

Create snapshot using lvcreate -s, Perform operations on snapshot, Mount snapshot to a directory, Unmount snapshot, Remove snapshot

Answer

Create snapshot using lvcreate -s, Mount snapshot to a directory, Remove snapshot, Perform operations on snapshot, Unmount snapshot

Question 7

Match each package management command to its action.

Accepted Answer

dnf install: Installs a package with dependencies. In RHEL 8/9, DNF is the default package manager. 'dnf install' installs packages with dependencies, 'dnf remove' uninstalls, 'rpm -ivh' installs local RPMs without dependency resolution. 'dnf update' updates all packages, and 'dnf search' finds packages by keyword. Common confusions arise between install/update and remove/search.

Answer

dnf update: Installs a package with dependencies

Answer

dnf search: Removes a package

Question 8

A junior admin writes a script that uses functions. They notice that a variable set inside a function is not available after the function call. What is the likely cause and best practice?

Accepted Answer

The variable was declared with 'local', change to 'global' keyword. The variable is unavailable after the function call because it was declared with the 'local' keyword. To make it global, you should either remove the 'local' declaration or explicitly use 'declare -g'. There is no 'global' keyword in bash. Option A's cause is correct but its remedy is wrong; Option D has the correct remedy but incorrectly claims variables are local by default. Therefore, none of the given options is entirely correct.

Answer

The script must be sourced (.) instead of executed to retain variables

Answer

The function was called inside a subshell, use 'export' to make it global

Answer

In bash, variables declared in a function are local by default, use 'declare -g' to make them global

Question 9

A sysadmin creates a script to rotate log files. The script uses 'find /var/log -type f -name "*.log" -mtime +30 -exec gzip {} \;' but some log files are not compressed. The script runs as root. What is the most likely reason some files remain uncompressed?

Accepted Answer

Another process deletes log files between find's detection and execution, causing 'find' to error on missing files. The `find` command traverses the directory and for each matching file, it invokes `gzip`. There is a time-of-check-to-time-of-use (TOCTOU) race condition: between the moment `find` identifies a file and the moment `gzip` opens it, another process (e.g., logrotate) may delete or rename the file. In that case, `gzip` will fail with a 'No such file or directory' error, and that log file's data will not be compressed. Since the script runs as root, permission problems are not the cause.

Answer

The log files are already compressed (.gz extension), and gzip fails silently

Answer

The script lacks proper quoting around {} which causes gzip to fail on files with spaces

Answer

The '-mtime +30' flag selects files newer than 30 days, so old files are excluded

Question 10

A script uses 'read' to get user input and then performs an action based on the input. However, when the script is piped (e.g., './script.sh | othercommand'), the read command does not wait for input and the script continues with empty variable. How can this be fixed?

Accepted Answer

Use 'exec < /dev/tty' at the start of the script. Both `read input < /dev/tty` and `exec < /dev/tty` at the script start redirect input to the controlling terminal, fixing the issue. The example `./script.sh | othercommand` pipes stdout, not stdin, so it would not cause the described problem.

Answer

Use 'stdbuf -i0' before the script invocation to set stdin unbuffered

Answer

Use 'read -t 0 input' to force immediate read