The answer is including set -e at the beginning of the script to exit on any error, along with quoting variables and using meaningful names. The set -e directive immediately halts execution if any command fails, preventing cascading failures that could corrupt data or leave the system in an inconsistent state. Quoting variables like "$file" is equally critical because it prevents word splitting and glob expansion, ensuring that filenames with spaces or special characters are treated as single arguments rather than being broken apart or expanded unexpectedly. On the Red Hat Certified System Administrator EX200 exam, these shell script best practices for RHEL test your ability to write scripts that are robust in production environments, where unquoted variables are a common trap that leads to silent failures or security vulnerabilities. A frequent exam trick is presenting a script without set -e that continues running after a critical command fails, or showing variable expansion without quotes that breaks on filenames containing spaces. Remember the mnemonic "Quote, Exit, Name" — quote all variables, exit on first error, and use descriptive names — to keep your scripts reliable and maintainable.
EX200 Create simple shell scripts Practice Question
This EX200 practice question tests your understanding of create simple shell scripts. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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?
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.
Option B is correct because 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.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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
Should match the shell used; using /bin/sh may not support bash extensions.
✓
Quote variables when used in commands, e.g., "$file" instead of $file.
Why this is correct
Prevents unintended word splitting and pathname expansion.
Related concept
Read the scenario before looking for a memorised answer.
✓
Start the script with a shebang line, e.g., #!/bin/bash.
Why this is correct
Specifies the interpreter explicitly.
Related concept
Read the scenario before looking for a memorised answer.
✓
Include set -e at the beginning of the script to exit on any error.
Why this is correct
Improves reliability by stopping on failures.
Related concept
Read the scenario before looking for a memorised answer.
✗
Always run scripts by invoking the interpreter directly (e.g., bash script.sh) instead of making them executable.
Why it's wrong here
Making scripts executable and using ./script.sh is standard; invoking interpreter directly is less convenient.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates may 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.
Detailed technical explanation
How to think about this question
When a variable is unquoted in a shell command, the shell performs word splitting (based on IFS) and pathname expansion (globbing) on its value. For example, if $file contains 'my file.txt', unquoted it becomes two arguments 'my' and 'file.txt', potentially causing errors or security issues. Quoting suppresses these expansions, ensuring the variable's value is passed as a single argument, which is critical when handling filenames with spaces or special characters.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Create simple shell scripts — This question tests Create simple shell scripts — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Quote variables when used in commands, e.g., "$file" instead of $file. — Option B is correct because 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.
What should I do if I get this EX200 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following are true about creating simple shell scripts in Red Hat Enterprise Linux?
easy
✓ A.The shebang line (e.g., #!/bin/bash) is used to specify the interpreter.
B.Scripts must be stored in /usr/local/bin to be found by the shell.
✓ C.The script file must have execute permission (chmod +x) to be run directly.
D.A script must be compiled before it can be run.
E.A script must have a .sh file extension to be executable.
Why A: Option A is correct because 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.
Variation 2. A developer wrote a shell script that is intended to back up log files by copying all .log files from /var/log/myapp to /backup/logs. The script runs daily via cron but the backup folder is empty. The script contains the following line: `cp /var/log/myapp/*.log /backup/logs/`. What is the most likely reason the backup fails?
easy
A.The PATH variable in cron is not set, so cp cannot be found.
B.The script does not have execute permission for the user running cron.
✓ C.No .log files exist in /var/log/myapp at the time of script execution, causing the glob to match nothing.
D.The cron job is not enabled because the crontab syntax is incorrect.
Why C: Option C is correct because the glob pattern `*.log` in the `cp` command is expanded by the shell at the time the script runs. If no `.log` files exist in `/var/log/myapp` when the cron job executes, the shell passes the literal string `*.log` to `cp`, which then fails with a 'No such file or directory' error (or, depending on shell settings, may silently do nothing). This is a common issue when log rotation or cleanup removes files before the backup runs.
Last reviewed: Jun 11, 2026
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.