Mastery Program · CL-501
L2 MultiCloud Engineer — Flagship Capstone Program
Our flagship platform-engineering journey: 70 hours theory, 130 hours labs across networking, identity and security, container platforms, observability, FinOps and AI infrastructure — while one real multi-cloud platform is built live across all 25 days, with VPN+BGP, GitOps healing, DNS failover and a graded 5× load storm. Certified via 10 rotating capstone briefs on a fixed 120-point rubric with live demo stations.
25teaching days
200instructed hours
45sessions
5modules
B5Advanced
8 hours a day, on the same honest-hours basis as the rest of our catalog.
The shape
Where the time goes, and how it is delivered.
Where the time goes
Week 1: Multi-Cloud NetworkingWeek 2: Identity & SecurityWeek 3: Container PlatformsWeek 4: Observability, FinOps & AI InfraWeek 5: Capstone
How the time is delivered
LAB · 78 h (39%)PA · 36 h (18%)ILT · 70 h (35%)MP · 16 h (8%)
LATTICE — one platform, two clouds, built live across 25 days
The platform is not a capstone bolted on at the end; it is the programme. From day one the class builds one real multi-cloud platform — cross-cloud VPN with BGP, GitOps that heals itself after a hostile edit, health-checked DNS failover, traced and costed per request — and every lab is a change to that same system. Week five assigns a rotating brief, puts it through a five-times load storm and a timed cross-cloud failover, then asks the candidate to defend it at six demo stations against a fixed 120-point rubric.
rotating briefdaily artifact gates6 demo stationsviva120-point rubric defensegraded 5× load storm evidencetimed cross-cloud failover drill
The engagement
LATTICE, gated.
Each stage produces an artifact a panel can inspect. Nobody advances on attendance.
1
VM-1 · The fabric
A segmented, inspected cross-cloud network with a full reachability matrix.
Pass-gate — Every intended path is open, every unintended one is closed, and the candidate can explain each route selection.
Day 5
2
VM-2 · The trust layer
Federated identity with permission boundaries, workload identity and a live credential rotation.
Pass-gate — Escalation attempts are refused by a named control, and rotation completes with no failed request.
Day 10
3
VM-3 · The platform
GitOps-managed clusters across two clouds, enforcing policy and self-healing after a hostile edit.
Pass-gate — A change made directly against the cluster is reverted without human action, and the portability gaps are documented rather than hidden.
Day 15
4
VM-4 · The evidence layer
Traces crossing cloud boundaries, burn-rate alerting on a real SLO, and a defended unit cost per request.
Pass-gate — The alert fires against injected budget consumption, and every input to the cost figure is named.
Day 20
5
VM-5 · Under storm
A graded 5x load storm and a timed cross-cloud failover, both under observation.
Pass-gate — The SLO holds or the breach is accounted for, and recovery meets the RTO the candidate published in advance.
Days 22-23
6
VM-6 · Defended
Six live demo stations and a viva against the fixed 120-point rubric.
Pass-gate — The panel is satisfied on all six stations, and the candidate names what they would build differently.
Days 24-25
Curriculum
Every session, every lab, every hour.
45 sessions across 5 modules. Expand any module to see the sessions, what a learner can do at the end of each, and the artifact they submit.
Week 1: Multi-Cloud Networking40 h · 10 sessions
D1a
Hub-and-spoke, three ways
Compare how AWS, Azure and GCP each express a hub-and-spoke topology, and say which primitive you would standardise on and what you lose by doing it.
Submittable labA topology decision record naming the chosen primitive per cloud and the capability sacrificed in each.
ILT4 h
D1b
Transit Gateway hub-spoke
Stand up a Transit Gateway hub with segregated spokes and prove traffic can only take the paths you intended.
Submittable labA working hub-spoke with a reachability matrix showing every intended path open and every unintended one closed.
LAB4 h
D2a
Azure vWAN and centralised inspection
Explain where inspection belongs in a multi-cloud egress design, and what it costs in latency and money to put it there.
Submittable labAn inspection design with the latency and egress cost of the chosen placement estimated and sourced.
ILT4 h
D2b
vWAN with firewall policy
Build a secured virtual hub and prove that an unapproved egress destination is actually refused.
Submittable labA vWAN deployment with a denied-egress test captured in firewall logs.
LAB4 h
D3a
Cross-cloud VPN and BGP
Read a BGP table well enough to predict which path traffic takes before you send it, and to explain it after.
Submittable labAn annotated route table for the platform's cross-cloud paths with the selected route justified per prefix.
ILT4 h
D3b
Cross-cloud tunnel with BGP
Bring up a VPN between two clouds with BGP, and diagnose the MSS problem that only appears once real payloads cross it.
Submittable labA working cross-cloud tunnel with a packet capture showing the MSS clamp resolving a fragmentation failure.
LAB4 h
D4a
Global DNS and traffic steering
Choose a failover strategy from the recovery objective backwards, and state what the DNS TTL commits you to.
Submittable labA failover design naming the steering policy, the TTL, and the worst-case client recovery time it implies.
ILT3 h
D4b
Global DNS failover
Configure health-checked global DNS and measure how long a client actually takes to follow the failover.
Submittable labA measured failover: the time from origin failure to client recovery, recorded rather than assumed.
LAB5 h
D5a
Segmentation across accounts
Design route segmentation that survives someone adding an account next quarter without a redesign.
Submittable labA segmentation model with the rule that governs new-account onboarding written down.
ILT3 h
D5b
Proctored — the network gate
Under proctored conditions, deliver a segmented, inspected, cross-cloud network and defend its reachability matrix.
Submittable labThe platform's network layer submitted with its reachability matrix and inspection evidence, assessed live.
PA5 h
Week 2: Identity & Security40 h · 10 sessions
D6a
IAM boundaries that hold
Distinguish what a permission boundary can enforce from what only an SCP can, and place each accordingly.
Submittable labA boundary design showing which control stops which escalation path, with the gap each leaves.
ILT4 h
D6b
Boundaries and escalation testing
Implement boundaries, then try to escalate past them and record what stopped you.
Submittable labAn escalation test log listing each attempted path and the control that refused it.
LAB4 h
D7a
Federation and OIDC
Trace a federated login end to end, and name the trust you are extending at each hop.
Submittable labA federation diagram annotated with the trust granted at every hop and its blast radius.
ILT4 h
D7b
Workload identity to pods
Give a pod a cloud identity with no long-lived secret anywhere in the path, and prove none exists.
Submittable labWorkload identity federation working, submitted with a search demonstrating no static credential in the cluster.
LAB4 h
D8a
CSPM and what it misses
Read a posture report critically: separate the findings that matter from the ones that merely score.
Submittable labA triaged CSPM report with findings ranked by exploitability rather than by severity label.
ILT4 h
D8b
GuardDuty detection and response
Trigger a real detection and drive it to containment through automation rather than a console.
Submittable labA detection-to-containment run with timestamps for detection, decision and containment.
LAB4 h
D9a
Secrets and rotation
Design rotation that does not need a maintenance window, and say where the design still breaks.
Submittable labA rotation design naming the dual-secret window and the one component that still requires care.
ILT3 h
D9b
Rotation without downtime
Rotate a live credential with traffic flowing, and prove no request failed while you did it.
Submittable labA rotation performed under load with the error-rate graph across the rotation window submitted.
LAB5 h
D10a
Identity blast radius
State what an attacker reaches from one compromised workload identity, and what stops the second hop.
Submittable labA blast-radius analysis for the platform's most privileged workload identity.
ILT3 h
D10b
Proctored — the identity gate
Under proctored conditions, deliver federated identity with boundaries, workload identity and rotation, and defend the blast radius.
Submittable labThe platform's identity layer assessed live, with escalation tests and a rotation performed on demand.
PA5 h
Week 3: Container Platforms40 h · 10 sessions
D11a
EKS, AKS and OpenShift compared
Choose a container platform on the constraints that actually differ between them, not on preference.
Submittable labA platform selection memo naming the deciding constraint and what the runners-up would have cost.
ILT4 h
D11b
Cluster baseline across two clouds
Stand up equivalent clusters on two clouds and enumerate honestly where equivalence breaks.
Submittable labTwo clusters with a written list of the behaviours that did not port and why.
LAB4 h
D12a
GitOps and reconciliation
Explain what reconciliation guarantees and what it cannot, so you know which failures GitOps will not save you from.
Submittable labA written account of three failure modes GitOps repairs and two it does not.
ILT4 h
D12b
ArgoCD self-heal after a hostile edit
Make a hostile change directly against the cluster and show the platform putting it back without you.
Submittable labA recorded drift-and-heal cycle with the reconciliation timestamp and the diff that was reverted.
LAB4 h
D13a
Policy as code
Write admission policy that blocks the workload you actually fear, and does not block the ones you need.
Submittable labA policy set with both a blocked case and an allowed case, each with its test.
ILT3 h
D13b
Gatekeeper and SCC portability
Enforce equivalent policy under Gatekeeper and OpenShift SCC, and document where the models refuse to line up.
Submittable labEquivalent policy on both platforms with a portability note listing the irreducible differences.
LAB5 h
D14a
Scheduling economics
Decide when spot capacity is responsible engineering and when it is a hidden outage, from the workload's tolerance.
Submittable labA capacity plan naming which workloads may run on spot and the disruption budget each is given.
ILT3 h
D14b
Karpenter with spot and disruption budgets
Run production-shaped workloads on spot pools and survive a forced interruption without breaching the budget.
Submittable labA forced spot interruption with the disruption budget observed and the recovery timeline recorded.
LAB5 h
D15a
Platform failure drills
Choose the drills worth rehearsing for this platform, and say what each one proves.
Submittable labA drill plan naming three drills, what each proves, and the evidence each produces.
ILT3 h
D15b
Proctored — the platform gate
Under proctored conditions, deliver GitOps-managed clusters that self-heal and enforce policy, and defend the portability gaps.
Submittable labThe platform's container layer assessed live, including a hostile edit reverted under observation.
PA5 h
Week 4: Observability, FinOps & AI Infra40 h · 10 sessions
D16a
OpenTelemetry as a contract
Treat instrumentation as an interface: decide what every service must emit before anyone writes a dashboard.
Submittable labAn instrumentation contract naming required spans, attributes and their cardinality limits.
ILT4 h
D16b
Tracing across cloud boundaries
Get one trace to survive a hop between clouds, and fix the context propagation that breaks it.
Submittable labA single trace spanning both clouds, with the propagation defect found and corrected.
LAB4 h
D17a
SLOs and burn-rate alerting
Set an SLO the business would recognise, and build alerting that wakes someone only when it should.
Submittable labAn SLO definition with burn-rate thresholds and the alert each threshold fires.
ILT4 h
D17b
Burn-rate alerts with runbooks
Wire burn-rate alerts to runbooks and prove the alert fires at the right moment, not merely eventually.
Submittable labA burn-rate alert demonstrated firing against injected error budget consumption, with its runbook attached.
LAB4 h
D18a
Unit cost per request
Reduce the platform's economics to one number an engineer can act on, and defend how it is derived.
Submittable labA unit-cost model showing cost per request with every input and assumption named.
ILT3 h
D18b
Cost engine and allocation
Attribute spend to teams and workloads, and show what remains unallocated and why.
Submittable labA cost allocation report with the unallocated remainder quantified and explained.
LAB5 h
D19a
Serving LLMs on your own platform
Decide when self-hosted inference beats an API for this workload, on measured cost and latency.
Submittable labA serving decision with the crossover point calculated for the platform's actual request profile.
ILT3 h
D19b
vLLM, LiteLLM and semantic cache
Serve a model behind a gateway with semantic caching, and measure what the cache actually saves.
Submittable labA serving stack with measured hit rate, latency and cost per request before and after caching.
LAB5 h
D20a
Load testing that tells the truth
Design a load test whose shape matches real traffic, so the result means something when it passes.
Submittable labA k6 test plan justified against the platform's observed traffic profile.
ILT3 h
D20b
Proctored — the observability gate
Under proctored conditions, deliver tracing, SLO alerting and unit-cost reporting, and defend the numbers.
Submittable labThe platform's observability and FinOps layer assessed live, with the unit-cost figure defended.
PA5 h
Week 5: Capstone40 h · 5 sessions
D21
Capstone build — brief assigned
Take a rotating capstone brief and reshape the platform to meet it, declaring the trade-offs you accept.
Submittable labA build plan against the assigned brief naming the deviations from the reference platform and the reason for each.
LAB8 h
D22
Graded 5x load storm
Hold the platform to its SLO through a five-times load storm, and account for whatever gave way.
Submittable labLoad storm evidence at 5x nominal: SLO adherence, autoscaling behaviour, and a post-mortem on every breach.
PA8 h
D23
Timed cross-cloud failover drill
Fail an entire cloud and recover inside the objective you published, under observation and against the clock.
Submittable labA timed failover with recovery measured against the stated RTO and the gap, if any, explained.
PA8 h
D24
Demo stations
Take a panel through six stations of the platform, answering for decisions made weeks earlier.
Submittable labSix demo stations delivered to panel — network, identity, platform, observability, cost, and AI serving.
MP8 h
D25
Viva and rubric defence
Defend the platform against the fixed 120-point rubric, including the parts you would build differently now.
Submittable labA rubric defence scored live across all 120 points, with the candidate's own list of what they would change.
MP8 h
| Mode | What it means |
|---|---|
| ILT | Instructor-led session (live, cohort) |
| LAB | Hands-on lab with submittable artifact |
| SP | Self-paced (curated resources + exercise) |
| MP | Mentor panel (review / pairing / retro) |
| PA | Proctored assessment (BuildReady / ProctorShield) — feeds PRI → DRI |
Proof
How we decide someone is ready.
The fixed 120-point rubric this programme is certified against. The weights are published, and a panel scores against them live.
Correctness under test
The platform does what it claims when a proctor drives it, not only when the candidate does.
25 pts
Resilience
Survives the load storm and the failover drill within published objectives.
20 pts
Security posture
Boundaries hold under escalation testing; no long-lived credential anywhere in the path.
20 pts
Architecture and trade-offs
Decisions are defensible and the cost of each is stated, including the rejected options.
20 pts
Observability and cost
Traces cross clouds, alerts fire for the right reason, and unit cost is derived rather than asserted.
15 pts
Operability
Runbooks match reality; another engineer could take the pager tonight.
10 pts
Communication
Explains the platform to a panel at the level each questioner needs.
10 pts
Next step
Run CL-501 for your team.
Tell us who is being trained and where they start, and we will scope it.