Chapter 49 — Engineering thesis
Lesson map
Lesson 49 published. Map, example, EX145.
flowchart TD
N0["Learning outcomes"]
N1["49.1 Problem"]
N2["49.2 Approach"]
N3["49.3 Evaluation"]
N4["49.4 Contributions"]
N5["49.6 Future work"]
N6["Writing process"]
N7["Abstract"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX145"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["49.1 Problem"]
N2["49.2 Approach"]
N3["49.3 Evaluation"]
N4["49.4 Contributions"]
N5["49.6 Future work"]
N6["Writing process"]
N7["Abstract"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX145"]
[Learning outcomes]
|
v
[49.1 Problem]
|
v
[49.2 Approach]
|
v
[49.3 Evaluation]
|
v
[49.4 Contributions]
|
v
[49.6 Future work]
|
v
[Writing process]
|
v
[Abstract]
|
v
[Worked example] --> [Exercise EX145]
Learning outcomes
You will (1) write the engineering thesis; (2) present problem, design, implementation, verification and evaluation; (3) discuss contributions and limits; (4) propose future work.
49.1 Problem
Configuration and credential weaknesses in a containerised energy-data platform, shown by the leaked key and missing network policies.
The thesis opens with the concrete incident rather than a general statement about cloud risk, because a reader can follow a real chain of events: a long-lived key copied out, and namespaces with no network policies to limit where it could be used. From that case Elena states the general problem: small platform teams run powerful shared infrastructure with weak defaults, and lack a practical method for turning security standards into controls they can check and sustain.
49.2 Approach
Requirements from risks and standards; layered architecture; implemented controls (workload identity, default-deny networking, Restricted pod security, signed images, guardrails, drift detection); secure namespace service.
The approach chapter explains the order of the work as well as its parts. Risks and standards produced requirements; requirements shaped the architecture; each control was then built to meet named requirements and verified against them. The namespace service comes last because it packages the earlier controls as defaults. Presenting the method this way lets another team reuse the sequence even if their tools differ from Solent's.
49.3 Evaluation
Coverage rose from 62% to 100% of production namespaces; long-lived workload keys from 23 to 0; time to fix risky configurations fell from 9 days to 4 hours; admission overhead about 20 ms median; trial objectives met.
Each figure in the list is given its source and sample size, following Dr Wagner's comment on the draft. The overhead figure comes from twenty synthetic deployments, the time-to-fix figures from six months either side of enforcement, and the trial results from a single run of each scenario. Stating these alongside the results lets a reader judge how much weight each can bear, and stops the strongest results from lending false certainty to the weakest.
49.4 Contributions
An engineering method combining standards, traceability and verification for small platform teams; the secure namespace service; measurement scripts reusable by others.
Elena claims contributions only where she has evidence of use. The method was followed through the whole project and is documented step by step. The namespace service runs in production, with the comparison against hand-made namespaces as evidence. The scripts are published with tests, so others can rerun them. She avoids claiming novelty for individual controls, since workload identity and default-deny policies are established practice; the contribution is combining and verifying them for a small team.
49.5 Limits
Single organisation, short observation, synthetic trial data, dependence on provider features.
The limits chapter connects each limit to the claim it affects. Results from Solent may not transfer to larger organisations or different regulators. Observation after rollout lasted months, not years. Trial scenarios used synthetic data and planned failures, which are kinder than real attacks. Several controls rely on the cloud provider's identity and storage features, which could change. Naming the affected claims helps readers decide how far to trust each result and where follow-up work should begin.
49.6 Future work
Extend the namespace service to cloud accounts; measure developer productivity effects; study multi-organisation adoption.
Each item follows from a limit or an unanswered question. Cloud account settings are today checked against their templates only afterwards, by the weekly drift report, much as namespaces were checked before the service, so creating accounts from verified templates could close similar gaps there. Developer productivity was measured only through ratings and rejection counts, which says little about time lost or saved. A study across several organisations would test whether the method transfers. Elena states what data each study would need, so the proposals can be acted on.
Writing process
Elena writes the thesis chapter by chapter alongside the work, reusing design notes, decision records and test reports rather than writing from memory at the end. Each chapter is reviewed by Dr Wagner within a week. This keeps the thesis accurate and reduces the final writing load. The final document is about 60 pages plus appendices containing the dossier summary, the requirement trace and the scripts. A short reading guide at the start tells practitioners which chapters to read if they only want the method or the results.
Abstract
The abstract states the problem, method, main results with figures and limits in 250 words.
Final check
Every figure is checked against its source file before submission.
Worked example
Dr Wagner's main comment on the draft is that the evaluation chapter lists results but not their uncertainty. Elena adds sample sizes and notes where figures come from single measurements.
Synthetic case. Results are synthetic.
Errors and limits
Engineering theses must show evidence, not only describe systems.
Exercises
- EX145 — Coverage result. How did coverage change? Rubric: 3 = 62% to 100%; 2 = partial; 1 = vague; 0 = none.
- EX146 — Contributions. List the contributions. Rubric: 3 = method, namespace service, scripts; 2 = two; 1 = one; 0 = none.
- EX147 — Draft comment. What did Dr Wagner ask to add? Rubric: 3 = uncertainty, sample sizes; 2 = partial; 1 = vague; 0 = none.
Synthesis
The thesis connects problem, design and evidence into one argument.
Continue studying — chapter 49 of 50
← Chapter 48 (draft) · Course chapter index · Chapter 50 (draft) →