Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Capstone choice"]
N2["44.2 Why"]
N3["44.3 Scope"]
N4["44.4 Success criteria"]
N5["44.5 Risks"]
N6["44.6 Mitigations"]
N7["44.7 Plan"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX130"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["44.1 Capstone choice"]
N2["44.2 Why"]
N3["44.3 Scope"]
N4["44.4 Success criteria"]
N5["44.5 Risks"]
N6["44.6 Mitigations"]
N7["44.7 Plan"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Capstone choice]
|
v
[44.2 Why]
|
v
[44.3 Scope]
|
v
[44.4 Success criteria]
|
v
[44.5 Risks]
|
v
[44.6 Mitigations]
|
v
[44.7 Plan]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define the capstone project scope; (2) plan design, implementation and verification; (3) identify risks; (4) agree success criteria.
44.1 Capstone choice
Elena's capstone is an automated "secure namespace" service: a request creates a namespace with default-deny network policies, Restricted pod security, workload identity binding, resource quotas and monitoring, all from reviewed templates.
The project brings together controls built separately earlier in the course and makes them the default for every new service. A developer submits a short request naming the team, the service and the size needed; the service then creates the namespace and applies each template in a fixed order, so no namespace exists for long without its policies. The result is checked automatically before the requesting team is told it is ready.
44.2 Why
The applied study showed new services generate most rejections. A secure-by-default namespace removes that friction and closes gaps like the opening case's missing policies.
The worked example of the research study found that four in ten rejections came in a service's first week, and a template already halved them. A full namespace service extends that idea from the workload's manifest to everything around it. It also tackles the opening case directly, where a namespace existed without network policies: if every namespace is created with default-deny in place, that gap cannot appear through forgetfulness.
44.3 Scope
Templates, a small request workflow, verification tests and documentation. Out of scope: changes to existing namespaces.
Keeping existing namespaces out of scope is a deliberate trade. Converting them would mean negotiating with every team and handling many special cases, which could not fit into eight weeks and would put the core service at risk. Existing namespaces are already covered by admission controls and drift detection, so leaving them alone does not open a gap. The out-of-scope list is written into the plan, so later requests can be pointed to it.
44.4 Success criteria
New namespaces pass all chapter 30 verification tests at creation; creation takes under 10 minutes; developers rate the process at least 4 of 5.
Each criterion maps to a way of checking it. The verification tests run automatically after creation and either pass or fail. Creation time is read from the workflow's own logs for every request during the trial. The developer rating comes from a short question sent after each namespace is delivered. Agreeing the thresholds with Rosa and Dr Wagner before building stops them from being lowered later to match whatever the service achieves.
44.5 Risks
Templates could become too rigid; the workflow could become a bottleneck; template errors would spread to every new namespace.
Rigid templates would push teams to request exceptions or work around the service, recreating the problem it was built to solve. A slow workflow would make teams wait and resent the platform. The third risk is the most serious, because a mistake in one template is copied into every namespace created afterwards, turning a single error into a widespread weakness. Elena rates each risk by likelihood and impact and names an owner for watching it.
44.6 Mitigations
Template tests in the pipeline; staged release; a documented way to request variations.
Each mitigation targets one risk. Template tests and the canary namespace catch errors before they spread. A staged release starts with a few willing teams, so a slow or awkward workflow is noticed while few people depend on it. A documented variation request, reviewed by the platform team, gives teams with genuine special needs a legitimate route, which removes the temptation to bypass the service and keeps the variations visible.
44.7 Plan
Eight weeks: design (2), implementation (3), verification (2), documentation and handover (1).
Design comes first so the reviewers in the independent design review have something concrete to examine before code is written. Implementation takes the largest share because the workflow, templates and tests all need building. The two verification weeks run the full suite against new namespaces and include time to fix and retest. The final week is for documentation and the handover to the platform engineer who will own the service. Rosa reviews progress against the plan weekly.
Stakeholder check
Before starting, Elena shows the plan to three developer teams who will use the service. They ask for a way to request larger quotas and for the service to create a starter alert dashboard. The quota request becomes part of scope; the dashboard is noted as a later improvement to keep the eight-week plan realistic. Elena also agrees with Rosa which platform engineer will own the service after handover, so design choices suit the people who will maintain it.
Timeline buffer
The second verification week doubles as the buffer: it is planned for retesting fixes, so problems found in the first week do not push the handover back.
Worked example
Dr Wagner asks how template errors will be caught before they spread. Elena adds a canary step: each template change first creates a test namespace and runs the verification suite before any real namespace uses it.
Synthetic case. Capstone details are synthetic.
Errors and limits
Capstones grow; protect scope with a written out-of-scope list.
Exercises
- EX130 — Capstone. What is the capstone? Rubric: 3 = automated secure namespace service; 2 = partial; 1 = vague; 0 = none.
- EX131 — Criteria. State the success criteria. Rubric: 3 = pass tests, under 10 min, rating ≥4; 2 = two; 1 = one; 0 = none.
- EX132 — Canary. What did the canary step add? Rubric: 3 = test namespace verification before use; 2 = partial; 1 = vague; 0 = none.
Synthesis
A clear scope and criteria set up the capstone for success.
Continue studying — chapter 44 of 50
← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →