Chapter 43 — Industry or public-service practice
Lesson map
Lesson 43 published. Map, example, EX127.
flowchart TD
N0["Learning outcomes"]
N1["43.1 Placement"]
N2["43.2 Change reviews"]
N3["43.3 Shadowing on-call"]
N4["43.4 Working with developers"]
N5["43.5 Professional lessons"]
N6["43.6 Supervision"]
N7["Reflection log"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX127"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["43.1 Placement"]
N2["43.2 Change reviews"]
N3["43.3 Shadowing on-call"]
N4["43.4 Working with developers"]
N5["43.5 Professional lessons"]
N6["43.6 Supervision"]
N7["Reflection log"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX127"]
[Learning outcomes]
|
v
[43.1 Placement]
|
v
[43.2 Change reviews]
|
v
[43.3 Shadowing on-call]
|
v
[43.4 Working with developers]
|
v
[43.5 Professional lessons]
|
v
[43.6 Supervision]
|
v
[Reflection log]
|
v
[Worked example] --> [Exercise EX127]
Learning outcomes
You will (1) work within a real-style operations team; (2) apply course methods to live-style tasks under supervision; (3) reflect on professional practice.
43.1 Placement
Elena spends eight weeks embedded in Solent's platform team, joining on-call shadowing, change reviews and planning.
The placement uses the same platform the course has studied, but now from inside the team that runs it, with its deadlines, handovers and priorities competing for attention. Elena has a supervisor, Rosa, and a written agreement stating what she may do: read access to repositories and dashboards, permission to comment on reviews and draft documents, and no production changes of her own. Clear limits let her contribute safely from the first week.
43.2 Change reviews
She reviews 40 infrastructure pull requests, commenting on security-relevant settings. Twelve comments lead to changes; she learns to phrase comments as questions with references.
A comment such as 'why does this job need write access to every bucket? The least-privilege requirement suggests listing the two it uses' invites the author to explain or fix, whereas 'this is insecure' tends to start an argument. Twelve accepted changes out of forty reviews is a reasonable rate: many pull requests had no security issue, and some comments were answered with a good reason that Elena had not known, which she records as learning rather than defeat.
43.3 Shadowing on-call
Elena observes alert handling and drafts runbook improvements, approved by the team.
Watching real alerts shows where the runbooks assume knowledge the reader may not have, such as which dashboard holds the admission logs or how to find a pod's owner. Elena notes each pause by the on-call engineer and drafts a change for it. The team reviews her drafts like any other change, and approval comes from the engineers who will use them at night, which is the test that matters for a runbook.
43.4 Working with developers
A developer team asks for help moving a service to Restricted pod security. Elena pairs with them; the service is compliant in two days.
Most of the work turns out to be small: setting the container to run as a non-root user, removing a capability the service never used, and moving a writable directory to a mounted volume. Pairing means the developers make the changes themselves while Elena explains each rejection message, so the next service they move will need less help. Two days compares well with the weeks such moves took when teams worked alone from documentation.
43.5 Professional lessons
Security engineers succeed by making the secure path easy: templates, clear messages, help when stuck.
The placement shows this repeatedly. Developers follow controls more readily when the template already does the right thing, when a rejection message says how to fix the manifest, and when someone can pair with them on a hard case. Blocking without help produces exceptions and workarounds. Elena also learns that her review comments carry more weight when she has helped the same team before, because trust earned through useful help makes later disagreement easier.
43.6 Supervision
Rosa reviews Elena's work weekly; all production changes are made by team members.
Weekly reviews let Rosa catch misunderstandings early and decide what Elena can take on next. The rule that only team members change production protects the platform and Elena alike: a student making a mistake in production would harm users and her own placement. Her contributions reach production through reviewed pull requests merged by the team. Rosa signs off each week's log, which becomes part of the placement evidence later in the course.
Reflection log
Each week Elena writes a short reflection: what she did, what she learned and what she would do differently. Reading them back at the end shows a shift from focusing on controls to focusing on how teams experience them. Rosa uses the reflections to plan Elena's final weeks, giving her more pairing with developers. The log also supplies material for the evidence dossier later in the course, since each entry links to the reviews and runbooks she worked on.
Supervisor feedback
Rosa's final feedback praises Elena's review comments for offering fixes with references, and suggests she practise saying no to scope creep.
Worked example
In week six, Elena notices a pull request adding a cloud role with wildcard storage permissions for a new analytics job. Her review comment proposes the specific actions and buckets needed, with a link to the least-privilege requirement; the author updates the role before merge.
Synthetic case. Placement details are synthetic.
Errors and limits
Reviewers who only block changes lose influence; offer the fix.
Exercises
- EX127 — Review outcome. How many review comments led to changes? Rubric: 3 = 12 of 40 PRs commented; 2 = partial; 1 = vague; 0 = none.
- EX128 — Lesson. What is the main professional lesson? Rubric: 3 = make secure path easy; 2 = partial; 1 = vague; 0 = none.
- EX129 — Wildcard role. How was the wildcard role handled? Rubric: 3 = proposed specific actions and buckets; 2 = partial; 1 = vague; 0 = none.
Synthesis
Practice teaches how security works with teams, not around them.
Continue studying — chapter 43 of 50
← Chapter 42 (draft) · Course chapter index · Chapter 44 (draft) →