Prompts module 2: operations jobs, from support to security

Day 15 · 17/11 — Sysadmin: diagnosing from logs

Goal: get a diagnosis grounded in the log lines, not a list of generic causes.

Theory 1/2: the weak prompt

My website is down, what should I do?

Diagnosis: no system, no service, no symptom, no log. The model can only produce the generic checklist every forum has. Missing parts: context, inputs, output format, success criteria.

Theory 2/2: the edited prompt

Context: Debian 13 server, nginx in front of a PHP-FPM app. Since
08:14 the site returns 502. I am the only admin; I can read logs
and restart services, not change the app.
Task: find the most likely cause from the logs below.
Inputs:
<nginx_error>(last 20 lines of /var/log/nginx/error.log)</nginx_error>
<journal>(journalctl -u php8.4-fpm --since "08:00")</journal>
Output: 1) the log line that points to the cause, quoted exactly;
2) the cause in one sentence; 3) one command to confirm it;
4) the fix, without restarting anything else.
If the logs do not show the cause, say so and say what to collect.

Practice (30 min)

1. In a Debian VM, install nginx, then break it: stop the service it proxies to, or put a syntax error in a site file and reload.
2. Collect journalctl -u nginx --since "10 min ago" -p warning and the last lines of the nginx error log.
3. Run the weak prompt, then the edited one, on your local model. Search each quoted line with grep -F.
4. Save the edited prompt as a card prompts/sysadmin-log-diagnosis.md with two test cases: your broken setup and a healthy log (the right answer is "no cause in these logs").

With your AI: "Here is a log excerpt between <log> tags. Do not diagnose. Quiz me: ask me three questions that make me read the lines myself (which service, which time, which error code), then tell me what I missed."

Recap (10 min)

Three lines: what the weak prompt lacked, the four parts of the output, the healthy-log test case and why it matters. Then redo the exercises without notes.

Day 16 · 18/11 — Sysadmin: asking for a script you can trust

Goal: get a shell script with safety built in, and review it before it runs.

Theory 1/2: the weak prompt

Write a script to clean up old files on the server.

Diagnosis: "old" and "files" are undefined, and nothing protects you. A model will happily write find / -mtime +30 -delete. Missing: which directory, which age, which shell, a dry run, logging, what must never be touched.

Theory 2/2: the edited prompt

Write a bash script for Debian 13.
Task: delete files older than 30 days in /var/backups/app only,
never following symbolic links, never leaving that directory.
Constraints: start with set -euo pipefail; default mode is a dry
run that only prints what would be deleted; a --apply flag deletes;
log each deleted path to stdout; no external tools beyond coreutils
and findutils; the script must pass shellcheck with no warning.
Output: the script, then a list of every command it runs and why.

Practice (30 min)

1. Create a test tree: mkdir -p /tmp/lab/app && touch -d "40 days ago" /tmp/lab/app/old.tar && touch /tmp/lab/app/new.tar, and a symlink to /etc inside it.
2. Ask for the script with the edited prompt, pointed at /tmp/lab/app. Read every line before running anything.
3. Run shellcheck on it, then the dry run, then --apply. Check that only old.tar went and /etc is intact.
4. Card: prompts/sysadmin-cleanup-script.md, with the checks you ran.

With your AI: "Review this script line by line [paste]. For each line, say what it does and what could go wrong on a production server. Do not rewrite it; I will fix it myself."

Let an agent do it: now that you have written and reviewed one by hand, a coding agent can draft such scripts and run ShellCheck and the dry run in a lab directory before showing you: "Write the cleanup script from prompts/sysadmin-cleanup-script.md, run shellcheck and a dry run on /tmp/lab/app, and show me the output; do not run --apply." You still read the script and run --apply yourself.

Recap (10 min)

Three lines: scope, dry run, external check. Then redo the exercises without notes.

Day 17 · 19/11 — Support: triage and the reply to the user

Goal: sort a ticket and answer the user in words they understand.

Theory 1/2: the weak prompt

Answer this ticket: "outlook doesnt work since this morning!!!"

Diagnosis: the model does not know your environment, your policy (what the user may do alone) or what a good reply looks like. It will invent steps, perhaps ask the user to reinstall Office. Support prompts need the context of the service desk, the allowed actions and the tone.

Theory 2/2: the edited prompt

Context: IT support for a 40-person firm, Microsoft 365, Windows 11.
Users may restart apps and the PC; they may not install software
or change account settings.
Task 1: classify the ticket: category (email, network, hardware,
account, other), urgency (blocks work: yes or no), missing
information (list).
Task 2: draft a reply to the user: acknowledge, two safe steps they
may try, the one question that would help us most.
Constraints: plain words, under 90 words, no blame, no promise of
a time we cannot keep.
<ticket>outlook doesnt work since this morning!!!</ticket>
Output: JSON for task 1, then the reply text.

Practice (30 min)

1. Write eight short fake tickets (no real names), from vague to precise, with the category you expect for each.
2. Run the edited prompt on all eight at temperature 0; validate the JSON and count right categories.
3. Read each reply as the user would: is any step forbidden by the policy? Note them.
4. Card prompts/support-triage-reply.md with the eight tickets as tests.

With your AI: "Play a frustrated, non-technical user whose e-mail stopped working. I am the support technician. Answer my questions only with what a real user would know; after ten exchanges, tell me which of my questions were useful and which were jargon."

Recap (10 min)

Three lines: what context support prompts need, why two deliverables, what you check in the reply. Then redo the exercises without notes.

Day 18 · 20/11 — Support: a procedure users can follow

Goal: turn a solved ticket into a step-by-step guide for users, and test it on someone.

Theory 1/2: the weak prompt

Write a guide on how to connect to the VPN.

Diagnosis: which VPN client, which system, for whom? The model will produce a plausible guide for some client, with menu names that may not exist in yours. A procedure is only as good as its exact screens and labels, which you must provide.

Theory 2/2: the edited prompt

Context: users are office staff on Windows 11; the VPN client is
already installed. Here are my notes from solving the ticket, with
the exact labels on screen:
<notes>…</notes>
Task: write a procedure for these users.
Constraints: numbered steps, one action per step, the exact label in
bold, what the user should see after each step, a "if it fails" line
at the end with what to send to support. Use only the labels in my
notes; if a step is missing from them, write [MISSING] instead of
guessing.
Output: Markdown.

Practice (30 min)

1. Pick a task you know on your own machine (connecting to Wi-Fi, adding a printer). Write your raw notes with the exact labels.
2. Run the edited prompt. Count [MISSING] markers and invented labels.
3. Give the procedure to someone (or follow it yourself on a fresh account) without helping. Note where they stop.
4. Card prompts/support-procedure.md.

With your AI: "Here is a user procedure [paste]. Pretend you are a user who has never done this. At each step, say what you would click and where you might get lost. Do not fix the procedure."

Recap (10 min)

Three lines: why the labels come from you, the [MISSING] trick, the test on a real person. Then redo the exercises without notes.

Day 19 · 21/11 — Network: troubleshooting with real outputs

Goal: give a model the topology and the command outputs, and get a reasoned diagnosis back.

Theory 1/2: the weak prompt

I can't ping the server. Why?

Diagnosis: no topology, no addresses, no outputs. A ping fails for a dozen reasons on four layers. The model needs the facts you would give a colleague on the phone: where from, where to, what is in between, and what the commands said.

Theory 2/2: the edited prompt

Context: client 192.0.2.10/24, gateway 192.0.2.1; server
198.51.100.20 in another subnet behind the same router.
Other clients in 192.0.2.0/24 reach the server.
Task: find the layer and the most likely cause, step by step,
from the outputs only.
<ip_addr>…</ip_addr> <ip_route>…</ip_route>
<ping>…</ping> <traceroute>…</traceroute>
Output: a table | step | what the output shows | conclusion |, then
the next command to run to confirm. Do not suggest changes on the
router: I have no access to it.

Practice (30 min)

1. In a VM, break the network one way: wrong gateway, wrong mask, or a DNS server that does not answer.
2. Collect the four outputs, plus dig example.com. Replace any real address with a documentation one.
3. Run the edited prompt; check each conclusion against the outputs yourself.
4. Card prompts/network-troubleshoot.md with your broken case and a working one.

With your AI: "Give me a network symptom and the outputs of ip addr, ip route and ping for a small broken setup with documentation addresses. Let me find the fault; give hints one at a time only if I ask."

Recap (10 min)

Three lines: the four outputs, the line that narrows the search, why no router changes. Then redo the exercises without notes.

Day 20 · 22/11 — Network: reviewing a config, and checking the maths yourself

Goal: get a useful config review, and never trust a model's subnet arithmetic unchecked.

Theory 1/2: the weak prompt and the edited one

Weak:   Is my firewall config OK? (paste of 200 lines)
Edited: Review the nftables ruleset below for a web server that
        must accept 80 and 443 from anywhere, 22 only from
        203.0.113.0/24, and nothing else inbound.
        <ruleset>…</ruleset>
        Output: a table | rule (quoted) | what it allows | matches
        the policy: yes or no |, then the rules missing for the
        policy. Do not rewrite the ruleset.

"Is it OK?" has no answer without a policy. With the policy, each rule can be checked against it, and you can verify the table rule by rule.

Theory 2/2: models and arithmetic

Masks, host counts and ranges are exact calculations. Models often get them right and sometimes confidently wrong, because they predict digits rather than compute them. Ask them to show the binary, then check with your own head or with ipcalc. Better: let a tool compute and the model explain.

Practice (30 min)

1. Write a small nftables ruleset with one deliberate hole (22 open to all).
2. Run the edited review. Did it find the hole? Did it flag a correct rule as wrong?
3. Ask the model to split 198.51.100.0/24 into four subnets with their ranges; check every number by hand.
4. Card prompts/network-ruleset-review.md.

With your AI: "Quiz me on subnetting: give me ten prefixes in documentation ranges, one at a time, ask for the mask, the number of hosts and the broadcast address, and correct me. Show your binary working only after my answer."

Recap (10 min)

Three lines: a review needs a policy, why models slip on arithmetic, who computes and who explains. Then redo the drills without notes.

Day 21 · 23/11 — DevOps: reviewing a Dockerfile and a pipeline

Goal: get a review that names concrete problems against stated rules.

Theory 1/2: the weak prompt

Improve this Dockerfile.

Diagnosis: "improve" for what? Size, build time, security, reproducibility pull in different directions. The model will rewrite everything, and you will not know which change matters. A review prompt states the criteria and asks for findings, not a rewrite.

Theory 2/2: the edited prompt

Review this Dockerfile for a Python web app going to production.
Criteria, in order: 1) runs as a non-root user; 2) base image pinned
to a version; 3) no secret in any layer; 4) dependencies installed
before the code is copied, for layer caching; 5) final image size.
<dockerfile>…</dockerfile>
Output: one line per finding: criterion number, the line quoted,
the problem, the smallest fix. If a criterion is met, say "ok".
No full rewrite.

Practice (30 min)

1. Write a deliberately poor Dockerfile: unpinned base, root user, COPY . . before installing dependencies, an ENV secret.
2. Run the edited review; then run hadolint on the same file. Compare the two lists.
3. Do the same with a CI file of your choice (stated criteria: pinned actions, no secret printed, tests before deploy).
4. Card prompts/devops-dockerfile-review.md.

With your AI: "Here are hadolint's findings and a model's review of the same Dockerfile [paste]. For each finding in one list and not the other, explain whether it is a real problem, citing the Docker documentation section I should read."

Recap (10 min)

Three lines: criteria in order, findings not rewrites, the linter as a second opinion. Then redo the exercises without notes.

Day 22 · 24/11 — DevOps: postmortem and runbook

Goal: turn raw incident notes into a blameless postmortem and a runbook step.

Theory 1/2: the weak prompt

Write a postmortem for yesterday's outage.

Diagnosis: the model was not there. It will invent a timeline, a root cause and action items that sound right. A postmortem prompt gives the facts (timeline, logs, chat excerpts), the template, and forbids anything not in them. Google's SRE book describes the blameless postmortem: focus on systems and causes, not on who.

Theory 2/2: the edited prompt

Context: blameless postmortem, internal readers.
Inputs: <timeline>(timestamped notes)</timeline>
<evidence>(log lines, graphs described)</evidence>
Task: fill this template using only the inputs:
Summary / Impact / Timeline / Root cause / What went well /
What went badly / Action items (owner: [TBD], due: [TBD]).
Constraints: no person's name, describe actions by role; every
statement in Root cause cites a timeline entry or an evidence line;
anything not supported is written as an open question.

Practice (30 min)

1. Use yesterday's or day 15's broken lab as the incident. Write a timeline of six timestamped lines and three evidence lines.
2. Run the edited prompt. Underline every sentence and find its source line; anything without one is invented.
3. Ask for one runbook entry: "symptom, check, fix, rollback", from the same inputs.
4. Card prompts/devops-postmortem.md.

With your AI: "Here is my postmortem draft [paste]. Act as the reviewer in a blameless postmortem meeting: ask me five questions about causes and missing evidence, never about who did what."

Recap (10 min)

Three lines: why facts only, why blameless, why [TBD]. Then redo the exercises without notes.

Day 23 · 25/11 — Security: triaging alerts and logs

Goal: get a defensible triage of suspicious log lines, with what to check next.

Theory 1/2: the weak prompt

Am I being hacked? (paste of auth.log)

Diagnosis: a yes or no question invites a dramatic answer. A useful triage counts and groups events, maps them to a known technique, rates confidence, and proposes the next check, while saying what the logs cannot show.

Theory 2/2: the edited prompt

Context: defensive triage of my own server (Debian 13, SSH on 22,
password login enabled). I want to know what happened, not to attack.
<authlog>(excerpt)</authlog>
Task: 1) group events by source address and type, with counts;
2) name the likely technique (MITRE ATT&CK ID if any);
3) say whether any login succeeded, quoting the line;
4) confidence: low, medium, high, and why;
5) the next three checks, as commands.
Say what these logs cannot tell.

Practice (30 min)

1. In your VM, generate failures: ssh wronguser@localhost a few times, then one successful login.
2. Extract journalctl -u ssh --since today; replace addresses with documentation ones.
3. Run the edited prompt. Recount the events with grep -c and compare with the model's counts.
4. Card prompts/security-authlog-triage.md.

With your AI: "Generate a fake auth.log excerpt of 30 lines with documentation addresses that contains exactly one suspicious success among failures. Do not tell me where it is; I will find it, then you confirm."

Let an agent do it: once you have triaged by hand, an agent with read-only shell access can do the counting each morning: "Read today's SSH journal, group failures by source with counts, quote any Accepted line, and write the table to triage.md. Read only: do not change any file outside this directory and do not block any address." You still decide every block yourself.

Recap (10 min)

Three lines: failure versus success, the five outputs, why recount. Then redo the exercises without notes.

Day 24 · 26/11 — Security: hardening review, scope and authorisation

Goal: frame a security request so it is legitimate, precise and checkable.

Theory 1/2: scope comes first

Security prompts must say what you are allowed to touch: your own systems, a lab, an engagement with written permission. It is the professional rule, and it also helps the model answer the right question. "How do I get into this server" is ambiguous; "review the hardening of my own server against this benchmark" is a job.

Theory 2/2: the edited review prompt

Context: my own Debian 13 server, internet-facing, admins log in
with keys only.
Task: review sshd_config against these requirements:
no root login; no password authentication; only the group
"admins" may log in; protocol defaults for ciphers.
<sshd_config>(output of sshd -T)</sshd_config>
Output: | requirement | directive and value found | met: yes/no |
and the exact lines to change. Remind me to keep a session open
while I test the change.

Practice (30 min)

1. On your VM, run sudo sshd -T and save the output.
2. Run the edited prompt; check each "met" against the output with grep.
3. Apply one change in a second session, test login in a third, keep the first open until it works.
4. Card prompts/security-ssh-review.md.

With your AI: "Quiz me on SSH hardening: ten questions, one at a time, on directives of sshd_config, what they do and their safe value, with a link to the man page section for each answer."

Recap (10 min)

Three lines: scope first, review against requirements, keep a session open. Then redo the exercises without notes.

Day 25 · 27/11 — Infrastructure as code: asking for a playbook

Goal: get an Ansible playbook that is idempotent and checkable before it touches anything.

Theory 1/2: the weak prompt

Write an Ansible playbook to set up a web server.

Diagnosis: which system, which server, which configuration, which version of Ansible? The model will often produce shell commands wrapped in tasks, which run every time and are not idempotent. A good IaC prompt names the modules to prefer and the check you will run.

Theory 2/2: the edited prompt

Write an Ansible playbook for Debian 13 hosts in group "web".
Task: install nginx, deploy templates/site.conf.j2 to
/etc/nginx/sites-available/site.conf, enable it, reload nginx on
change only.
Constraints: use fully qualified module names (ansible.builtin.*);
no shell or command module; a handler for the reload; the playbook
must report no change on a second run.
Output: the playbook, then the commands I should run to check it:
syntax check, check mode with diff, second run.

Practice (30 min)

1. Install Ansible on your machine; target your VM in an inventory file.
2. Get the playbook with the edited prompt. Run ansible-playbook --syntax-check, then --check --diff, then a real run, then a second run: it must report changed=0.
3. Card prompts/iac-ansible-playbook.md, with the four commands as checks.

With your AI: "Explain idempotence in Ansible with two tasks that do the same thing, one idempotent and one not, and ask me to say which is which and why before you answer."

Let an agent do it: now that you have checked a playbook by hand, an agent can write the next ones and run the syntax check and check mode against a lab inventory: "Write the playbook from prompts/iac-ansible-playbook.md for my lab inventory, run --syntax-check and --check --diff, and show me the diff; do not run without --check." You still read the diff and launch the real run.

Recap (10 min)

Three lines: modules over shell, the handler, the second run. Then redo the exercises without notes.

Day 26 · 28/11 — What never goes into a prompt

Goal: clean logs and configs before sending them to a model, by hand and with code.

Theory 1/2: the rule

A hosted model is a third party: what you paste leaves your organisation, may be kept in logs, and is subject to the provider's terms. Never paste passwords, keys, tokens, customer personal data, or your employer's internal names and addresses without permission. A local model keeps data on your machine, which is why this path uses one. Replace secrets with placeholders, addresses with documentation ranges, names with roles.

Theory 2/2: redact with code

By hand you will miss one. A small function catches the patterns you know; you still read the result.

function redact(line) {
}

function redact(line) {
  return line
    .replace(/\b(?:\d{1,3}\.){3}\d{1,3}\b/g, '[IP]')
    .replace(/password=\S+/g, 'password=[REDACTED]');
}

Practice (30 min)

1. Take the logs and configs you used in this module. List every kind of sensitive value they contain (addresses, hostnames, users, keys).
2. Write the same redaction as a sed command or a short script, add hostnames and usernames to it, and run it on your files.
3. Read the output line by line: what did it miss?
4. Add a "Redaction" section to your library's README with the script and its limits.

With your AI: (local model only) "Here is a redacted log [paste]. List anything that could still identify a person, a company or a system, and explain why. Do not reproduce the values themselves."

Recap (10 min)

Three lines: what never goes, local versus hosted, why code plus reading. Then redo the exercises without notes.

Day 27 · 29/11 — Routing alerts with a small model

Goal: build a classification prompt a small local model gets right, and measure it.

Theory 1/2: small model, narrow task

A small model is fast and cheap but needs a narrow task: a fixed list of labels, a definition of each, an "other" label for what fits none, a few examples, low temperature, structured output. Then you measure it on labelled cases, as on day 8, and you route "other" and low-confidence cases to a human.

Theory 2/2: the edited prompt

Classify the alert into exactly one team.
Teams: network (links, routing, DNS, firewall), systems (disk,
memory, services, OS), database (queries, replication, locks),
security (logins, malware, policy), other (none of these clearly).
<alert>{alert}</alert>
Answer as JSON: {"team": "...", "reason": "max 15 words"}
Examples:
"disk /var 95% full on web1" -> systems
"replication lag 300s on db2" -> database

Practice (30 min)

1. Write 20 short fake alerts with the team you expect, including four ambiguous ones.
2. Run the prompt at temperature 0 with a JSON schema; count right answers per team.
3. Change one thing (definitions, an example) and rerun. Keep the better version.
4. Card prompts/ops-alert-routing.md with the 20 cases and the score per version.

With your AI: "Here are my 20 labelled alerts and the model's answers [paste]. Build the confusion table team by team, then tell me which definition in my prompt is probably causing the most errors."

Recap (10 min)

Three lines: what a small model needs, why "other", how you measured. Then redo the exercises without notes.

Day 28 · 30/11 — Module 2 review: the operations prompt pack

Goal: deliver a tested set of operations prompts and redo the module's hardest exercises.

Theory 1/2: what the operations prompts share

All the prompts of this module had the same spine: the exact system and version, the real outputs fenced as data, a policy or criteria to compare against, an output you can check line by line, a way out ("not in these logs", [MISSING], other), and a check outside the model (grep, shellcheck, hadolint, check mode).

Theory 2/2: fix this prompt

You are a senior Linux expert. Fix my server, it's slow. Be thorough!

Practice (30 min)

1. Check that each card of the module has inputs, output, checks and at least two test cases.
2. Rerun all of them on your current model; update ## History.
3. Write jobs/operations.md: one paragraph per job of the module, with the prompt you would reuse first.
4. Module 2 deliverable: the operations prompt pack pushed to your forge, with its test cases and scores.

With your AI: "Here is the list of my operations prompts with their scores [paste]. Ask me five questions, one at a time, about the choices I made in them (why this check, why this output), as an interviewer for a junior sysadmin job would."

Recap (10 min)

Write the six parts of the operations spine from memory. Then redo the module's exercises you got wrong.