Courseiva

XK0-006 Automation, Orchestration, and Scripting Practice Question

A Linux administrator schedules a maintenance script with cron using the entry `30 2 * * 1 /usr/local/bin/backup.sh`. The script runs but produces no output and fails silently when executed by cron, though it works when run interactively. Which action best addresses the silent failure?

⚠ Common exam trap

The trap here is believing that moving a cron job's location or adding `nohup` fixes environment-related failures rather than capturing their output.

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

✓

Redirect the script's stdout and stderr to a log file within the crontab entry or script.

Cron runs jobs with a minimal environment and no terminal, so interactive successes can become silent failures. Because cron only emails output when a mail transfer agent is configured, failures frequently vanish. Capturing stdout and stderr to a log file exposes the environment-related errors, such as an incomplete PATH or missing variables, that cause the discrepancy between interactive and scheduled execution.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Move the script to `/etc/cron.d/` so it inherits the system environment.

    Why it's wrong here

    Scripts in `/etc/cron.d/` still run with cron's minimal environment, not the interactive shell's. Relocating the file changes scheduling semantics slightly but does not supply the PATH, variables, or output capture needed. The silent failure would persist because the root cause is the environment and lack of logging, not the crontab's location.

  • ✓

    Redirect the script's stdout and stderr to a log file within the crontab entry or script.

    Why this is correct

    Cron captures any output and mails it, but if mail is unconfigured the output is discarded, so failures go unnoticed. Redirecting stdout and stderr to a file captures cron's environment-specific errors, such as missing PATH entries or permissions, enabling diagnosis. This directly resolves the lack of visibility that makes the cron run appear to fail silently.

  • ✗

    Add the `nohup` command before the script path in the crontab line.

    Why it's wrong here

    `nohup` makes a process immune to hangup signals, which is relevant for interactive sessions, not cron. Cron already detaches jobs from a terminal, so `nohup` adds nothing. It also does not improve visibility into why the script fails, leaving the silent failure unresolved and potentially adding a stray `nohup.out` file depending on the working directory.

  • ✗

    Change the schedule to run every minute so the failure is observed sooner.

    Why it's wrong here

    Increasing frequency does not reveal the cause of the failure and could generate repeated failures or alert noise. The problem is a lack of diagnostic output, not timing. Running more often simply repeats the same silent failure, consuming resources and potentially masking the real issue without providing any logging or environment correction.

About these practice questions

One of 781 original XK0-006 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official CompTIA exam blueprint

This XK0-006 practice question is part of Courseiva's free CompTIA 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 XK0-006 exam.