Chapter 18 — Supervised technical project
Lesson map
Lesson 18 published. Map, example, EX069.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Choosing the project"]
N2["18.2 Delivering and evidencing"]
N3["18.3 Handover"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX069"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Choosing the project"]
N2["18.2 Delivering and evidencing"]
N3["18.3 Handover"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX069"]
[Learning outcomes]
|
v
[18.1 Choosing the project]
|
v
[18.2 Delivering and evidencing]
|
v
[18.3 Handover]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX069]
Learning outcomes
You will (1) deliver a scoped project improving one cryptographic service; (2) present evidence of before and after states; (3) hand over operation with documentation.
18.1 Choosing the project
For his final project Tomás chooses the depot Wi-Fi trust chain, because the RADIUS incident in chapter 13 showed it was fragile. His scope covers the RADIUS server certificate, the internal intermediate and the handhelds' trust store, with Priya as supervisor and the network manager as approver. His goals are measurable: no unplanned Wi-Fi outages from certificate changes, renewal of the RADIUS certificate at least thirty days before expiry, and a tested runbook. He leaves the internal root redesign out of scope because it needs an engineer's authority, and records that as future work.
18.2 Delivering and evidencing
Tomás adds the RADIUS certificate and intermediate to the expiry report, pushes the current intermediate to all handhelds through device management before the next renewal, and writes a renewal runbook that a colleague tests. Before evidence includes the incident timeline and the missing intermediate; after evidence includes the updated trust store on a sample of handhelds, a renewal rehearsal in the lab and the new monitoring alert firing in a test. Each claim in his report links to evidence with commands, timestamps and digests, following the habits from chapter 5.
18.3 Handover
A project is not finished until someone else can run it. Tomás hands over to the night-shift lead with a walkthrough of the runbook, the alert and the dependency map. He lists open risks: the internal root key is still on a general-purpose server, and two old handhelds cannot receive updates. He presents the project to the operations team in ten minutes, focusing on what changed, how it was verified and what remains. Priya's assessment notes that the strongest part was not technical cleverness but careful scoping, evidence and honest reporting of limits.
Worked example
Tomás delivers the Wi-Fi trust chain project with before and after evidence, a tested runbook and a handover listing two open risks.
Synthetic case. The project, devices and assessment are synthetic.
Errors and limits
Sample checks may miss devices; full coverage needs management reports. Out-of-scope risks remain real until someone owns them.
Exercises
- EX069 — Out of scope. What did Tomás leave out of scope and why? Rubric: 3 = the internal root redesign, because it needs engineer authority;; 2 = names item;; 1 = vague;; 0 = none.
- EX070 — Measurable goals. Give two of Tomás's measurable goals. Rubric: 3 = no unplanned outages from cert changes, renewal 30 days early, tested runbook (two);; 2 = one;; 1 = vague goal;; 0 = none.
- EX071 — After evidence. Name two pieces of after evidence. Rubric: 3 = updated trust store sample, lab renewal rehearsal, alert test firing (two);; 2 = one;; 1 = vague;; 0 = none.
- EX072 — Open risks. Which open risks did the handover list? Rubric: 3 = root key on general-purpose server, two handhelds cannot update;; 2 = one;; 1 = vague;; 0 = none.
Synthesis
A supervised project proves technical competence through scope, evidence, handover and honest limits rather than through clever code.
Continue studying — chapter 18 of 18
← Chapter 17 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →