EX200 Essential Tools Practice Question
A system administrator is troubleshooting a cron job that runs a script as root. The script is located at /root/scripts/backup.sh and has permissions 755. The cron job is defined in /etc/crontab with the line: 0 2 * * * root /root/scripts/backup.sh. However, the script does not run at the scheduled time. The administrator checks the cron logs and finds no errors. The administrator then runs the script manually as root and it executes successfully. What is the most likely cause of the cron job not running?
⚠ Common exam trap
Red Hat often tests the misconception that file permissions or cron daemon status are the primary causes of cron job failures, when in reality the minimal cron environment and missing environment variables are the subtle but frequent issue.
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
✓
The cron job line uses absolute path to the script but the script requires an environment variable that is not set in cron's minimal environment.
Cron jobs run with a minimal environment, setting only a few variables (such as HOME, SHELL, LOGNAME, and a default PATH) and not sourcing the user's shell startup files. The script at /root/scripts/backup.sh may rely on an environment variable (e.g., a database password or directory path) defined in root's interactive shell but not in cron's environment. When run manually as root, the variable is available, but cron does not source /root/.bashrc or /root/.bash_profile, causing the script to fail silently or not execute as expected.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The cron job line uses absolute path to the script but the script requires an environment variable that is not set in cron's minimal environment.
Why this is correct
Cron runs with a sparse environment that includes only a few default variables such as HOME, LOGIN, and SHELL, with PATH typically set to /usr/bin:/bin. It does not source /etc/profile or a user's ~/.bash_profile, so any custom environment variable that the script expects—for example, a database password or an application home—will be unset. Even though the script's absolute path is correct and it runs manually, the missing variable causes the script to fail under cron. The solution is to export the variable inside the script or define it explicitly in the crontab.
- ✗
The script is not executable by the root user.
Why it's wrong here
If the script lacked execute permission for the owner, attempting to run it manually would produce a 'Permission denied' error, but the administrator reported that manual execution succeeds. The file permissions of 755 grant the owner (root) read and execute access, so the script is clearly executable by root. Since cron runs the script with the same kernel-level permission checks as a manual run, an invalid permission flag cannot be the cause of the cron-specific failure.
- ✗
The cron daemon is not running.
Why it's wrong here
If the cron daemon (crond) were not running, no cron jobs at all would fire, including any other scheduled maintenance tasks, and the system would show cron service errors or empty cron logs. The fact that only this particular job fails while others presumably run, and that the script executes successfully when invoked by hand, strongly indicates the daemon is operational. A stopped daemon would also prevent the cron job from even being attempted, rather than producing a script-level runtime failure.
- ✗
The /etc/crontab file does not allow running scripts from /root.
Why it's wrong here
There is no inherent restriction in /etc/crontab or in the cron subsystem that forbids executing scripts from /root. Cron simply runs the command as the specified user, and as long as that user (here root) has read and execute permissions on the script, the file location is irrelevant. The script's location in /root may affect environment variables that rely on PATH, but since the cron line uses an absolute path, that is a non-issue. If /root were the problem, the script would also fail when run manually from another directory, which is not the case.
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 427 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.