Chapter 50 — Final defense
Lesson map
Lesson 50 published. Map, example, EX148.
flowchart TD
N0["Learning outcomes"]
N1["50.1 The panel"]
N2["50.2 Technical questions"]
N3["50.3 Professional questions"]
N4["50.4 Reflection"]
N5["50.5 Outcome"]
N6["50.6 Next steps"]
N7["Mentoring"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX148"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["50.1 The panel"]
N2["50.2 Technical questions"]
N3["50.3 Professional questions"]
N4["50.4 Reflection"]
N5["50.5 Outcome"]
N6["50.6 Next steps"]
N7["Mentoring"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX148"]
[Learning outcomes]
|
v
[50.1 The panel]
|
v
[50.2 Technical questions]
|
v
[50.3 Professional questions]
|
v
[50.4 Reflection]
|
v
[50.5 Outcome]
|
v
[50.6 Next steps]
|
v
[Mentoring]
|
v
[Worked example] --> [Exercise EX148]
Learning outcomes
You will (1) defend the engineering thesis before a panel; (2) answer technical and professional questions; (3) reflect on learning; (4) plan next steps.
50.1 The panel
Dr Wagner, Rosa Delgado and an external examiner from industry.
The three panellists bring different views. Dr Wagner has supervised the thesis and knows its argument in detail. Rosa knows the platform and can judge whether the work holds up in daily operation. The external examiner has seen neither, and judges whether the thesis would convince someone outside the project, which is closest to how a future employer or regulator would read it. Elena prepares for each by rereading the parts each one is likely to question.
50.2 Technical questions
Why fail closed? Because production safety outweighs deployment convenience, backed by a reliable engine. Why namespaces rather than clusters per service? The scored decision record. How do controls handle a provider outage? Rebuild and degradation plans.
Each answer points to evidence rather than opinion. For fail-closed, Elena cites the engine failure trial, where recovery took six minutes and running workloads were unaffected. For architecture, she shows the decision record's scores and its revisit triggers. For a provider outage, she describes rebuilding the platform from the declared state in version control and running degraded until the provider recovers, and admits that a full regional outage has not been tested.
50.3 Professional questions
How did you handle developer resistance? Through exceptions with expiry, clear messages and making the secure path easy. What would you do differently? Involve developers earlier in requirements.
Elena's answer on resistance is concrete: the developer survey, the change to rejection messages and the two-day exception service level. On what she would change, she explains that developers joined after the first requirements were written, and several early complaints, such as exception delays, could have been designed out from the start. The panel values the admission because it shows she learned from the project rather than defending every choice.
50.4 Reflection
Elena writes that the most valuable skill was turning standards into testable requirements and then into evidence.
She gives an example: a standard's recommendation to group containers by sensitivity became a requirement about separate clusters, then a decision record, then configuration queries and tests that showed the separation was in place. Each step made the idea more checkable. She also reflects that the hardest work was not technical but persuading teams, which took listening, clear messages and quick help more than policy writing.
50.5 Outcome
The thesis passes; Solent offers Elena a platform security engineer role.
The panel's decision rests on the evidence that the work was done well and checked honestly: traced requirements, verified controls, measured results and openly stated limits. The job offer shows the work was useful to Solent as well as academically sound. Elena's role continues the project's direction, which also means the systems she built will have their author nearby for a while, though the handover and documentation were designed so the platform does not depend on her.
50.6 Next steps
Lead the extension of secure defaults to cloud accounts, mentor next year's student.
Extending secure defaults to cloud accounts follows the future work in the thesis and uses the same pattern: reviewed templates, a narrowly scoped automation identity, verification at creation and a canary. Mentoring passes on both the methods and the habits behind them, such as writing requirements as tests and including failures in evidence. Elena plans to run next year's failure and recovery trial with new scenarios from the threat register, so the controls keep being tested as the platform changes.
Mentoring
As part of her new role, Elena prepares a short guide for next year's student: how to find data, which stakeholders to meet first and how to use synthetic data for labs. The guide shows the project's methods becoming part of Solent's practice, the outcome Dr Wagner hoped for. She also hands over her lab scripts with tests, so next year's student starts from working tools rather than from scratch.
Closing reflection
Elena closes by thanking the platform team, noting that every control in the thesis exists because they run it daily.
Worked example
The external examiner asks whether the approach would work at a much larger company. Elena answers that the method would, but the tooling would need more automation and the exception process would need delegation; she cites the Borg and Kubernetes experience (Burns et al., 2016) of declarative, reconciled configuration at scale as supporting the core idea.
Synthetic case. Panel and outcomes are synthetic.
Errors and limits
Answer within the evidence; say where it runs out.
Exercises
- EX148 — Fail closed defence. How did Elena justify fail closed? Rubric: 3 = safety over convenience, reliable engine; 2 = partial; 1 = vague; 0 = none.
- EX149 — Do differently. What would she do differently? Rubric: 3 = involve developers earlier; 2 = partial; 1 = vague; 0 = none.
- EX150 — Scale answer. How did she answer the scale question? Rubric: 3 = method scales; more automation, delegation; 2 = partial; 1 = vague; 0 = none.
Synthesis
Defend with evidence and know where it ends.
Continue studying — chapter 50 of 50
← Chapter 49 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →