Inside configure_app.sh the value of DB_CONN_STRING is blank. The administrator wants the variable to be visible to the helper script (and any other child processes started by the provisioning script) but to disappear as soon as the provisioning script ends. Which change best satisfies this requirement?
Append DB_CONN_STRING="postgres://svc_db@db01/prod" to /etc/environment using sudo tee, then reload the environment.
In Bash, a simple assignment such as VAR=value creates a shell variable that is scoped only to the current shell; child processes do not inherit it. Using the export (or declare -x) built-in converts the shell variable into an environment variable, causing it to be copied into the environment of every child process that the script starts. The variable still lives only for the life of the current shell session, so it is gone as soon as the provisioning script finishes. Writing the variable into /etc/environment would make it persistent system-wide-far beyond the scope required. Running the helper script with sudo does not guarantee that the new environment variable is passed (sudo typically resets the environment unless configured otherwise). Marking the variable read-only with declare -r prevents modification but does nothing to export it. Therefore, adding export DB_CONN_STRING="postgres://svc_db@db01/prod" (or placing export in front of the assignment) is the only option that meets all stated requirements.
Ask Bash
Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.
What is the difference between a shell variable and an environment variable in Bash?
Open an interactive chat with Bash
Why doesn’t running a script with `sudo` automatically pass all environment variables?
Open an interactive chat with Bash
How does the `export` command interact with child processes spawned by a script?