Chapter 36 — Field or community practice
Lesson map
Lesson 36 published. Map, example, EX106.
flowchart TD
N0["Learning outcomes"]
N1["36.1 The placement"]
N2["36.2 Adapting methods"]
N3["36.3 Findings"]
N4["36.4 Fixes"]
N5["36.5 Communication"]
N6["36.6 Reflection"]
N7["Leaving it sustainable"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX106"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 The placement"]
N2["36.2 Adapting methods"]
N3["36.3 Findings"]
N4["36.4 Fixes"]
N5["36.5 Communication"]
N6["36.6 Reflection"]
N7["Leaving it sustainable"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX106"]
[Learning outcomes]
|
v
[36.1 The placement]
|
v
[36.2 Adapting methods]
|
v
[36.3 Findings]
|
v
[36.4 Fixes]
|
v
[36.5 Communication]
|
v
[36.6 Reflection]
|
v
[Leaving it sustainable]
|
v
[Worked example] --> [Exercise EX106]
Learning outcomes
You will (1) apply cloud security skills in a community setting; (2) adapt methods for small organisations; (3) communicate with non-specialists; (4) reflect on practice.
36.1 The placement
Samuel volunteers for four weeks with a fictional local charity, Harbourside Youth Trust, which runs a small booking app on a cloud platform with one part-time IT volunteer.
The app lets families book places at youth activities and stores names, contact details and some event photos. One part-time volunteer manages everything, alongside other duties. Samuel's role is to help, not to take over, so every change is made by the volunteer while he explains what it does and why. Westmere arranged it.
36.2 Adapting methods
The full university checklist is too much. Samuel picks five checks that matter most for a small account: owner MFA, no owner keys, storage public access blocked, audit logging on, and budget alerts.
Each of the five checks addresses a risk the charity could realistically face and fix: a stolen owner password, a leaked key, public photos of children, no record of changes and an unexpected bill. Other checks from the university list, such as pod security, do not apply because the charity runs no containers.
36.3 Findings
Owner MFA was off; a storage bucket of event photos was public; logging was off. Keys and budgets were fine.
Three of five checks failed, the same pattern as the university's early accounts before guardrails. The public bucket held photos meant for the website, so making it private needed care to avoid breaking the site. Samuel recorded each finding with a short description of what it meant for the charity. He also noted what was working, the keys and budget alerts, so the trustees saw a balanced picture. Each finding had a single recommended fix that the volunteer could make in the console in a few minutes.
36.4 Fixes
With the trustees' written permission, the volunteer turns on MFA, blocks public access after moving the intended public photos to the website, and enables logging. Samuel guides; the volunteer makes the changes.
Written permission from the trustees confirms that the changes were authorised by the people responsible for the charity. Moving the intended public photos to the website first meant blocking the bucket did not break anything families relied on. Having the volunteer make each change ensures they understand the settings and could reverse them if needed.
36.5 Communication
Samuel explains risks in terms of children's photos and the charity's reputation, not technical jargon.
Trustees understood immediately when Samuel explained that anyone could have downloaded photos of children at the charity's events. That explanation produced faster agreement than any discussion of storage permissions. He also explained what had not happened: there was no sign that anyone had downloaded them, though without logging nobody could be sure. He avoided blame too: the settings had been left at defaults by a volunteer doing their best with no training. The trustees thanked the volunteer for agreeing to fix them, which made follow-up work easier and kept the volunteer engaged.
36.6 Reflection
Small organisations need short, prioritised advice and someone to help them act on it.
Samuel's university checklist would have overwhelmed the volunteer; five checks were enough to fix the most serious problems in an afternoon. He also learned that his main contribution was confidence: once the volunteer saw the changes were simple and reversible, they made them without hesitation. Samuel's placement report records which advice was followed and which was not, and why. All five checks were adopted; a suggestion to set up separate accounts for testing was declined because the charity had no capacity to manage two accounts, which Samuel accepted as a reasonable decision for its size.
Leaving it sustainable
Before leaving, Samuel writes a one-page guide for the charity volunteer: the five checks, how to do each in the console, and how often. He also sets a calendar reminder for the trustees to review who has owner access every six months. The guide uses screenshots described in words so it survives interface changes. The volunteer tries every step while Samuel watches, so the guide is proven to work for the person who will use it.
Worked example
Three months later the volunteer emails that a budget alert caught an accidentally left-running test machine, saving a month's costs. The charity asks Westmere for a yearly check, which becomes a student volunteering scheme.
Synthetic case. The charity and events are synthetic.
Errors and limits
Advice must match the organisation's capacity or it will not be followed.
Exercises
- EX106 — Five checks. List the five checks. Rubric: 3 = owner MFA, no owner keys, public access blocked, logging, budget alerts; 2 = four; 1 = two; 0 = none.
- EX107 — Findings. What did Samuel find? Rubric: 3 = MFA off, public bucket, logging off; 2 = two; 1 = one; 0 = none.
- EX108 — Who changes. Who made the changes? Rubric: 3 = the volunteer, with permission; 2 = partial; 1 = vague; 0 = none.
Synthesis
Adapt methods to the organisation's size and capacity.
Continue studying — chapter 36 of 40
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →