Shell Automation8 min read•October 2026•Kernelry Staff

Bash Scripting, Error Handling & System Automation

Even in an era of Python and Go, robust Bash scripting remains a core requirement for writing Docker entrypoints, CI/CD runner steps, and emergency triage one-liners. Interviewers assess your knowledge of defensive scripting idioms (set -euo pipefail), signal handling (trap), stream redirection, and efficient text processing using grep, awk, and sed.

Architecture Blueprint

Bash Defensive Execution Flow with Trap & Pipefail

How set -euo pipefail catches hidden failures across command pipelines and delegates cleanup routines to a centralized EXIT trap.

The Core Concept

Bash is the default command-line shell and scripting language on most Linux distributions. Shell scripts automate operating system administration, pipeline steps, container entrypoints, and log parsing by orchestrating Unix utilities and standard streams.

Key Rules of Thumb for Production Systems

•Always start production scripts with set -euo pipefail to halt on errors, unbound variables, and pipeline failures.

•Use trap handlers to clean up temporary directories and lockfiles on exit or termination signals.

•Quote every variable expansion ("$var", "$@") to prevent word splitting and unintended pathname globbing.

•Prefer native arithmetic (( x + 1 )) and built-in parameter expansion over spawning external subshell processes.

Why Production Systems Demand This Depth

Careless shell scripts fail silently on errors, execute incomplete logic when pipes break, accidentally wipe server directories due to unquoted variables, and mishandle POSIX termination signals in Docker containers. Writing defensive, audited scripts prevents catastrophic operational failures.

Common Diagnostic Pitfalls

•Neglecting pipefail: a pipeline like curl -f "$URL" | tar xz reports only the status of tar, so a failed download goes unnoticed. Without -f, curl also exits 0 on an HTTP 404.
•Running rm -rf "$DIR"/ without checking DIR: when it is empty the command becomes rm -rf /. Write "${DIR:?}" so the script stops when DIR is unset or empty.
•Failing to handle signals (SIGTERM/SIGINT) in container entrypoint scripts, causing Docker stop to wait 10 seconds before sending SIGKILL.
•Parsing ls output instead of using native shell globbing for file iteration.

Best Practices for Scenario Drills

•Explain the exact purpose of each flag in set -euo pipefail (-e exits on error, -u exits on unset vars, -o pipefail preserves pipe error codes).
•Discuss how [[ ... ]] provides safer conditional evaluation with regex matching compared to legacy [ ... ] test brackets.
•Demonstrate how exec replaces the current shell process with the target application, allowing PID 1 signal forwarding in Docker.

Worked Production Scenarios

Study real-world outage patterns, diagnostic trees, and clarifying questions.

Writing a Robust Container Entrypoint Script

Difficulty: mid

Scenario Prompt:

“You are writing an entrypoint script for a database migration and application startup container. It must run migrations, catch any failures immediately, clean up temporary credentials on exit, and start the application as PID 1 so it handles SIGTERM cleanly. How do you implement this?”

Substantive Technical Concepts to Hit:

Defensive Shell Flags

Set set -euo pipefail at the top of the script so any failed migration or missing environment variable aborts execution immediately.

Signal Trap and Cleanup

trap cleanup EXIT INT TERM removes temporary credential files if a migration fails. exec replaces the shell, so the trap never runs after it: delete the credentials before the exec line.

Exec Process Replacement

Start the application with exec "$@" (or exec the binary directly) so it replaces the shell process and receives SIGTERM directly as PID 1.

Parameter Expansion Defaults

Use parameter expansion such as "${PORT:-8080}" to supply a default when a variable is unset or empty.

Senior Clarifying Questions to Investigate:

Does the container run as an unprivileged user where temporary files must be restricted to /tmp?
Should migration failures trigger a retry backoff loop or immediately abort the container deployment?
Are database credentials passed as mounted files or environment variables that need redacting from logs?

A Script Works by Hand but Fails from Cron

Difficulty: junior

Scenario Prompt:

“A backup script runs fine when you execute it in your terminal. Scheduled in crontab for 2 AM, it fails every night and nobody sees an error. How do you debug it?”

Substantive Technical Concepts to Hit:

The Minimal Cron Environment

Cron starts jobs with a short PATH (often just /usr/bin:/bin) and almost no environment variables. Commands in /usr/local/bin or variables exported in your shell profile are missing. Set PATH at the top of the crontab or use absolute paths.

Which Shell Runs the Job

Cron runs the command line with /bin/sh unless SHELL is set in the crontab, and it does not read ~/.bashrc. Bash-only syntax on the crontab line itself fails under dash or another POSIX sh, so give the script a #!/usr/bin/env bash line and call it directly.

Capturing Output

Redirect output to a log with >> /var/log/backup.log 2>&1, or set MAILTO, so the error is recorded somewhere. Silent failure is usually lost stderr.

Reproducing the Cron Context

Run the script with env -i /bin/sh -c "/path/to/script" to strip your environment, and cd to a known directory inside the script because cron starts in the user home directory.

Senior Clarifying Questions to Investigate:

Could two runs overlap if one takes longer than the interval, and should the script take a lock with flock?
Which time zone does the cron daemon use on this host, and does that match the intended schedule?
Does the job need credentials that only exist in an interactive session, such as an SSH agent?

Interactive Scenario Drills

That's where we come in.

Explaining architectural trade-offs under time constraints is very different from reading about them.

Kernelry helps you rehearse technical questions, evidence-led debugging, safe next steps, and the clear communication teams expect. The drills adapt to your answer, so you practice the reasoning rather than memorize a company-specific script. During early access, free accounts include ten daily scenarios across our mixed question pool, with no credit card required.

Start Today's Free Drill

Back to All Blog Posts