An administrator must apply the same schema change to 40 database servers overnight, unattended, using identical steps on each and keeping a log of each server's result. Which approach best meets this need?
Select an answer to reveal the explanation.
Short Explanation
Clicking through a GUI forty times is forty chances to miss a step. A command-line script does the same thing every time, runs while you sleep and leaves a log behind. That's the repeatability the stem is pointing you toward.
Full Explanation
Command-line scripting turns a change into a repeatable, unattended procedure. A script that reads a list of servers, connects to each with a command-line database client, applies the same change file and writes the outcome to a log ensures identical steps everywhere, runs without anyone present, and leaves evidence of which servers succeeded or failed. The script itself can be stored in version control and reviewed through change management. Running the change by hand in a GUI on each server is interactive work that cannot happen unattended overnight, and manual repetition invites skipped or altered steps across 40 servers. Emailing the script to server owners distributes execution across many people and schedules, removes central logging, and ignores the overnight window. Replication copies data or changes between linked databases in a defined topology; these are 40 independent servers, and many replication setups do not propagate schema changes, so relying on it would leave most servers unchanged. Exam caveat: automation amplifies mistakes as easily as it repeats success, so the script should be tested on non-production servers and should stop or alert on failure rather than continuing blindly. Operational check: run the script against two test servers, review the log for each, verify the schema change in the data dictionary on both, and then schedule the production run.