Chapter 46 — Engineering capstone II
Lesson map
Lesson 46 published. Map, example, EX136.
flowchart TD
N0["Learning outcomes"]
N1["46.1 Implementation"]
N2["46.2 Verification"]
N3["46.3 Staging trial"]
N4["46.4 Production"]
N5["46.5 Developer feedback"]
N6["46.6 Handover"]
N7["46.7 Criteria check"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX136"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["46.1 Implementation"]
N2["46.2 Verification"]
N3["46.3 Staging trial"]
N4["46.4 Production"]
N5["46.5 Developer feedback"]
N6["46.6 Handover"]
N7["46.7 Criteria check"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX136"]
[Learning outcomes]
|
v
[46.1 Implementation]
|
v
[46.2 Verification]
|
v
[46.3 Staging trial]
|
v
[46.4 Production]
|
v
[46.5 Developer feedback]
|
v
[46.6 Handover]
|
v
[46.7 Criteria check]
|
v
[Worked example] --> [Exercise EX136]
Learning outcomes
You will (1) implement and verify the secure namespace service; (2) run it in staging and production; (3) measure against success criteria; (4) document and hand over.
46.1 Implementation
Templates are written as versioned manifests; the request workflow is a reviewed pull request to a namespaces repository, processed by the GitOps controller with a narrowly scoped identity. A canary namespace verifies each template version.
Using a pull request as the request form means every namespace has a reviewer, a timestamp and a record of who asked for it, with no new tool to build or secure. The controller's identity can create namespaces only with the approved label prefix, as the design review required. Templates are referenced by version, so a namespace always shows which version created it, and changing a template never alters existing namespaces silently.
46.2 Verification
Each new namespace automatically runs the chapter 30 tests: privileged pod rejected, unsigned image rejected, web-to-db connection blocked, workload identity limited, quotas applied, alerts flowing. Results are attached to the request.
Running the tests at creation turns the earlier one-off verification into a check every namespace receives. Attaching the results to the request gives the developer and any later auditor the same proof, dated and tied to a template version. If any test fails, the namespace is marked not ready and the requesting team is told why, so nobody deploys into a namespace that is only partly protected while the fault is fixed.
46.3 Staging trial
Twelve namespaces are created in staging over two weeks; all pass verification. One template error, a missing DNS egress rule, is caught by the canary before any real namespace uses it.
Without that egress rule, default-deny would have blocked name lookups, so services in the new namespace could not have found the database or the message queue. The failure would have looked like an application bug rather than a template error, and would have recurred in every namespace. Catching it in the canary confirms the design review's concern about errors spreading and shows that the canary step earns its place in the workflow.
46.4 Production
Eight new production namespaces are created in the following month, all passing at creation. Median creation time is 6 minutes.
Six minutes is well under the ten-minute criterion, and most of that time is the controller's reconciliation cycle and the verification tests rather than any manual step. Elena also records the slowest creation, which waited for a reviewer to approve the pull request. Approval time is outside the service's control, so she reports it separately, keeping the creation measure honest about what the service itself does.
46.5 Developer feedback
Developers rate the process 4.4 of 5; the main request is clearer documentation on quota options.
The rating comes from a short question sent after each delivery, and comments are read alongside the score. The quota request echoes the design review, which had already turned fixed quotas into size options; the options exist, but developers cannot tell which suits their workload. That is a documentation gap rather than a design flaw, so the fix is examples of typical workloads in the user guide, not new options.
46.6 Handover
The platform team takes ownership with runbooks, template tests and a maintenance schedule.
Handover is tested, not assumed. The platform engineer who will own the service makes a template change on their own, using only the documents, and runs it through the canary and the tests. Elena watches without helping and notes where they hesitate. The maintenance schedule sets when templates are reviewed against new Kubernetes versions and policy changes, so the defaults do not slowly fall behind the controls they were built to apply.
46.7 Criteria check
All three success criteria are met.
Every production namespace passed verification at creation, median creation took six minutes against a ten-minute limit, and developers rated the process 4.4 against a target of 4. Elena reports each of the three figures with its measure and sample size: eight production namespaces and the ratings returned for them. She also notes that early results may flatter the service, since willing teams adopted it first, and that the maintenance schedule exists to keep those results from fading. Rosa countersigns the check.
Documentation
The service has a short user guide: how to request a namespace, what is included, how to choose quota sizes and how to request a variation. Following developer feedback, quota options are explained with examples of typical workloads. The platform team's guide covers template changes, canary checks and how to roll back a template version.
Ownership
The platform team now owns the service.
Worked example
Rosa compares the first eight production namespaces with the previous eight created by hand: the hand-made ones averaged 2.5 missing controls at creation, the new ones none. The comparison goes into the evidence dossier as the clearest result of the capstone.
Synthetic case. Namespaces and figures are synthetic.
Errors and limits
Early success can fade if templates are not maintained; schedule reviews.
Exercises
- EX136 — Canary catch. What did the canary catch? Rubric: 3 = missing DNS egress rule; 2 = partial; 1 = vague; 0 = none.
- EX137 — Results. What were creation time and rating? Rubric: 3 = 6 minutes; 4.4/5; 2 = partial; 1 = vague; 0 = none.
- EX138 — Comparison. How did new namespaces compare with hand-made ones? Rubric: 3 = 0 vs 2.5 missing controls; 2 = partial; 1 = vague; 0 = none.
Synthesis
Secure defaults, verified at creation, prevent gaps rather than finding them later.
Continue studying — chapter 46 of 50
← Chapter 45 (draft) · Course chapter index · Chapter 47 (draft) →