Facilitator only · Week 8

Running the two hands-on days

Week 8 is the one week the interns work in a real cloud: each builds their own use case on AWS and on Google Cloud, in their own free accounts. The deck, slides 1 to 16, is read ahead before Tuesday and is not presented; Day 1 opens with a ten minute recap. The plan each intern makes in the Use Case Builder decides what they build, and so what they have to delete.

This is a summary. The full guide, with every price and limit and a link to the provider page it was read from, is WEEK8-HANDSON.md in the lab's docs folder, checked on 24 and 25 September 2026.

The one rule

Personal trial accounts, never Jahez

Each intern uses their own free account, opened with their own email. Nothing is created in a Jahez organization, billing account or domain.
No Jahez data goes into these accounts: not an export, not a screenshot of a real record, not an internal hostname, and not a copy of this lab, which carries the Jahez name.
Addresses come from the provider (a cloudfront.net or web.app name, a load balancer's IP address), or from a domain the intern already owns personally. Nobody touches a Jahez zone.
Ask on Day 1 who has no card. Firebase Spark needs none, and nobody should be pushed into using a parent's card to take part.

Day 1 · Tuesday 29 September · 120 minutes

Safe accounts, a plan, and the static front end

Time	Min	Block
0:00-0:10	10	Kickoff: a recap of the deck, and each intern states their use case in one sentence.
0:10-0:25	15	Account safety check: MFA on the owner login, a budget alert on both clouds with credits excluded, personal accounts only. Re-check the budgets set up before Sunday.
0:25-0:40	15	Console tour on both clouds: regions, account or project, the billing page, IAM.
0:40-0:55	15	Plan the use case in the Use Case Builder: requirements, architecture, AWS against Google Cloud.
0:55-1:40	45	Build A: the static front end on both clouds, S3 behind CloudFront on AWS, Firebase Hosting or Cloud Storage on Google Cloud.
1:40-1:50	10	Access review: least privilege, no public bucket except the one holding only the public site, SSH closed.
1:50-2:00	10	Show and tell, then stop or delete anything that bills by the hour before leaving.

Overnight: nothing that bills by the hour or by the second stays running (Cloud SQL, RDS, load balancers, virtual machines, Beanstalk environments). Static hosting may stay.

Day 2 · Wednesday 30 September · 120 minutes

The dynamic part, a demo each, and a clean teardown

Time	Min	Block
0:00-0:10	10	Safety check: budgets, and anything left running overnight.
0:10-0:55	45	Build B: the dynamic part of the use case, as the intern's plan drew it. A database only if the use case needs one.
0:55-1:15	20	Build C: HTTPS and a custom domain (optional), monitoring and logs, an access control review.
1:15-1:35	20	Present: each intern about five minutes of demo and one minute of feedback.
1:35-2:00	25	Teardown, with the checklist below.

Before anything is built

The safety checks

Multi-factor authentication on the account before the first resource.
A budget alert at a small figure, for example 5 dollars, with credits excluded. Both clouds count credits by default, so on a trial the credit hides the spend and the alert never fires. AWS: leave Credits out in the budget's advanced options. Google Cloud: clear Promotions under Savings.
One project per intern, named for the week, so there is one thing to delete at the end.
No access keys in GitHub. A key made for a command line tool is deleted the same day; the console and Cloud Shell are enough this week.
SSH closed. The EC2 launch wizard opens SSH to anywhere: untick it. Google Cloud's default network carries default-allow-ssh and default-allow-rdp from anywhere: delete them.

A budget is an alert, not a limit. It tells somebody; it stops nothing.

Day 2, the last 25 minutes

Teardown: every box the plan drew has a delete line

CloudFront on the Free plan: cancel the plan, disable the distribution, wait for it to finish deploying, then delete it. A distribution on a pricing plan cannot be deleted.
Empty each bucket, then delete it. Terminate the Beanstalk environment.
Delete Cloud Run services and any Cloud SQL or RDS instance. A stopped Cloud SQL instance still bills for storage and its IP address.
Delete virtual machines, load balancers, Lambda functions, DynamoDB tables, Cognito user pools, Firestore data and any Cloud DNS zone the plan created.
Release Elastic IPs and reserved static IPs.
Then open each service's list on both clouds. The billing page lags, so it cannot confirm anything is gone.
Last, shut down the Google Cloud project if nothing else lives in it, and only after its lists are checked: a project waiting to be deleted cannot be opened. It is held for 30 days and then deleted.

While they work

What to watch for

A budget set up before Sunday almost certainly counts credits. Re-check it on Day 1 or it will never fire.
The load balancer is the thing that usually survives a teardown, and it bills for every hour or part of an hour.
A Firebase project linked to a billing account, the free trial included, is moved to the paid Blaze plan.
A Google-managed certificate waits in provisioning until the domain points at the load balancer. That is the lesson of the path's lock stage, not a fault. A CAA record that allows only amazon.com stops Google from issuing at all.
S3's own website endpoint is HTTP only and needs a public bucket, which is why CloudFront is the front door on AWS.
Anything public other than the one bucket that holds only the public site is a finding for the access review.

Facilitator only · Week 4

Running the asset week

Week 4 is the first week the interns produce something you will actually use. The Asset Record Project starts here and runs to week 6, so what happens on Sunday sets the standard for three weeks rather than one.

Before you open your mouth

The one framing that has to be right

Identity on the register was about 93.5 percent complete on 21 August 2026, and that is a real result built by the team that implemented it. Identity is one of seven field groups. What the interns are adding is warranty, cost and lifecycle, and it is being added because new things need it: an insurance valuation after a move, a refresh budget, the numbers Finance depreciates against.

Why this matters more than it sounds. These three are going to be asking questions of the people who built this register. If they arrive describing it as incomplete, you spend the rest of the program repairing that. The lab material is written the right way round throughout, and this is the sentence to repeat: identity is done, and the new requirement needs financial and lifecycle fields on top of it.

Two numbers not to say, because both are wrong in a way somebody will repeat: 93.5 percent is not the register, it is one group of seven. And the difference between Intune and the register is not a count of missing assets, it is an unclassified difference between two systems counting different populations.

Changed 26 August

There are five priority levels now, not four

The grid was already the standard three by three with the bottom right cell folded into P4. It is split out: low impact with low urgency is P5, and the other eight cells are exactly where they were. Five tickets moved, including T03 and T17, which are two of the loudest traps in the bank.

The distinction to teach, because a fifth level with no meaning is just a longer list. P4 is on the clock: it is at the back of the queue, it has a target, and somebody is waiting for it. P5 has no clock: nothing is stopped, nobody is blocked, and it is done when there is capacity. The test is one question, who is waiting. If they can name a person and say what that person cannot do, it is P4. If the honest answer is that nothing is stopped and it would simply be better once it exists, it is P5.

Where interns will get this wrong. The test decides the bottom row of the grid only, the one-person row. Two tickets in the bank, T20 and T24, affect a whole team with nobody waiting, and both are still P4, because medium impact never reaches P5. If somebody argues T24 down to P5 they have applied a real rule outside the row it belongs to. Both tickets now say so in their explanation.

Nobody's score moved. The trainer marks the priority it derives from their impact and urgency against the ticket key, and both changed together, so every answer already given is still marked the same way.

The session

What is open this week, and in what order

Order	What	Time	What it is for
1	Asset Path, four stages	about 50 min	The lifecycle, the seven field groups and who consumes each one, and the judgment calls. Stage 4 classifies the difference between Jira Assets and Intune into cause codes.
2	Register Trainer, 19 records	about 40 min	The practice surface. Four decisions per record: which group to fill next, who is waiting, would the row load, and what you do. Most of the wrong answers are the ones that make the data look better, which is the instinct to catch.
3	The Asset Record Project	hand it over, 10 min	The assignment. Read the six rules together, out loud, then leave them to it.
4	Week 4 paper, 20 questions	30 min, timed	Marked and counted. Seventy percent to pass. Sit it at the end of the week, not the start.

The assignment

What you have to hand them, and when

The project cannot start until they have an export. That is the one thing only you can produce, and it is worth doing before Sunday rather than during the session.

Give them	Which columns	Not this
A dated export of the hardware records	serial, asset tag, make, model, type, status, department code, cost center	No assigned user names, no email addresses. Codes only. Rule 5 of the assignment says so and the sheet has to agree with it.
Which vendor route to use	Lenovo batch lookup for the bulk, Dell by service tag for the rest	Do not give them a reseller contact. The reseller route is yours, and it is the one that unblocks cost.
Where the output goes	One folder, dated filenames	Not into production. They never touch the live schema, and that is not a trust question, it is the rule.

The three deliverables at the end of week 4 are the raw warranty file, the miss list with reasons, and three numbers that add up: started with, matched, missed. If the three numbers do not add up, everything in weeks 5 and 6 is built on sand, so check that one thing even if you check nothing else.

Marking

What good looks like, and what to praise

Praise the miss list. The instinct is to hide misses because they look like failure. A miss list with a reason against each row is the most useful thing produced in week 4, and saying so once early changes how the next two weeks go.
Praise an empty cell. An intern who leaves acquisition cost empty rather than estimating it has understood the whole point. The public lookup gives dates, not money.
Watch for the tidy-up instinct. Setting a leaver's laptop to unassigned, marking a contradictory record to make it consistent, rounding a cost. Every one of those makes the data look better and the situation worse. The Register Trainer tests it in four places, so you will see it in their scores before you see it in their work.
Do not expect a high match rate. Machines bought before the current reseller relationship, machines from another reseller, transfers in, mistyped serials. A 70 percent match with a reasoned miss list beats a 95 percent match nobody can explain.

Reading their numbers

What the lab tells you without asking them

Everything on the Register Trainer posts a row per record judged, carrying which attempt it was and which of the four decisions were right. Two patterns are worth looking for:

Group call low, import call high. They are reading the record as a formatting exercise. The judgment is the part that matters and it is the part not landing.
Everything high except the action call. They can read a register and they do not yet know what to do about what they read. That is the one to coach directly, and it is the most valuable half hour you will spend this week.

Facilitator only · Week 3

Running the service desk week

Four things are open this week and they are meant to be done in order: the desk reference, the Triage Trainer, the Service Desk Arcade, then the exam. Everything is graded and explained in the browser. You point them at the hub, you say the four things below out loud, and on Thursday you read their shift report.

Time it takes you

Fifteen minutes on Sunday or Monday, ten minutes on Thursday. Nothing in between unless they ask.

Time it takes them

Twenty minutes on the desk reference, two to three hours on the twenty four tickets, and about ninety minutes on the assessment. The arcade is what they do instead of scrolling.

What you get back

A shift report per intern: tickets judged, and the percentage right on type, priority and route separately, plus how many times a loud ticket swayed them.

Put this on the screen

What they type

jahez-coop-lab.pages.dev

That is the whole address. No password, no invite code, nothing to install. They create an account with their work email, which takes about ten seconds, and everything they do from that moment is credited to them.

If you want them to land straight on the sign-up form rather than the sign-in one, add /?join=2026-fall to the end. It is optional and it carries nothing personal, deliberately, because a link with somebody's address in it ends up in browser history and in the server logs.

Tell them to use the same browser all week. Progress is kept on the machine they are sitting at.

Fifteen minutes at the start

The four things to say out loud

Priority is calculated, never chosen. They judge impact and urgency separately and the priority falls out of the grid. There is no priority button anywhere in the lab, and that is deliberate. It is the single thing most people get wrong on a real desk.
The user's stated priority is wrong on twenty one of the twenty four tickets. Not occasionally, almost always. Some are marked Urgent and are P5, the lowest level there is; one is written politely and is a P1. The word in the email is how the user feels, not how the ticket is scored.
The type decides everything after it. If the type is wrong the priority cannot be right, because a different process is measuring it. Thirteen of the twenty four are incidents, seven are service requests, two are problems and two are changes.
Two tickets go to Cyber GRC and nowhere else. A phishing report and a suspected supplier bank fraud. Sending either straight to a colleague, deleting the mail, or searching the mailbox yourself destroys the evidence. Cyber GRC is one door and it is the only one.

What not to say
Do not walk them through the priority grid before they start. They have the desk reference and the Trainer explains every answer as they go. Being wrong on ticket three and told why is worth more than being told first and being right on ticket three for no reason.

What they will hit

The eight tickets that catch nearly everyone

Every ticket in the bank explains itself after the answer, so you do not need to teach these. Recognize them when an intern gets stuck, and ask the question in the last column.

Ticket	They usually say	It is	Ask them
T03 URGENT!!! second screen	P1, because the subject shouts	Service request, P5	"Who set that priority, you or the sender?"
T09 dispatch board question	P3, because it is politely written	Incident, P1, L3	"How many people cannot work right now?"
T14 wifi terrible today	Fix the one laptop	Incident, P1, L3	"Did you check anyone sitting near her?"
T16 EVERYTHING IS DOWN	P1, because it says whole company	Incident, P3, L2	"Who else did you check before you believed it?"
T02 new girl needs the folder	Incident, she cannot work	Service request	"Did she ever have that access?"
T13 Request: new keyboard please	Catalog order, wait for approval	Incident, a part failed	"Did the keyboard work last week?"
T06 FW: is this real?	Delete it, praise her, close	Incident → Cyber GRC	"Who else got that mail?"
T21 recordings missing	Pass to L3 and wait	Incident → Vendor, P2	"Whose system is it, and who still owns the user's ticket?"

Four of the twenty four cannot be judged from what is written and need a question asked first. An intern who answers all twenty four without ever saying "I would ask" has not read them properly.

The arcade

Why there is a game, and what it is for

Ticket Rush

Sixty seconds, type only. Speed builds a multiplier, a wrong call resets it and costs three seconds. It drills the first decision until it is automatic.

Under Pressure

Ten tickets, three lives, impact and urgency judged separately while the queue fills. Getting the right letter from the wrong reading scores eight instead of twenty five, and says so.

Where Does It Go

Routing to L1, L2, L3, Vendor, Cyber GRC or Not IT. This is the one that exposes whether the six destinations landed.

XP comes from beating your own best, not from playing
A round that matches or misses their previous best earns nothing, so grinding the same game does not inflate a rank. If you see a large arcade score, they genuinely improved.

The assessment

Two different things, and they are not interchangeable

	Full assessment	Foundation style mock
Shape	80 questions, 5 tickets, 3 written answers	40 questions drawn from the 61 that sit on the ITIL 4 Foundation syllabus
Clock	None. It saves after every answer and resumes where they stopped	60 minutes, closed book, no feedback until the end
Feedback	After every question, with the reasoning	At the end only, with the ones they missed
Pass mark	None. It is a diagnosis, not a gate	65 percent, the real one
Use it for	Finding out what they do not know	Finding out whether they would pass on the day

Confidently wrong is tracked separately
Every question in the full assessment asks whether they were sure. The report counts how many times they were sure and wrong. That number matters more than the score: it is the one that costs on a live desk, and it is the number to open the Thursday conversation with.

The bank knows ITIL Version 5 exists. Those questions, along with the ISO comparisons and the L1/L2/L3 tiering, are deliberately kept out of the mock. They are good desk knowledge and they are not on the Foundation paper.

Ten minutes on Thursday

Reading a week 3 shift report

The report separates type, priority and route on purpose. The gaps between those three numbers are where the conversation is.

What you see	What it usually means	What to ask
Type high, priority low	They can classify but they are still reading the user's mood. The most common pattern, and the easiest to fix.	"On T09, what made it a P1 when nobody shouted?"
Priority high, route low	They judge severity well and do not yet know who owns what. Send them back to the six destinations on the desk reference.	"Who fixes a wireless design problem, and who fixes one laptop?"
Swayed count above three	Loud tickets are moving them. This is the habit the whole week exists to break.	"Which ticket did you re-read after you saw the answer?"
All three high, no timed shift	They did the practice queue with the explanations in front of them and never tested it cold.	"Run a shift before Thursday." It is eight tickets and it takes ten minutes.
Confidently wrong above five	Guessing with conviction. Worth more attention than any score on the page.	"Pick one of those. What would have to be true for the other answer to be right?"

The one question worth asking every intern
"Which ticket did you get wrong in a way you would not have believed?" It takes thirty seconds and it tells you whether the week actually landed.

Facilitator only

Running week 2 without running week 2

Everything in the Ops Range is injected, graded and explained by the software. There is no lab to stand up, no license to buy, no account to create and no session for you to deliver. Your job is three things: point them at the hub, answer questions when they ask, and read the shift report at the end of the week.

Time it takes you

Ten minutes at the start of the week, ten minutes at the end of it. Nothing in between unless they ask.

Time it takes them

About seventy minutes of Academy and four to six hours on the Range, spread across five days.

What you get back

A text file per trainee listing every mission, the hints taken, the collateral caused and whether the first call was right.

Ten minutes at the start

What to say when you hand it over

The estate is a training model of a normal corporate network. It is not our production network and none of the addresses in it are real. Do not treat anything in it as a documented Jahez fact.
Progress is stored in the browser, on their own machine, and copied to their lab account while they are signed in. If they clear site data or switch browser, it comes back by itself when they sign in. A practice account's progress is not gone either: its backups reach the lab without an account, so they do not come back by themselves, but you can pull the latest one by their email under Backups on the Compete page (Seats and cohorts) and send them the code to paste into Move my progress. Tell them to sign in, or to use the same browser all week.
Hints cost twenty five points. Collateral damage costs sixty. That difference is deliberate and it is the single most important thing to say out loud.
The capstone has no hints. Two faults and one report that is not a fault.
They export the shift report themselves at the end. You do not need to collect anything from their machine.

Ten minutes at the end

Reading a shift report properly

Total XP is the least interesting number on the page. These four tell you something.

What you see	What it usually means	What to ask them
High XP, several collateral	Changing things to see what happens, rather than reading first. Common and fixable.	"Walk me through M12. What told you that line was the wrong one?"
Low hints, wrong first calls	Persistent but guessing. They are solving by elimination, not by reasoning.	"On M09, what were the three things it could have been before you looked?"
Right first calls, many hints	They can reason and they do not trust it. The most improvable pattern here.	"You called M06 correctly. Why did you take a hint after that?"
Tier 3 untouched	Either they ran out of week, or the service and firewall layer did not land.	"What are the three reasons a share can fail?" The answer is path, service, filter.
Capstone solved, clean, no hints	They can hold two faults apart and leave a non-fault alone. That is the outcome.	"Why did you leave Gi1/0/12 shut?"

The one question worth asking every trainee
"Which mission taught you something you would not have got from reading?" The answer tells you whether the exercise did its job, and it takes thirty seconds.

Answer key

Injected fault, win condition and the trap, per mission

Read this before you rely on the key being hidden.

It is not hidden, and it cannot be. The Ops Range grades and explains in the browser, so missions.js has to carry every injected fault, every correct first call and every fix. The same is true of exam_mcq.js and tickets.js. Anyone who opens the developer tools can read all of it in under a minute.

This page used to hide the key behind a word. That was worse than useless: it implied a protection that did not exist. It is gone.

Which is fine, because none of this is assessment. The program says so itself: unlimited retakes, the score is for the trainee and not for their file. A trainee who reads the answers has only cheated themselves out of the practice. If any of it ever has to count, a graded exam, a certificate, anything a decision rests on, it cannot be marked in the browser. That needs the answers held server side and the grading done there, which is a different build, not a setting.

Answer key

All fifteen faults

The grader

What "solved" actually requires

A mission only closes when two independent checks both pass, which is why a trainee cannot make a symptom go away and call it fixed.

1. The service baseline

Fifteen assertions run against the live estate on every keystroke: thirteen things that must work, and two that must stay blocked. The trainee sees them as the service board on the left of the screen.

2. Structural integrity

Every port VLAN, trunk allowed list, SVI state, DHCP relay, host address, running service, host firewall and access-list line is compared against the intended design. Anything that differs is either the fault or collateral damage. There is no third category.

Restoring service by putting everyone into one VLAN fails the check.
Clearing the access list to fix printing fails the check, because it removes the guest segmentation.
Enabling the parked port on the Floor 1 switch fails the check, because that port is correct as it is.

Scoring

The model, in full

Component	Value	Why it is set there
Base XP	110 to 230, capstone 400	Roughly proportional to how many layers the trainee has to rule out.
Correct first hypothesis	+40	Rewards reasoning before touching. Marked on the first answer only.
Each hint	−25	Escalation is legitimate and it is not free. Three hints exist per mission and the third names the fix.
Each piece of collateral	−60	Deliberately more than two hints. Asking is cheaper than breaking something.
Debrief questions	+15 each	Answered after the fix, from memory. Retrieval is what makes it survive the week.
Speed	up to +50	Capped low on purpose. It is a tiebreak between two correct answers, never a reason to rush.
Floor	20 XP minimum	A mission solved badly is still a mission solved.

Ranks are lab-wide, not per app, and there is one ladder: Trainee, Service Desk L1 at 400, Service Desk L2 at 1000, Infrastructure Engineer at 1800, Systems Engineer at 2800, Corporate IT Certified at 4000, Service Owner at 6000, Operations Lead at 8500, Solutions Architect at 11500, IT Manager at 15000, and Head of Corporate IT at 19500. The last five were added so the rank keeps moving through week 16 rather than topping out in week 5. XP comes from every surface, Academy lessons, Range missions, path stages, and beating your own arcade best, so the rank beside their name is the whole program, not one week of it.

Reference, staff only

How the surface is built

The depth layer reference page shows the patterns every page in this lab is assembled from: the hero, the cards, the motion, the type scale and the Jahez color set. Read it when you want to know why a page looks the way it does, or before you ask for a change to one. The progress card on it holds a demonstration value rather than anybody's record, so do not read a number off it. It is not something an intern is meant to work through, and it is not on the week rail.

Open the design reference