Responsible use of AI in Linux administration

Why this matters

Objective 4.5 did not exist in XK0-005. CompTIA added it for V8 because the tools arrived in the job faster than they arrived in any curriculum, and an administrator who cannot use them is now slower than one who can.

The exam's angle is worth being clear about up front: it tests judgement, not enthusiasm. The questions are about what you send to a public service, what you check before running, and what your organisation's policy allows. The generated command that looks right and quietly does the wrong thing is the scenario, and the answer is always some form of "verify it first".

Which is not a reason for caution theatre. The productivity gain is real and large. The point is that it is a gain in drafting, and drafting is the part of the job that was never the risk.

The lesson

Common use cases

The common use cases where these tools genuinely earn their place, and why each works:

Generation of code. A backup script with logging, error handling and a retention policy — the shape is standard, the details are yours, and starting from a draft is much faster than starting from an empty file. The same for systemd units, cron entries, and any of the boilerplate you have written twenty times and still have to look up.

Generation of regular expressions. This is the strongest case on the list. Regexes are famously write-only: describing what you want in English and receiving a pattern is far quicker than assembling one from memory, and much quicker than reading someone else's afterwards. Asking for an explanation of an existing regex, component by component, is just as useful.

# "match an IPv4 address at the start of a log line, then the timestamp"
^((?:\d{1,3}\.){3}\d{1,3})\s+\[([^\]]+)\]

But test it against your actual data. A regex that is 95% right is a regex that silently drops one line in twenty, and you will not notice — the pipeline still produces plausible output. Run it against a sample where you know the correct count, and compare.

Generation of infrastructure as code. A Terraform module, an Ansible role, a Kubernetes manifest, a compose file. These have a great deal of required structure, and the tools produce a working skeleton quickly.

The caveat is specific and important: generated infrastructure code tends toward permissive defaults. Security groups open to 0.0.0.0/0, storage buckets without encryption, IAM policies with wildcards, containers running as root. Not maliciously — those are the shapes most common in the public examples it learned from. Review the security-relevant lines specifically, and run tofu plan before anything else.

Document code / create documentation. Genuinely one of the best uses, because the information is all present in the code and the task is transformation rather than invention. Explaining a 300-line script somebody left behind, drafting a README, writing comments for a shell function, converting a runbook you have in your head into steps someone else can follow. It also inverts nicely: paste a script and ask what it does before you run something you found on the internet.

Recommendations for how to improve compliance. Given a benchmark — CIS, STIG, PCI DSS — and a configuration, these tools are effective at pointing out where the two diverge and drafting the remediation. "Here is my sshd_config, which CIS Level 1 controls does it fail?" is a question that gets a useful answer, and it is genuinely faster than reading the benchmark end to end.

But the authority is the benchmark, not the model. Use the output to navigate to the actual control, then verify with the real tool:

oscap xccdf eval --profile cis /usr/share/xml/scap/ssg-rhel9-ds.xml

A compliance claim you cannot trace to a control number is not a compliance claim.

Security review. Reading a script for injection risks, unquoted variables, world-writable files, hard-coded credentials, curl | bash patterns. It is a good extra reviewer — it never gets bored, and it catches the class of thing a human skims past on a Friday. It is not a substitute for a scanner or for someone who knows your environment, and it will miss logic flaws that depend on context it does not have.

Code optimization. Rewriting a script that shells out in a loop, replacing a chain of grep | awk | sed with one awk, spotting an O(n²) pattern in a Python function. Useful, and the one where you must measure rather than trust: benchmark before and after, because "this is faster" is a claim, and occasionally a wrong one.

Code linting. Slightly different in that the deterministic tools are better at it and should run first — shellcheck, ruff, ansible-lint, yamllint, hadolint. They are exact and they do not invent. Where a model adds value is explaining why a lint warning matters and what the fix should be, which is often not obvious from the message.

shellcheck deploy.sh          # run this FIRST -- it is exact
ruff check scripts/
ansible-lint playbooks/

The general division: deterministic tools for facts, models for drafting and explanation.

Prompt engineering

Prompt engineering is the practical skill of asking well, and for administration work it comes down to supplying context that the model cannot guess.

A weak prompt and a good one differ mostly in specifics:

"write a backup script"

versus

"Write a bash script for RHEL 9 that backs up /var/lib/postgresql to /backup/db using pg_dump, keeps 14 days of backups, logs to /var/log/db-backup.log with timestamps, exits non-zero and logs the failure if the dump fails, and is safe to run from cron with a minimal environment. Use set -euo pipefail."

What makes the second work:

• The environment: distribution, version, shell, package manager. A Debian answer on a RHEL box wastes your time.
• The constraints: retention, paths, logging, exit behaviour.
• The failure modes you care about: cron's minimal environment is exactly the kind of thing that gets forgotten.
• The conventions you want followed.

Other techniques that measurably help: ask it to explain its reasoning before the code, which surfaces a wrong assumption before you have read a hundred lines built on it; ask for the failure modes of what it just wrote; give it an example of the input and the output you want; and iterate rather than expecting one shot — "now handle the case where the disk is full" is a normal second message.

Ask for what you do not want, too. "Do not use eval", "no curl | bash", "POSIX sh, not bash" all work.

Verify output

Verify output is the rule the whole objective is built around, and it has a concrete procedure rather than being general advice.

Read every line before running it. Not skim — read. The failure mode is specific: generated code is fluent, confident, well-commented and plausible-looking, which suppresses exactly the scepticism you would apply to a Stack Overflow answer written in broken English. Fluency is not correctness, and the correlation between how right something sounds and how right it is, is weaker than it feels.

Models invent things that do not exist. Command flags, module names, configuration options, file paths — usually plausible, occasionally sufficiently plausible that you would swear you had used them. Check with the authority:

man rsync                    # does the flag exist?
rsync --help | grep -- --the-flag
tofu plan                    # what would ACTUALLY change
ansible-playbook site.yml --check --diff
podman run --rm -it image sh -c 'the command'   # try it somewhere disposable

Test in a non-production environment. A VM, a container, a scratch directory. Something you can destroy.

Be most careful with the destructive commands — rm -rf, dd, mkfs, sed -i, DROP, --force, truncate. Any generated command containing one gets read twice, and its target checked. A path built from a variable that could be empty is the specific thing to look for, because rm -rf "$dir"/ with dir unset deletes from /.

Avoid copy/paste without review/quality assurance is CompTIA's phrasing of the same rule, and it is on the objectives verbatim because it is the mistake people actually make. Pasting a generated block straight into a terminal on a production host is the whole risk in one action. Paste it into an editor first; the extra three seconds is the entire quality assurance step.

The standard worth holding: you are the author. Whatever produced the draft, the change is yours, your name is on the commit, and "the AI wrote it" has never once been an acceptable answer in an incident review.

Human review

Human review is the process version of the same principle: generated code goes through the same pull request, the same reviewer and the same pipeline as anything else. No separate fast lane.

Two failure modes worth naming, because they are the ones that occur:

Volume overwhelming review. These tools make it easy to produce far more change than anyone can meaningfully review, and a reviewer facing 2,000 lines approves it. Keep changes small enough to actually be reviewed — the constraint that used to be enforced by how long writing took now has to be enforced deliberately.

Automation bias. Reviewers trust generated output more than they would trust a colleague's, because it reads as authoritative and has no ego attached. The correct posture is the reverse: a colleague understands your environment and a model does not.

For anything security-relevant — authentication, permissions, network exposure, cryptography, secrets handling — human review by someone competent in that area is not optional, whatever wrote the first draft.

Data governance

Data governance is the question of what leaves your organisation, and it is where the exam's real emphasis sits.

When you paste something into a public AI service, you have sent it to a third party. That is a disclosure. It may be logged, retained, reviewed by staff for abuse monitoring, or — depending on the terms — used for training. It is outside your network and outside your control, and no amount of the service being trustworthy changes the fact that the data left.

Never paste:

• Passwords, API keys, tokens, private keys, certificates
• Real customer or employee data, or anything personally identifying
• Internal IP addressing, hostnames, network topology
• Proprietary source code, where policy forbids it
• Anything regulated — health records, payment card data, anything under GDPR
• Security findings, vulnerability details, incident specifics

The workable habit is to sanitise before asking. The question is almost never about your real values:

# instead of pasting the real thing
ssh admin@10.4.19.22 'grep "payment failed for user bob@realcustomer.com" /var/log/app.log'

# ask about the shape
ssh user@host 'grep "PATTERN" /var/log/app.log'

You lose nothing — the answer to "how do I grep a remote log" does not depend on the hostname — and you have disclosed nothing.

Security of data extends the same thought to what you get back and where it goes. Generated code arrives with no provenance and no licence, and it goes into your repository, so treat it as untrusted input until reviewed. Do not let a tool with repository access push unreviewed. And be aware that a model with access to your files can quote them into a context you did not intend.

Large language model training is the specific concern behind the paste rule. A model is trained on large text corpora, and services differ in whether your inputs join that corpus. Consumer tiers often train on conversations by default; business and enterprise tiers generally do not, contractually. Know which tier you are on, because the difference is whether your configuration file might be recalled in someone else's session. The exam's expected answer to "is it safe to paste this?" starts with what the terms say about training.

Retention matters separately from training: a service may not train on your data and still keep it for thirty days, which is thirty days of exposure to a breach at that provider.

Private versus public, and local models

Private vs. public is the deployment decision, and it is mostly a question of what you are allowed to send:

Local models run entirely on your own hardware, and this is the option worth knowing about for the exam and worth having tried in practice:

# Ollama is the usual entry point
curl -fsSL https://ollama.com/install.sh | sh     # read it first, obviously
ollama pull llama3.1
ollama run llama3.1 "explain this sshd_config line: MaxStartups 10:30:60"
ollama list

The trade is capability for control. A model that fits on a workstation GPU is noticeably weaker than the largest hosted ones — but for explaining a config line, drafting a regex, or reviewing a script, it is entirely adequate. And nothing leaves the machine, which means the paste rules above simply do not apply: an air-gapped environment, a classified network, or a regulated workload can use one where a public service is prohibited outright.

That is the point to carry: the answer to "we cannot send this data anywhere" is not "then we cannot use these tools", it is a local model.

Adhere to corporate policy

Adhere to corporate policy is on the objectives as its own sub-topic because it is the sub-topic that actually decides everything above.

Organisations differ enormously — some ban public services outright, some approve specific ones, some run their own, some have no policy yet. What is required of you is the same in every case: find out before you use them, not after. Ask which tools are approved, what data classifications may be sent, whether generated code needs marking or extra review, and who to ask when the policy does not cover your case.

Where there is no policy, do not read that as permission. Assume the conservative position — nothing sensitive to public services — and ask.

The regulated cases are stricter and worth recognising: HIPAA, PCI DSS, GDPR and government classification schemes all constrain where data may be processed, and a public AI service is a processor in a jurisdiction you did not choose. In those environments, a local model or a contracted private deployment is not a preference, it is the only lawful option.

On the exam

• The use cases: generating code, regular expressions and infrastructure as code; documenting code; compliance recommendations; security review; code optimisation; linting.
• Deterministic tools for facts (shellcheck, ruff, oscap), models for drafting and explanation.
• Prompt engineering = supply the environment, the constraints and the failure modes you care about. Iterate rather than expecting one answer.
• Verify output before running it. Models invent flags, modules and paths that do not exist — check man, --help, tofu plan, --check.
• Avoid copy/paste without review — paste into an editor, never straight into a production terminal. Read destructive commands twice.
• Human review applies to generated code exactly as to written code. Watch for volume that defeats review, and for trusting output because it sounds authoritative.
• Data governance: pasting into a public service is a disclosure to a third party. Never send credentials, customer data, internal topology, or regulated data. Sanitise first — ask about the shape, not the values.
• LLM training: know whether your tier trains on your inputs. Consumer tiers often do; enterprise tiers contractually do not. Retention is a separate question from training.
• Private vs. public vs. local. A local model keeps data on your hardware and works offline, at some cost in capability — the answer for air-gapped and regulated environments.
• Adhere to corporate policy, and where none exists, assume the conservative position and ask.