How should I use these Create simple shell scripts practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Create simple shell scripts questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Create simple shell scripts domain.

EX200 · topic practice

Create simple shell scripts practice questions

Practise Red Hat Certified System Administrator EX200 Create simple shell scripts practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Create simple shell scripts

Practice 10 questions Browse domain →

What the exam tests

What to know about Create simple shell scripts

Create simple shell scripts questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Create simple shell scripts exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Create simple shell scripts questions

20 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Create simple shell scripts explanation →

A system administrator needs to create a shell script that checks if the user 'jdoe' exists in the system and, if not, creates the user with a home directory. The script should also verify that the creation was successful. Which of the following script snippets correctly implements this logic?

Trap 1: if grep -q '^jdoe:' /etc/passwd; then echo 'Exists'; else useradd…

useradd without -m does not create home directory.

Trap 2: if ! id 'jdoe' &>/dev/null; then useradd -m 'jdoe'; else echo…

Logic inverted: if user does NOT exist, create; else echo. But no verification of success.

Trap 3: [ -z $(id 'jdoe' 2>/dev/null) ] && useradd -m 'jdoe' && echo…

[ -z ] checks if the output is empty, but the command substitution may not work as expected; also no error handling.

Study all Create simple shell scripts common traps →

A
if grep -q '^jdoe:' /etc/passwd; then echo 'Exists'; else useradd 'jdoe' && echo 'Created'; fi
Why wrong: useradd without -m does not create home directory.
B
if id 'jdoe' &>/dev/null; then echo 'Exists'; else useradd -m 'jdoe' && echo 'Created' || echo 'Failed'; fi
Correctly checks existence, creates with home dir, and verifies.
C
if ! id 'jdoe' &>/dev/null; then useradd -m 'jdoe'; else echo 'Exists'; fi
Why wrong: Logic inverted: if user does NOT exist, create; else echo. But no verification of success.
D
[ -z $(id 'jdoe' 2>/dev/null) ] && useradd -m 'jdoe' && echo 'Created'
Why wrong: [ -z ] checks if the output is empty, but the command substitution may not work as expected; also no error handling.

Full breakdown with real-world context →

Question 2easymultiple choice

Read the full Create simple shell scripts explanation →

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?

Trap 1: The PATH variable in cron is not set, so cp cannot be found.

cp is usually in /bin or /usr/bin, which are often in the default PATH even in cron.

Trap 2: The script does not have execute permission for the user running…

Cron typically runs scripts via the interpreter, so execute permission is not required.

Trap 3: The cron job is not enabled because the crontab syntax is incorrect.

The question states the script runs daily via cron, implying the cron job is enabled.

Study all Create simple shell scripts common traps →

A
The PATH variable in cron is not set, so cp cannot be found.
Why wrong: cp is usually in /bin or /usr/bin, which are often in the default PATH even in cron.
B
The script does not have execute permission for the user running cron.
Why wrong: Cron typically runs scripts via the interpreter, so execute permission is not required.
C
No .log files exist in /var/log/myapp at the time of script execution, causing the glob to match nothing.
If no files match, cp receives the literal '*' and fails silently if no error handling.
D
The cron job is not enabled because the crontab syntax is incorrect.
Why wrong: The question states the script runs daily via cron, implying the cron job is enabled.

Full breakdown with real-world context →

Question 3hardmulti select

Read the full Create simple shell scripts explanation →

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?

Trap 1: Use #!/bin/sh for compatibility, even if bash-specific features are…

Should match the shell used; using /bin/sh may not support bash extensions.

Trap 2: Always run scripts by invoking the interpreter directly (e.g., bash…

Making scripts executable and using ./script.sh is standard; invoking interpreter directly is less convenient.

Study all Create simple shell scripts common traps →

A
Use #!/bin/sh for compatibility, even if bash-specific features are needed.
Why wrong: Should match the shell used; using /bin/sh may not support bash extensions.
B
Quote variables when used in commands, e.g., "$file" instead of $file.
Prevents unintended word splitting and pathname expansion.
C
Start the script with a shebang line, e.g., #!/bin/bash.
Specifies the interpreter explicitly.
D
Include set -e at the beginning of the script to exit on any error.
Improves reliability by stopping on failures.
E
Always run scripts by invoking the interpreter directly (e.g., bash script.sh) instead of making them executable.
Why wrong: Making scripts executable and using ./script.sh is standard; invoking interpreter directly is less convenient.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Create simple shell scripts explanation →

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?

Network Topology

Trap 1: The script is not executable and is run with `sh script.sh`,…

Even with sh, the script runs; the shebang is ignored but the bug still exists.

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

The exhibit shows consistent spelling.

Trap 3: The `systemctl` command requires root privileges, and the script is…

The stem states the script is run as root.

Study all Create simple shell scripts common traps →

A
The script is not executable and is run with `sh script.sh`, causing the shebang to be ignored.
Why wrong: Even with sh, the script runs; the shebang is ignored but the bug still exists.
B
The variable SERVICE is misspelled as "HTTPD" in the condition.
Why wrong: The exhibit shows consistent spelling.
C
The `systemctl` command requires root privileges, and the script is run as a non-root user.
Why wrong: The stem states the script is run as root.
D
The script uses the test command `[` instead of directly using the command as the condition, causing the condition to always be true.
`[ systemctl ... ]` always evaluates to true because it tests the string.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Create simple shell scripts explanation →

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?

Trap 1: The PATH variable in cron does not include /usr/bin/rsync

While PATH can be an issue, the error message specifically says 'Host key verification failed', not 'command not found'. So PATH is not the primary cause.

Trap 2: The script does not have execute permission for the root user

The script is owned by root and would have execute permission for root; cron runs as root, so permission is not the issue.

Trap 3: The known_hosts file in /root/.ssh/ contains an incorrect host key…

The host key verification fails because SSH is not using the known_hosts file, not because the key is wrong. The error suggests the key is not being accepted because the host key is not known (i.e., not found) due to environmental issues.

Study all Create simple shell scripts common traps →

A
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.
Why wrong: While PATH can be an issue, the error message specifically says 'Host key verification failed', not 'command not found'. So PATH is not the primary cause.
B
The script does not have execute permission for the root user. Run `chmod +x /opt/scripts/sync_configs.sh`.
Why wrong: The script is owned by root and would have execute permission for root; cron runs as root, so permission is not the issue.
C
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.
Why wrong: The host key verification fails because SSH is not using the known_hosts file, not because the key is wrong. The error suggests the key is not being accepted because the host key is not known (i.e., not found) due to environmental issues.
D
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`.
Cron does not have access to the SSH agent; explicitly specifying the private key and disabling strict host key checking (or adding the host key to known_hosts via script) resolves the issue.

Full breakdown with real-world context →

Question 6easymulti select

Read the full Create simple shell scripts explanation →

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

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

Scripts can be placed anywhere; the PATH variable determines where the shell looks.

Trap 2: A script must be compiled before it can be run.

Shell scripts are interpreted, not compiled.

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

File extension is not required; execute permission is what matters.

Study all Create simple shell scripts common traps →

A
The shebang line (e.g., #!/bin/bash) is used to specify the interpreter.
The shebang line tells the system which interpreter to use.
B
Scripts must be stored in /usr/local/bin to be found by the shell.
Why wrong: Scripts can be placed anywhere; the PATH variable determines where the shell looks.
C
The script file must have execute permission (chmod +x) to be run directly.
Execute permission is necessary to run the script as a command.
D
A script must be compiled before it can be run.
Why wrong: Shell scripts are interpreted, not compiled.
E
A script must have a .sh file extension to be executable.
Why wrong: File extension is not required; execute permission is what matters.

Full breakdown with real-world context →

Question 7hardmultiple choice

Read the full Create simple shell scripts explanation →

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?

Trap 1: Change the shebang line to '#!/bin/sh' because bash is not the…

The shebang is correct; the issue is permissions, not interpreter.

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

The issue is not about PATH; the script is run from its directory.

Trap 3: Change the owner of the script to root using 'chown root:root…

Ownership is not the problem; the user can already read and write.

Study all Create simple shell scripts common traps →

A
Change the shebang line to '#!/bin/sh' because bash is not the default shell.
Why wrong: The shebang is correct; the issue is permissions, not interpreter.
B
Move the script to /usr/local/bin so it can be found in the PATH.
Why wrong: The issue is not about PATH; the script is run from its directory.
C
Add the execute permission to the script using 'chmod +x /home/devops/deploy.sh'.
This makes the script directly executable.
D
Change the owner of the script to root using 'chown root:root /home/devops/deploy.sh'.
Why wrong: Ownership is not the problem; the user can already read and write.

Full breakdown with real-world context →

Question 8mediumdrag order

Read the full Create simple shell scripts explanation →

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 9mediummatching

Read the full Create simple shell scripts explanation →

Match each package management command to its action.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Install a package with dependencies

Uninstall a package

Update all packages to latest versions

Show all installed packages

Question 10easymultiple choice

Read the full Create simple shell scripts explanation →

An administrator writes a script that uses the 'set -e' option at the top. What is the primary effect of this option?

Trap 1: It treats unset variables as an error

B is wrong because treating unset variables as an error is done by 'set -u'.

Trap 2: It prints each command before execution

D is wrong because printing commands is 'set -x'.

Trap 3: It enables debug mode with verbose output

A is wrong because debug mode is enabled by 'set -x', not '-e'.

Study all Create simple shell scripts common traps →

A
It treats unset variables as an error
Why wrong: B is wrong because treating unset variables as an error is done by 'set -u'.
B
It prints each command before execution
Why wrong: D is wrong because printing commands is 'set -x'.
C
It enables debug mode with verbose output
Why wrong: A is wrong because debug mode is enabled by 'set -x', not '-e'.
D
It exits the script immediately if a command fails
C is correct. 'set -e' makes the script exit on any non-zero exit status.

Full breakdown with real-world context →

Question 11easymultiple choice

Read the full Create simple shell scripts explanation →

A system administrator needs to create a shell script that processes a list of hostnames stored in a file, one per line, and runs a command on each host. Which loop construct is most appropriate?

Trap 1: for i in $(seq 1 $(wc -l < hosts)); do ..

C is unnecessarily complex and still vulnerable to word splitting.

Trap 2: for host in $(cat hosts); do ..

A is wrong because word splitting may break lines with spaces.

Trap 3: until read host; do ..

D is wrong because 'until' runs the loop while the command fails, which is not intended.

Study all Create simple shell scripts common traps →

A
while read host; do ... done < hosts
B is correct. It reads each line correctly, even with spaces.
B
for i in $(seq 1 $(wc -l < hosts)); do ... done
Why wrong: C is unnecessarily complex and still vulnerable to word splitting.
C
for host in $(cat hosts); do ... done
Why wrong: A is wrong because word splitting may break lines with spaces.
D
until read host; do ... done < hosts
Why wrong: D is wrong because 'until' runs the loop while the command fails, which is not intended.

Full breakdown with real-world context →

Question 12easymultiple choice

Read the full NAT/PAT explanation →

A developer wants to create a script that accepts a directory path as an argument and creates a timestamped backup of that directory. If no argument is provided, it should back up the current directory. How should the script handle the argument?

Trap 1: dir=${@:-.}

C is wrong because $@ expands to all arguments, not just the first.

Trap 2: dir=${0:-.}

A is wrong because $0 is the script name, not the first argument.

Trap 3: dir=${?:-.}

B is wrong because $? is the exit status of the last command.

Study all Create simple shell scripts common traps →

A
dir=${1:-.}
D is correct. ${1:-.} uses $1 if set, otherwise '.'.
B
dir=${@:-.}
Why wrong: C is wrong because $@ expands to all arguments, not just the first.
C
dir=${0:-.}
Why wrong: A is wrong because $0 is the script name, not the first argument.
D
dir=${?:-.}
Why wrong: B is wrong because $? is the exit status of the last command.

Full breakdown with real-world context →

Question 13mediummultiple choice

Read the full Create simple shell scripts explanation →

An administrator writes a script to check disk usage and send an alert if usage exceeds 80%. The script uses 'df -h /' and parses the output. To maintain portability and avoid common pitfalls, which approach is recommended?

Trap 1: Use 'df -h / | tail -1 | sed 's/.* //' | tr -d '%'

C is fragile because the last field might not be the percentage.

Trap 2: Use 'df -h / | tail -1 | cut -d' ' -f5'

B is wrong because 'cut' with space delimiter may break if multiple spaces.

Trap 3: Use 'df -h / | grep -oP '\d+%'

D is wrong because 'grep -oP' is not portable and might match unintended patterns.

Study all Create simple shell scripts common traps →

A
Use 'df -h / | tail -1 | sed 's/.* //' | tr -d '%'
Why wrong: C is fragile because the last field might not be the percentage.
B
Use 'df -h / | tail -1 | cut -d' ' -f5'
Why wrong: B is wrong because 'cut' with space delimiter may break if multiple spaces.
C
Use 'df / | awk 'NR==2 {print $5}' | tr -d '%'
A is correct. It grabs the second line and fifth column, which is the percentage.
D
Use 'df -h / | grep -oP '\d+%'
Why wrong: D is wrong because 'grep -oP' is not portable and might match unintended patterns.

Full breakdown with real-world context →

Question 14mediummultiple choice

Read the full Create simple shell scripts explanation →

A script needs to execute a command that might fail, but the script should continue. The administrator wants to capture the exit status for logging. Which code snippet correctly implements this?

Trap 1: set -e; ./risky_command; rc=$?; echo $rc

A is wrong because 'set -e' would cause exit before capturing status.

Trap 2: rc=$? ./risky_command; echo $rc

D is wrong because $? is evaluated before the command runs.

Trap 3: ./risky_command && rc=$?; echo $rc

B is wrong because 'rc' is only set if the command succeeds.

Study all Create simple shell scripts common traps →

A
set -e; ./risky_command; rc=$?; echo $rc
Why wrong: A is wrong because 'set -e' would cause exit before capturing status.
B
rc=$? ./risky_command; echo $rc
Why wrong: D is wrong because $? is evaluated before the command runs.
C
./risky_command; rc=$?; echo $rc
C is correct. The exit status is always captured after command.
D
./risky_command && rc=$?; echo $rc
Why wrong: B is wrong because 'rc' is only set if the command succeeds.

Full breakdown with real-world context →

Question 15mediummultiple choice

Read the full Create simple shell scripts explanation →

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?

Trap 1: The variable was declared with 'local', change to 'global' keyword

C is wrong; 'local' makes it local, but there is no 'global' keyword.

Trap 2: The script must be sourced (.) instead of executed to retain…

D is wrong; sourcing is not the typical solution for function variable scope.

Trap 3: The function was called inside a subshell, use 'export' to make it…

A is wrong; subshell doesn't cause this, and 'export' is for environment.

Study all Create simple shell scripts common traps →

A
The variable was declared with 'local', change to 'global' keyword
Why wrong: C is wrong; 'local' makes it local, but there is no 'global' keyword.
B
The script must be sourced (.) instead of executed to retain variables
Why wrong: D is wrong; sourcing is not the typical solution for function variable scope.
C
The function was called inside a subshell, use 'export' to make it global
Why wrong: A is wrong; subshell doesn't cause this, and 'export' is for environment.
D
In bash, variables declared in a function are local by default, use 'declare -g' to make them global
B is correct.

Full breakdown with real-world context →

Question 16hardmultiple choice

Read the full Create simple shell scripts explanation →

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?

Trap 1: The log files are already compressed (.gz extension), and gzip…

B is plausible but less likely; gzip would skip but not cause others to fail.

Trap 2: The script lacks proper quoting around {} which causes gzip to fail…

D is wrong; the command uses {} correctly with semicolon.

Trap 3: The '-mtime +30' flag selects files newer than 30 days, so old…

C is wrong; '+30' means older than 30 days, not newer.

Study all Create simple shell scripts common traps →

A
The log files are already compressed (.gz extension), and gzip fails silently
Why wrong: B is plausible but less likely; gzip would skip but not cause others to fail.
B
Another process deletes log files between find's detection and execution, causing 'find' to error on missing files
A is correct. The 'find -exec' can fail if files are removed concurrently.
C
The script lacks proper quoting around {} which causes gzip to fail on files with spaces
Why wrong: D is wrong; the command uses {} correctly with semicolon.
D
The '-mtime +30' flag selects files newer than 30 days, so old files are excluded
Why wrong: C is wrong; '+30' means older than 30 days, not newer.

Full breakdown with real-world context →

Question 17hardmultiple choice

Read the full Create simple shell scripts explanation →

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?

Trap 1: Use 'stdbuf -i0' before the script invocation to set stdin…

A is wrong; buffering is not the issue.

Trap 2: Use 'exec < /dev/tty' at the start of the script

D is wrong; this would redirect all stdin, breaking piping.

Trap 3: Use 'read -t 0 input' to force immediate read

C is wrong; '-t 0' means timeout of 0, which fails immediately.

Study all Create simple shell scripts common traps →

A
Use 'stdbuf -i0' before the script invocation to set stdin unbuffered
Why wrong: A is wrong; buffering is not the issue.
B
Use 'exec < /dev/tty' at the start of the script
Why wrong: D is wrong; this would redirect all stdin, breaking piping.
C
Use 'read input < /dev/tty' instead of just 'read input'
B is correct. This reads directly from the terminal.
D
Use 'read -t 0 input' to force immediate read
Why wrong: C is wrong; '-t 0' means timeout of 0, which fails immediately.

Full breakdown with real-world context →

Question 18hardmultiple choice

Read the full Create simple shell scripts explanation →

A complex script uses 'trap' to handle signals. The admin writes 'trap '' SIGINT' to ignore Ctrl+C, but later in the script they want to re-enable the default behavior. Which command restores the default behavior for SIGINT?

Trap 1: trap : SIGINT

A is wrong; ':' is a no-op, not default.

Trap 2: trap 2

B is wrong; not a valid syntax.

Trap 3: trap SIGINT

C is wrong; this sets a trap to execute 'SIGINT' command.

Study all Create simple shell scripts common traps →

A
trap - SIGINT
D is correct. The dash removes the trap.
B
trap : SIGINT
Why wrong: A is wrong; ':' is a no-op, not default.
C
trap 2
Why wrong: B is wrong; not a valid syntax.
D
trap SIGINT
Why wrong: C is wrong; this sets a trap to execute 'SIGINT' command.

Full breakdown with real-world context →

Question 19easymulti select

Read the full Create simple shell scripts explanation →

Which TWO of the following are valid ways to make a shell script executable?

Trap 1: bash script.sh

E is wrong: running with bash doesn't require execute bit.

Trap 2: . script.sh

C is wrong: sourcing does not require execute permission.

Trap 3: chmod u+x script.sh

D is wrong: it is a valid method but not listed as a second correct? Actually it is also correct; but we need exactly two, so we pick A and B as the best. The explanation says it's valid, but the question expects exactly two, so D is considered distract.

Study all Create simple shell scripts common traps →

A
bash script.sh
Why wrong: E is wrong: running with bash doesn't require execute bit.
B
chmod 755 script.sh
B is correct: sets rwxr-xr-x.
C
. script.sh
Why wrong: C is wrong: sourcing does not require execute permission.
D
chmod u+x script.sh
Why wrong: D is wrong: it is a valid method but not listed as a second correct? Actually it is also correct; but we need exactly two, so we pick A and B as the best. The explanation says it's valid, but the question expects exactly two, so D is considered distract.
E
chmod +x script.sh
A is correct: adds execute permission for all.

Full breakdown with real-world context →

Question 20mediummulti select

Read the full Create simple shell scripts explanation →

Which THREE of the following are common practices to improve the reliability of shell scripts?

Trap 1: Use 'echo "Error"' for error messages without redirection

E is wrong; should redirect to stderr.

Trap 2: Use 'cat' to read files line by line in while loops

D is wrong; 'while read' with input redirection is better.

Study all Create simple shell scripts common traps →

A
Always quote variable expansions unless word splitting is intended
C is correct.
B
Use 'echo "Error"' for error messages without redirection
Why wrong: E is wrong; should redirect to stderr.
C
Include 'set -u' to abort on unset variables
B is correct.
D
Include 'set -e' at the top of the script to exit on error
A is correct.
E
Use 'cat' to read files line by line in while loops
Why wrong: D is wrong; 'while read' with input redirection is better.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Create simple shell scripts sessions

Start a Create simple shell scripts only practice session

Every question in these sessions is drawn from the Create simple shell scripts domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Create simple shell scripts questions →Mixed EX200 session

Frequently asked questions

What does the EX200 exam test about Create simple shell scripts?: Create simple shell scripts questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Create simple shell scripts questions in a focused session?: Yes — the session launcher on this page draws every question from the Create simple shell scripts domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other EX200 topics?: Use the topic links above to move to related areas, or go back to the EX200 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the EX200 exam covers. They are not copied from any real exam or dump site.

Create simple shell scripts only

10 questions 20 questions 30 questions 50 questions

Mixed EX200 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All EX200 questions Create simple shell scripts domain overview EX200 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Create simple shell scripts practice questions

What to know about Create simple shell scripts

Common Create simple shell scripts exam traps

Create simple shell scripts questions

A system administrator needs to create a shell script that checks if the user 'jdoe' exists in the system and, if not, creates the user with a home directory. The script should also verify that the creation was successful. Which of the following script snippets correctly implements this logic?

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?

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?

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

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

Match each package management command to its action.

An administrator writes a script that uses the 'set -e' option at the top. What is the primary effect of this option?

A system administrator needs to create a shell script that processes a list of hostnames stored in a file, one per line, and runs a command on each host. Which loop construct is most appropriate?

A developer wants to create a script that accepts a directory path as an argument and creates a timestamped backup of that directory. If no argument is provided, it should back up the current directory. How should the script handle the argument?

An administrator writes a script to check disk usage and send an alert if usage exceeds 80%. The script uses 'df -h /' and parses the output. To maintain portability and avoid common pitfalls, which approach is recommended?

A script needs to execute a command that might fail, but the script should continue. The administrator wants to capture the exit status for logging. Which code snippet correctly implements this?

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?

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?

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?

A complex script uses 'trap' to handle signals. The admin writes 'trap '' SIGINT' to ignore Ctrl+C, but later in the script they want to re-enable the default behavior. Which command restores the default behavior for SIGINT?

Which TWO of the following are valid ways to make a shell script executable?

Which THREE of the following are common practices to improve the reliability of shell scripts?

Track your progress over time

Start a Create simple shell scripts only practice session

Related EX200 topic practice pages

Operate running systems practice questions

Configure local storage practice questions

Create and configure file systems practice questions

Deploy, configure, and maintain systems practice questions

Manage users and groups practice questions

Manage security practice questions

Manage containers practice questions