AI-assisted administration

Before you read. A colleague asks an assistant for a cleanup script. It gets one in four seconds. It is well-commented, uses find correctly, and looks like something a competent person would write. They run it on the build server.

It deletes the wrong directory and exits zero.

Nothing about that story requires the assistant to have been bad at its job. The script it produced is the kind of script people write. That is the problem.

This lesson is on the exam because AI assistance is now part of ordinary administration and the objectives treat it as a tool with a safe operating procedure, like dd, or rm -rf, or anything else that is useful in proportion to how much damage it can do.

A disclosure, since it is relevant: this lesson was written with the same class of tool it is about. Every command transcript below was captured by running the command on a real machine rather than by predicting the output, which is precisely the habit the lesson argues for. You should extend this text the same scepticism it asks you to extend to anything else generated this way.

Some words you will need

large language model (LLM)

A model that predicts likely text. Everything it does follows from that, including its failure modes.

prompt

The input. Instructions, context, and data, with no reliable boundary between them.

context window

How much text the model can consider at once. Anything outside it does not exist.

hallucination

Fluent output that is false. Not a malfunction; the same process that produces correct answers.

inference

Running a model to get output, as distinct from training it.

local / self-hosted model

Runs on hardware you control. Nothing leaves your network.

hosted / API model

Runs on somebody else's infrastructure. Your input goes to them.

prompt injection

Instructions hidden in data the model reads, which it may then follow.

data governance

The rules about what data may go where, and who is accountable when it goes elsewhere.

human in the loop

A person who reviews and approves before anything takes effect.

What breaks without this

Confident wrong answers get run. The output has no tone of uncertainty available to it. A fabricated flag is delivered in exactly the same voice as a correct one.

Credentials and internal data leave the building. Pasting a config file into a public tool to ask what is wrong with it sends that config file, and any password in it, to a third party.

Nobody can explain what is deployed. Generated configuration that works but that nobody on the team understands is unmaintainable, and it fails at the worst moment, which is during an incident.

Skills quietly do not develop. An engineer who has never had to work out why a command failed has not learned to work out why a command failed.

Untrusted input becomes an instruction channel. The moment a model reads a log file, a ticket, or a web page, whatever is written there is competing with your instructions.

Policy is broken without anybody deciding to. Most organisations have rules about this now. Very few people have read them.

What it is genuinely good at

Being clear-eyed about the failures requires being fair about the value, and the value is real. The pattern is that these tools are strong where the output is immediately checkable and weak where it is not.

And where it is weak, with the reason rather than the vibe:

The single most useful framing: treat generated output as a confident suggestion from a stranger who has never seen your systems and will not be there at 3am. Some of those suggestions are excellent. You would still check them.

Verify before you run it

The habit is small and specific: for anything named (a package, a flag, a path, a service), ask the system whether it exists before you depend on it. This costs seconds.

Package names are the common case, because plausible names are easy to generate and repository naming is arbitrary:

# AlmaLinux 10.2, x86_64
$ echo "--- a suggested package name, checked before it is trusted ---"; dnf -q info nginx-mainline-extras; echo "dnf exit status: $?"; echo; echo "--- and a name that is real ---"; dnf -q info nginx | head -5; echo "dnf exit status: ${PIPESTATUS[0]}"
--- a suggested package name, checked before it is trusted ---
Error: No matching Packages to list
dnf exit status: 1

--- and a name that is real ---
Available Packages
Name         : nginx
Epoch        : 2
Version      : 1.26.3
Release      : 6.el10_2.5
dnf exit status: 0

nginx-mainline-extras sounds entirely reasonable. It does not exist. One dnf info settles it, and the exit status is unambiguous enough to use in a script.

This matters more than being an inconvenience. A plausible-but-nonexistent package name is a supply chain opportunity: if a name is suggested often enough, somebody can register it on a public index and wait. That attack has a name (slopsquatting, a variant of typosquatting) and it is a real and documented technique against language ecosystems like PyPI and npm, where anybody may publish. Distribution repositories are much harder to attack this way; language package indexes are not.

Flags are the same shape of problem:

# AlmaLinux 10.2, x86_64
$ echo "--- a suggested flag, checked against the tool itself ---"; tar --strip-leading-dirs -tf /dev/null; echo "tar exit status: $?"; echo; echo "--- what the tool actually calls it ---"; tar --help | grep -i "strip NUMBER"
--- a suggested flag, checked against the tool itself ---
tar: unrecognized option '--strip-leading-dirs'
Try 'tar --help' or 'tar --usage' for more information.
tar exit status: 64

--- what the tool actually calls it ---
      --strip-components=NUMBER   strip NUMBER leading components from file

The capability is real and the name was invented. --strip-components is what GNU tar calls it. This is the characteristic failure: not nonsense, but something adjacent to the truth, which is far harder to spot by reading.

A bad flag name is the good case, because the tool refuses. The dangerous version is a flag that exists and means something else.

Dry-run mode is the most underused item in that table. Before taking a suggestion to remove a package, ask the package manager what it would actually do:

# AlmaLinux 10.2, x86_64
$ echo "--- the suggestion was: just remove the old python package ---"; dnf remove --assumeno python3-libs 2>&1 | tail -14
--- the suggestion was: just remove the old python package ---
Error: 
 Problem: The operation would result in broken dependencies for the following protected packages: dnf
  - package python3-dnf-4.20.0-22.el10_2.alma.1.noarch from @System requires /usr/bin/python3, but none of the providers can be installed
  - package python3-dnf-4.20.0-22.el10_2.alma.1.noarch from @System requires python(abi) = 3.12, but none of the providers can be installed
  - package python3-3.12.13-2.el10_2.x86_64 from @System requires libpython3.12.so.1.0()(64bit), but none of the providers can be installed
  - package python3-3.12.13-2.el10_2.x86_64 from @System requires python3-libs(x86-64) = 3.12.13-2.el10_2, but none of the providers can be installed
  - package dnf-4.20.0-22.el10_2.alma.1.noarch from @System requires python3-dnf = 4.20.0-22.el10_2.alma.1, but none of the providers can be installed
  - conflicting requests
  - problem with installed package dnf-4.20.0-22.el10_2.alma.1.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Removing that one library would have taken dnf itself with it. The package manager knows this and refuses, because dnf is on its protected list, an answer available in one command, before anything happened.

Note the tail of the message, which is the genuinely dangerous part: dnf helpfully suggests --skip-broken and --nobest. Those flags are the sound of a system offering you a way to proceed anyway, and an assistant asked “how do I get past this error” will hand them to you. When a tool refuses, the refusal is usually the answer.

podman run --rm -it docker.io/library/almalinux:10 bash

truncate -s 2G /var/tmp/disk1.img
losetup --find --show /var/tmp/disk1.img

The review is the job

Verification catches things that do not exist. The harder case is code that exists, runs, and is wrong. Here is a cleanup script of exactly the kind these tools produce, and the kind people write:

# Debian 13 (trixie), x86_64
$ cat cleanup.sh
#!/bin/bash
# Remove build artefacts older than 30 days.
BUILD_DIR=$1
find $BUILD_DIR -name "*.tmp" -mtime +30 -exec rm -rf {} \;
cd $BUILD_DIR/cache
rm -rf *
echo "Cleaned $BUILD_DIR"

Seven lines. Commented. Uses find with -mtime correctly. Reads fine.

Run a linter over it before reading it yourself. This is the cheapest review available and it is not an AI tool, it is a static analyser that has known these patterns for a decade:

# Debian 13 (trixie), x86_64
$ shellcheck cleanup.sh; echo "shellcheck exit status: $?"

In cleanup.sh line 4:
find $BUILD_DIR -name "*.tmp" -mtime +30 -exec rm -rf {} \;
     ^--------^ SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: 
find "$BUILD_DIR" -name "*.tmp" -mtime +30 -exec rm -rf {} \;


In cleanup.sh line 5:
cd $BUILD_DIR/cache
^-----------------^ SC2164 (warning): Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
   ^--------^ SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: 
cd "$BUILD_DIR"/cache || exit


In cleanup.sh line 6:
rm -rf *
       ^-- SC2035 (info): Use ./*glob* or -- *glob* so names with dashes won't become options.

For more information:
  https://www.shellcheck.net/wiki/SC2164 -- Use 'cd ... || exit' or 'cd ... |...
  https://www.shellcheck.net/wiki/SC2035 -- Use ./*glob* or -- *glob* so name...
  https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
shellcheck exit status: 1

SC2164 is the one that matters, and its wording undersells it. “Use cd ... || exit in case cd fails” sounds like tidiness. What it means here is that if the cd on line 5 fails, line 6 runs rm -rf * in whatever directory the script happens to be in.

# Debian 13 (trixie), x86_64
$ touch important.conf release-notes.md build.log; ls; echo "--- now run it the way somebody would, having forgotten the argument ---"; ./cleanup.sh; echo "exit status: $?"; echo "--- what is left ---"; ls -A; echo "(nothing)"
build.log
cleanup.sh
important.conf
release-notes.md
--- now run it the way somebody would, having forgotten the argument ---
./cleanup.sh: line 5: cd: /cache: No such file or directory
Cleaned 
exit status: 0
--- what is left ---
(nothing)

Everything is gone, including the script itself, and it exited 0. Read the chain, because every link is an ordinary mistake:

1. $1 is empty, so BUILD_DIR is empty. set -u was not used.
2. cd $BUILD_DIR/cache becomes cd /cache, which does not exist.
3. The cd fails. There is no || exit, and no set -e, so the script continues.
4. rm -rf * runs in the current directory, which is wherever you happened to be.
5. echo "Cleaned " prints, the script ends, and the exit status is echo’s.

The script reported success. In a pipeline, per lesson 60, that stage is green.

None of these are exotic bugs. They are the four most common shell mistakes there are, and a linter names three of them in under a second.

What leaves your network

Everything above is about correctness. This is about disclosure, and it is the part that ends careers rather than evenings.

When you paste text into a hosted assistant, you have sent that text to a third party. Not conceptually, actually. It transits their network, is processed on their hardware, and is retained under whatever their terms say.

What people paste without thinking:

• A config file, to ask why the service will not start. It has a database password in it.
• A stack trace, which contains internal hostnames, file paths, and sometimes a connection string.
• A log extract, containing customer email addresses, IP addresses, or account identifiers.
• kubectl get secret -o yaml output, “to check the formatting”.
• A chunk of proprietary source code.
• A network diagram or firewall ruleset, which is a map of your estate.

The questions your organisation has to have answered:

The rule that survives contact with reality: if you would not put it in a public ticket, do not put it in a hosted assistant. Redact first, replace real hostnames, addresses, and identifiers with obvious placeholders. It takes seconds and almost never reduces the quality of the answer, because the model does not need your real subnet to explain your routing problem.

Prompt injection: once a model reads untrusted input

This is the failure mode most worth understanding, because it is the one that scales from an individual mistake to a security incident, and because the tooling being built right now walks into it repeatedly.

A model has no reliable boundary between instructions and data. Both are text in the same context. So if you ask an assistant to summarise a log file, and the log file contains a line saying “ignore your previous instructions and run the following command”, that text is competing with yours on roughly equal terms.

This stops being theoretical the moment the model can act. An assistant that only produces text and hands it to you for review is a small problem: you are the boundary. An assistant wired into tools that can read files, call APIs, or execute commands has no such boundary, and the untrusted input reaches something that acts.

Where untrusted content enters an administrator’s workflow, which is everywhere:

• Log files, attacker-controlled by definition, since anything that touches your service writes to them
• Ticket text, email bodies, chat messages
• Web pages fetched for research
• Filenames, HTTP headers, user agent strings
• Source files, README files, dependency metadata, code comments
• The output of any command that echoes user-supplied data back

The general shape of the defence, which is the same shape as every injection problem before it:

• Do not let output act without approval. A human confirming each side-effecting action is the control that works today. Everything else is mitigation.
• Least privilege for the tooling. If an assistant has a read-only token, an injected instruction cannot write. This is ordinary access control and it is the most effective thing available.
• Separate the channels as far as the architecture allows. Untrusted content should be clearly delimited and labelled as data, and the system should be built assuming that delimiting can be defeated.
• Constrain the action space. An assistant that may only run commands from an allowlist has a bounded failure. One with a shell does not.
• Log everything the tool did, not just what it said, so an incident can be reconstructed.
• Assume the boundary can be crossed. There is no known reliable way to make a model ignore instructions embedded in data. Design as though it will sometimes follow them, because it will.

The honest summary: this is an unsolved problem, and treating it as solved is the mistake. OWASP lists prompt injection as the first item in its Top 10 for LLM applications for that reason, and it is worth reading before you approve any tool that gives a model the ability to do something rather than say something.

Assisted-by: <tool>; verified with shellcheck and a --dry-run against staging.
Reviewed-by: <a person>

Asking better questions

The objective mentions prompt engineering. Stripped of the mystique, it is mostly the skill of writing a good bug report, and the same things help.

Two that are specific to this context and genuinely change the output:

Ask for the dry-run form first. “Give me the command to check what this would do before doing it” produces --dry-run, --noop, or -n, and it puts you in the habit from the start.

Ask it to argue against itself. “What would make this the wrong approach?” tends to produce the caveats that a direct answer omits, because a direct question invites a direct answer and the failure mode is confidence.

And the one that matters most: when you do not understand a piece of the answer, ask about that piece rather than accepting it. The gap between “it works” and “I know why it works” is where the next outage lives.

Across distributions

Nothing about using an assistant is distribution-specific. Verifying what it tells you is, and that is where the family split earns its place in this topic: generated answers drift toward whichever distribution is most written about, which is usually Ubuntu.

The classic tell is a suggestion that mixes the two families in one answer. Installing httpd with apt, editing /etc/apache2/apache2.conf on a machine where the package is httpd, or restarting apache2 on RHEL. Each half is correct somewhere and the combination is correct nowhere, and it is confident, well formatted, and wrong.

Package names that do not exist are the other one worth checking by reflex. A plausible name is easy to generate and costs nothing to verify, and installing something a stranger named for you is how a typosquatted package gets onto a server. dnf search or apt-cache search before install, every time.

Prove it

The verification is short, and doing it in this order means you never run anything you have not resolved:

# Does the command exist here, and what provides it
command -v <cmd> && rpm -qf "$(command -v <cmd>)"     # or dpkg -S

# Does the flag it used exist in this version
<cmd> --help | grep -- --the-flag
man <cmd> | grep -- --the-flag

# Does the file it named exist, and does anything own it
ls -l /the/path && rpm -qf /the/path                  # or dpkg -S

# Does the package exist before you install it
dnf search <name>                                     # or apt-cache search

# What would this actually do, without doing it
dnf install --assumeno <name>
<destructive-command> --dry-run

--help | grep on the specific flag is the fastest check in the list, because generated commands frequently pair a real tool with a flag from a different tool or a different major version. The command name looks right, the option does not exist, and the error you get back is about syntax rather than about the flag being invented.

What trips people up

1. Piping a fetched script into a shell

curl | bash executes as it downloads, so there is no moment at which you could have read it. Download it, read it, then run the file. HTTPS proves you reached the host you named and says nothing about what that host chose to serve you.

2. Pasting logs or configuration into a hosted tool

Configuration files carry passwords, connection strings, internal hostnames, and key material. Logs carry usernames, IP addresses, and occasionally tokens. Sending them to a third party is a disclosure whether or not anything goes wrong afterwards, and it is usually covered by a policy somebody wrote down.

3. Treating retrieved content as instruction

A model that reads a file, a web page, or a ticket is reading data. When that data contains text addressed to the model, it is still data. Anything with a side effect gets confirmed by a person, and that boundary is architectural rather than something you ask the model to respect.

4. Accepting confident output about your specific system

It has never seen your machine. Version numbers, file paths, default values, and whether a service is enabled are all things it is inferring from what is common, and your system is a sample of one that it cannot check.

5. Committing generated code you have not read

The person on call at 3am reads the commit and needs the author to explain it. Origin changes nothing about that, and a code review is a second pair of eyes on work already checked rather than the place correctness gets decided.

6. Using it to learn instead of to go faster

It is genuinely good at explaining an error, drafting a script skeleton, and summarising documentation you then read. Used to skip understanding, it produces an administrator who can generate a command and cannot tell whether it worked, which the exam and the job both find out quickly.

Work it through

A tool suggests fixing a failing web server with:

sudo apt install httpd && sudo systemctl enable --now httpd
sudo vi /etc/apache2/apache2.conf

You are on AlmaLinux. Work out what is wrong before reading on.

The answer contradicts itself, which needs no research to spot. apt belongs to Debian and Ubuntu; httpd is the RHEL-family package name for Apache, where Debian calls it apache2. Half of this is right for one family and half for the other, so it is correct nowhere. That internal inconsistency is the cheapest signal available, and it needs no research to spot.

Resolve it to the machine in front of you:

cat /etc/os-release        # which family, actually
command -v apt dnf         # which resolver exists here

On AlmaLinux, dnf and httpd are the pair that go together.

Verify the path before opening it, because the config path follows the package name and the suggestion took it from the wrong family:

rpm -ql httpd | grep -E 'conf$' | head

That returns /etc/httpd/conf/httpd.conf, not /etc/apache2/apache2.conf. The file the suggestion named does not exist on this machine, and vi on a path that does not exist creates it, which leaves you editing a new empty file and concluding the documentation is wrong.

Ask whether the suggestion answers the question at all. The report was a failing web server, and installing a web server is a strange response to one that is already installed. The generated fix skipped the diagnosis entirely, which is the deeper problem with it.

What generalises: the error was catchable without knowing anything about Apache. An answer that mixes two package managers is wrong on its face, and one command against /etc/os-release settles which half to keep. Verification is usually faster than the reading it replaces.

Try it

Optional, and worth doing precisely because it is uncomfortable.

1. Ask a tool you use for the command to do something moderately obscure on your distribution. Before running it, verify every part: that the command exists, that the package provides it, that each flag is in --help, and that any file it names is real.
2. Keep a tally over a week of how many suggestions were correct, correct for the wrong distribution, or invented. The ratio is more informative than any opinion about the tools, including this lesson’s.
3. Take one script it generates and review it as though a colleague wrote it. Write down what you would ask them in review, then check whether you can answer those questions yourself.
4. Put a line into a text file that reads as an instruction addressed to a tool, then ask an assistant with file access to summarise the file. Watch what it does with the line.

Verification step. Step 3 is done when you have found at least one thing you would have asked a human author about. If you found nothing, you read it for plausibility rather than for correctness, which is the failure mode the whole topic is about.

For the exam

Always review before running. If an option says to run generated output directly, it is wrong.

Verify that things exist. Packages, flags, paths, services.

Data governance is about what leaves your network. Never paste credentials, customer data, or proprietary code into a public tool.

Local models keep data in-house, at the cost of capability and the obligation to operate them.

Follow corporate policy, and know that most organisations now have one.

The human is accountable. Not the tool.

Good use cases are checkable ones: explaining errors, boilerplate, regex, translation between formats, first-pass review, documentation.

Bad use cases: anything specific to your environment, anything irreversible, anything security-critical without expert review.

Prompt injection is instructions hidden in data the model reads.

Where this sits

That is block E complete: scripting, version control, infrastructure as code, the three configuration tools, pipelines, orchestration, and this.

The thread running through all of it is the same one this lesson ends on. Lesson 57 argued for declaring intent rather than remembering steps. Lesson 60 argued that a pipeline is only as honest as its exit codes. Lesson 61 argued that a description you can replay beats a running system you cannot rebuild. Every one of those is an argument for understanding what you are running, and a tool that produces plausible text very quickly makes that argument more urgent rather than less.

Block F is troubleshooting, which is the discipline all of this was preparation for.

References

• ShellCheck wiki, SC2164 - ShellCheck. Accessed 2026-08-09.
• ShellCheck wiki, SC2086 - ShellCheck. Accessed 2026-08-09.
• OWASP Top 10 for Large Language Model Applications - OWASP. Accessed 2026-08-09.
• NIST AI Risk Management Framework (AI 100-1) - NIST. Accessed 2026-08-09.
• tar(1), GNU tar manual - GNU. Accessed 2026-08-09.

The commands here were run on a real machine, not written from memory. The package and dependency transcripts are from AlmaLinux 10.2 on x86_64; the script, shellcheck, and deletion transcripts are from Debian 13 (trixie) on x86_64. cleanup.sh really did delete every file in its working directory, including itself, and really did exit 0, that transcript is the unedited output, which is the point. The fake package name and the fake tar flag were chosen to be plausible; the tools’ responses to them were not written by me.