Chapter 11 — Applied project
Lesson map
Lesson 11 published. Map, example, EX051.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Project"]
N2["11.2 Scope"]
N3["11.3 Method"]
N4["11.4 Evaluation"]
N5["11.5 Outcome"]
N6["11.6 Presentation"]
N7["Project timeline"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX051"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Project"]
N2["11.2 Scope"]
N3["11.3 Method"]
N4["11.4 Evaluation"]
N5["11.5 Outcome"]
N6["11.6 Presentation"]
N7["Project timeline"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX051"]
[Learning outcomes]
|
v
[11.1 Project]
|
v
[11.2 Scope]
|
v
[11.3 Method]
|
v
[11.4 Evaluation]
|
v
[11.5 Outcome]
|
v
[11.6 Presentation]
|
v
[Project timeline]
|
v
[Worked example] --> [Exercise EX051]
Learning outcomes
You will (1) plan and complete a substantial project; (2) define scope, method and evaluation; (3) present outcomes.
11.1 Project
Inês's final project: a reusable cluster security baseline for Beacon, with central labels, policy engine rules, upgrade checklist and assurance tests. Making the baseline reusable means Beacon can apply it to any new cluster, rather than repeating the analysis each time. It brings together the central labels and Restricted default, the P2 rules with the host path addition, the upgrade checklist step and the quarterly behaviour tests. Prof. Rao approves the project scope as the course's final assessment. The baseline is stored in the central repository as one versioned package.
11.2 Scope
Four clusters; excludes provider control plane and developer laptops. Limiting the scope to four clusters keeps the project achievable within the course and covers every cluster in the audit finding. The provider's control plane is excluded because the provider secures it, while developer laptops are a separate risk with different controls. Inês records both exclusions with their reasons in the project plan, so examiners can see the boundaries were chosen deliberately. Analytics stays in scope despite holding less customer data, because arbitrary code runs there.
11.3 Method
Build in staging, evaluate on the corpus, roll out by cluster in audit, warn, enforce order. Building in staging first means problems are found before production is affected. Evaluating on the 200-manifest corpus tests the rules before any deployment can be blocked. Rolling out cluster by cluster through audit, warn and enforce gives each team time to fix workloads and lets the working group learn from early clusters before later ones. Inês records each cluster's dates in audit, warn and enforce mode, with any problems found. Claims-prod goes last because its legacy batch jobs need the time-limited exception before enforcement begins.
11.4 Evaluation
Success means P2-level recall on the corpus, all four clusters enforced, and quarterly assurance at least 90%. Each of the three criteria tests a different part of the baseline. Recall on the corpus checks the rules, enforcement on all four clusters checks the rollout, and assurance of at least 90% checks that controls keep working over time. The criteria were set before rollout, so they could not be adjusted to match results. Inês reports each criterion against the evidence that shows whether it was met. Prof. Rao approved the criteria with the scope, so the examiners can check them against the original plan.
11.5 Outcome
All criteria met by Q3; four exceptions remain with expiry dates. The evidence comes from the corpus evaluation, the cluster configuration and the Q3 behaviour tests, repeated by internal audit on a different sample. The four remaining exceptions are recorded in the register with owners, compensating controls and expiry dates, and they are reported to the risk committee each month. Inês's results table lists which criterion each piece of evidence supports, so examiners can check them one by one. Internal audit's repeat of the Q3 tests on a different sample supports the assurance criterion, and the remaining exceptions include the claims batch jobs awaiting their rewrite.
11.6 Presentation
She presents to Fenwick examiners and Beacon's risk committee, with limits stated. The examiners assess the method and evidence, while the risk committee decides whether the baseline is ready to become Beacon's standard. Stating limits, such as the small assurance sample and estimates behind the cost comparison, lets both audiences judge the results fairly. An examiner asked what would happen if Beacon moved to a second provider, and Inês explained which parts of the baseline would need re-checking. The risk committee's questions focus on the remaining exceptions and when each will close.
Project timeline
The project ran over three quarters. In the first, Inês built the baseline in staging and assembled the evaluation corpus. In the second, she ran the evaluation, chose P2 and rolled out to analytics and quotes, the clusters with fewer legacy workloads. In the third, she rolled out to claims and shared, handled the batch and vendor exceptions, and ran the independent check with internal audit.
Each phase ended with a short review recording what went well, what did not and what would change. The biggest lesson was that the rollout order mattered: starting with simpler clusters built confidence and produced worked examples that helped the claims team prepare.
Examiner feedback
The examiners praise the clear success criteria and the honest limits section. They suggest that a future version could test the baseline on a cluster built from scratch, to confirm the documentation is enough for a new team without Inês's help. Beacon's platform team later does this for a new pricing cluster and records two gaps in the guidance, which are fixed.
Worked example
An examiner asks what would happen if Beacon moved to a second cloud provider. Inês explains that the baseline relies on Kubernetes features, not provider features, but the shared responsibility split would need to be re-checked.
Synthetic case. Project details are synthetic.
Errors and limits
Define success before starting.
Exercises
- EX051 — Deliverables. What did the baseline include? Rubric: 3 = labels, engine rules, checklist, tests; 2 = two; 1 = one; 0 = none.
- EX052 — Exclusions. What was out of scope? Rubric: 3 = control plane, laptops; 2 = partial; 1 = vague; 0 = none.
- EX053 — Success. What were success criteria? Rubric: 3 = recall, all enforced, ≥90% assurance; 2 = two; 1 = one; 0 = none.
- EX054 — Outcome. What remained at the end? Rubric: 3 = two exceptions with expiry; 2 = partial; 1 = vague; 0 = none.
- EX055 — Second provider. What changes with a second provider? Rubric: 3 = re-check shared responsibility; 2 = partial; 1 = vague; 0 = none.
Synthesis
Scope, evaluate and present honestly.
Continue studying — chapter 11 of 12
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →