Chapter 8 — Scripting for checks
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Why script"]
N2["8.2 Read-only first"]
N3["8.3 Clear output"]
N4["8.4 Testing scripts"]
N5["Scheduling checks"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Why script"]
N2["8.2 Read-only first"]
N3["8.3 Clear output"]
N4["8.4 Testing scripts"]
N5["Scheduling checks"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Why script]
|
v
[8.2 Read-only first]
|
v
[8.3 Clear output]
|
v
[8.4 Testing scripts]
|
v
[Scheduling checks]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) write small read-only scripts; (2) parse simple data; (3) produce clear reports.
8.1 Why script
Many checks repeat: listing accounts, comparing settings, checking backup times. A short script makes them consistent and fast. Python's standard library is enough for most: csv to read exports, datetime for dates, json for configuration.
For Tomás the alternative is clicking through consoles and copying numbers by hand, which is slow and gives slightly different answers each time. A script reading the same export the same way gives the same answer for the same data, which is what makes a before-and-after comparison fair at the end of the placement.
8.2 Read-only first
Tomás's scripts only read exported data and print results. They never change systems. This makes them safe to run during the placement and easy to review: Dev can read every line.
The scripts read files that Dev exports from the directory, the management service and the backup software, so Tomás never needs credentials for those systems. Because nothing is written back, a mistake in a script can only produce a wrong number, which a test file can catch, rather than a changed account or a broken server. That read-only limit is also exactly what the placement agreement allows him to do.
8.3 Clear output
A good check prints a short summary and the specific items that need attention. A wall of text is ignored. Each script ends with one line such as "late 2 of 6" so the result is clear at a glance.
The summary line puts the count before its denominator, so 'stale 4 of 7' reads correctly even to someone who has never seen the script. The items needing attention are listed under it by name, sorted so the most urgent come first. Dev can paste that line straight into the weekly review notes without rewriting it.
8.4 Testing scripts
Tomás tests each script with small synthetic inputs where he knows the right answer, including edge cases such as an empty file or a missing date. A script that silently skips bad rows can hide problems.
For the stale-account script he builds a file with one account used yesterday, one used exactly ninety days ago and one used ninety-one days ago, so he can confirm the boundary is handled as intended. A row with no date should be reported as an error, not treated as recent or skipped, because an account that has never signed in still needs a decision.
Scheduling checks
A script is most useful when it runs on a schedule rather than when someone remembers. Dev schedules the account and backup checks weekly with the system scheduler, writing each run's output to a dated file. The dated history shows whether things are improving, and lets Tomás compare one week with another or show an auditor that the checks really ran. Each script starts with a short header explaining what it reads, what it prints and who owns it, so another technician can keep it running after the placement. If a scheduled run fails to produce its file, that absence is itself flagged in the weekly review, so a broken check cannot pass silently.
Worked example
Tomás writes a twelve-line script reading a CSV of accounts, computing days since last sign-in and printing the stale ones; with a test file of three rows he confirms it flags exactly the one he expects.
Synthetic case. Data are synthetic.
Errors and limits
Scripts that change systems need much more care, review and approval; keep checks read-only.
Exercises
- EX022 — Library choice. Which standard library modules help read an account export with dates? Rubric: 3 = csv and datetime with roles;; 2 = names one;; 1 = vague;; 0 = none.
- EX023 — Output design. Write the final summary line for a script that found 3 of 50 laptops unencrypted. Rubric: 3 = clear count and denominator;; 2 = count only;; 1 = vague;; 0 = none.
- EX024 — Edge cases. Name two edge cases to test. Rubric: 3 = empty file and missing or malformed date;; 2 = one;; 1 = vague;; 0 = none.
Synthesis
Small read-only scripts turn repetitive checks into reliable routines.
Continue studying — chapter 08 of 30
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →