EX200 Create simple shell scripts Practice Question
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?
⚠ Common exam trap
Test-takers frequently think using #!/bin/sh is always safer for compatibility, but they overlook that it can break scripts relying on bash-specific features, and they may also believe invoking the interpreter directly is always acceptable, ignoring the portability and clarity benefits of an executable script with a shebang.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
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 analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use #!/bin/sh for compatibility, even if bash-specific features are needed.
Why it's wrong here
The shebang line must name the interpreter that actually executes the script; on modern Debian/Ubuntu systems /bin/sh is dash, a POSIX-only shell lacking bash arrays, [[ ]], and process substitution. Declaring #!/bin/sh while using bashisms leads to runtime syntax errors or unexpected behavior. For compatibility with bash features, explicitly use #!/bin/bash or, better, write POSIX-compliant code if portability is required.
- ✓
Quote variables when used in commands, e.g., "$file" instead of $file.
Why this is correct
Unquoted variable expansions are subject to word splitting and pathname expansion, so a filename like 'My File.txt' would be split into two arguments, and a value containing '*' could expand to multiple files. Quoting, as in "$file", preserves the variable's value as one literal argument, preventing these transformations. This is essential when handling user input, file paths, or any value with whitespace or glob characters.
- ✓
Start the script with a shebang line, e.g., #!/bin/bash.
Why this is correct
A shebang line, such as #!/bin/bash, tells the operating system kernel which interpreter to invoke when the script is executed directly, and it must be the first line of the file. Without it, execution may fail with 'permission denied' or fall back to the current shell, which may not support the script's syntax. Choosing the correct shebang ensures the script runs in a predictable environment and that bash-specific features are available.
- ✓
Include set -e at the beginning of the script to exit on any error.
Why this is correct
set -e makes the script abort immediately when any command or simple pipeline returns a non-zero exit status, so errors do not silently cascade. This is a common reliability safeguard, but it has caveats: it is ignored in conditional contexts like if or while tests, and commands whose failure is expected must be explicitly handled. Used thoughtfully, it improves deterministic behavior and simplifies debugging.
- ✗
Always run scripts by invoking the interpreter directly (e.g., bash script.sh) instead of making them executable.
Why it's wrong here
Running a script with bash script.sh works, but it skips the shebang and negates the purpose of making the file executable, which is required for it to be invoked by name from PATH with ./script.sh. The executable bit and shebang together allow the kernel to select the correct interpreter automatically, and they are the standard for distributing scripts. Requiring users to know the interpreter reduces portability and convenience.
Go deeper
Related to this question
About these practice questions
This EX200 question is part of Courseiva's 427-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX200 exam.