Foundations, in review.

A phase is easier to hold as a shape than as nine separate reading sessions. Read down the list and you will feel the deliberate order: first what the cloud is and whether you should use it at all, then the map of the market, then the four moves that lay down a governed Azure estate. Nothing here was arbitrary; each class was the prerequisite for the next.

1 · What is Cloud?

Someone else's computers, rented by the second and reached over the network — and the shift from owning capacity to renting it.

2 · Why Cloud?

The honest business case: elasticity, capex-to-opex, and speed of provisioning — the reasons an organisation actually moves.

3 · Pros, Cons & When Not To

The counter-case. Steady, predictable workloads can be cheaper on-premises; "cloud" is a decision, not a default.

4 · IaaS, PaaS & SaaS

The service-model ladder, read as a shared-responsibility line: the higher you climb, the less you run and the less you control.

5 · Public, Private, Hybrid

Where the workload physically lives, and why regulation and latency — not fashion — decide it.

6 · AWS, Azure & GCP

The three-provider map, and why the capability matters more than the brand name that moves under it.

7 · Entra, Subscriptions & Resource Groups

The Azure hierarchy: identity at the top, the subscription as the billing-and-scope boundary, the resource group as the unit you create and delete together.

8 · RBAC & Azure Policy

The two guardrails: RBAC decides who may act — a role definition's Actions and NotActions, pinned to a scope — while Policy is the guardrail on what may exist. Both inherited down the hierarchy from Class 7.

9 · Service Principals & Managed Identity

How software authenticates without a human — and why a managed identity, holding no secret to leak, is the answer inside Azure.

Service names will change; these instincts will not. If you keep five things from Phase One, keep these — they are the reasons the rest of the bootcamp will make sense.

Cloud is a decision

Not a destination. You can now argue both sides of a migration, which is what separates an engineer from a hype-follower.

The responsibility line

Every cloud service splits work between you and the provider. Knowing exactly where the line falls for IaaS, PaaS, and SaaS is how you reason about risk.

Governance before growth

Hierarchy, roles, and policy come first — because an estate that grows before it is governed cannot be governed later without pain.

Least privilege & blast radius

Grant the narrowest role at the smallest scope. When something is compromised, the damage is bounded by how much access it held.

No standing secrets

A stored credential is a leak with a delay. Inside Azure, a managed identity removes the secret entirely — the most senior instinct in the phase.

Govern the estate before you grow it.

A recap is only honest if it names capabilities, not topics covered. Everything below is something you could be asked to do on day one of a junior cloud role — and now could.

Five questions, and none of them lives inside a single class — each one only resolves when two or three of the nine click together. Answer each in your head, out loud if you can, before you open the thread. If the answer comes fast, the phase has landed. If it doesn't, the thread names exactly which class to revisit.

Three passages that used to sit inside the classes, moved here so each class reads in one sitting. Nothing in them is new to the phase; each is the longer telling of an idea its class states in a paragraph. Read them when the short version is not enough.

The accounting argument, in full from Class One

The shift is the one Class One names in two words, CapEx to OpEx: a large purchase made once and depreciated for years, against an ongoing cost paid as incurred. Figure 4 (Class One’s numbering) draws what that shift actually moves. Buying a server was never the cost of a server; it was the cost of the room it sat in, the power that fed it, the cooling that kept it from throttling, the disk you kept in a drawer for the night the running one failed, and the person who drove in to fit it. On-premises, every layer of that stack is a line in your budget and a name on a rota. In the cloud the lower layers become Azure's to own and operate, and yours only to rent by the hour.

Name the categories that leave your books, because a CFO will ask you to itemise them: the capital tied up in hardware bought for a peak; the power and cooling of a room sized for machines that mostly idle; the floor space that room occupies; the maintenance contracts and spare parts; and the fraction of an engineer's week spent on tasks that produce no feature — patching firmware, chasing a fan, swapping a drive at two in the morning. The cloud does not make that work disappear. It moves the work to a provider who does it at a scale you cannot match, and converts your share of it from a capital purchase into a metered line you can switch off.

It also has a sharp edge, and you should be the person who names it before the invoice does: pay-as-you-go is pay-for-what-you-forget. A virtual machine nobody remembers provisioning bills at three in the morning on a public holiday. An oversized database sized "to be safe" is safe in precisely one direction. Cost discipline is not a finance afterthought bolted on in Class Thirty-Two — it is an engineering property of the systems you build, and it starts at the first resource you create.

There is a second move worth previewing, because it is the answer to that sharp edge. Pure pay-as-you-go is the right default for anything spiky or uncertain, but for the baseline you know you will run — the handful of units the storefront needs every month, all year — a provider will sell you that capacity cheaper in exchange for a commitment: reserve it for a year or three and the hourly rate falls sharply. The mature pattern is a blend — commit to the floor, pay on demand for the peak above it — and getting that blend right is much of what Class Thirty-Two means by cost management. For now, carry only the shape of it: metered does not have to mean unplanned.

When the answer is no, in full from Class Two

A cloud engineer who can only argue for the cloud is a salesperson with a certificate. The credible ones know the three places the honest answer is "not this, not yet," and can say so without flinching. Leadership tends to raise them in this order.

Compliance & residency

Some data is bound by law or contract to live in a particular country, under a particular custody, sometimes on hardware you can point to. The cloud has answers — sovereign regions, residency guarantees — but they are answers you must design for deliberately, not assume.

Latency & physics

Light is not negotiable. A factory sensor that must react in a millisecond cannot wait for a round trip to a region three hundred kilometres away. Some workloads belong at the edge or on-premises because the speed of light says so, and no SLA overrules it.

Sunk cost

A company that bought a datacentre eighteen months ago is depreciating it for years yet. Moving today means paying twice — once for the idle asset, once for the cloud. Often the correct engineering answer is "at the next refresh," and saying so earns more trust than a migration that bleeds money to prove a point.

Note that only one of these three is technical. Compliance is a legal fact and sunk cost is an accounting one, and you will meet both far more often than you meet a workload that is genuinely impossible to move. The skill is not knowing that the cloud is powerful. It is knowing where its power stops being the point.

Each of the three fails a different test, and it is worth naming which. Compliance fails the where test: the workload could run beautifully in the cloud, but the law will not let it run in that cloud, in that country, under that custody — and no amount of engineering elegance argues with a statute. Latency fails the when test: the round trip to the region takes longer than the workload has, and the speed of light does not negotiate. Sunk cost fails the now test: the move is right, but this quarter is the wrong quarter, because you would be paying twice — once for the idle asset you already bought, once for the cloud that replaces it — until the old hardware finishes depreciating. Class Three takes all three apart in detail and adds the ones that show up on the invoice rather than in the architecture. Carry this much: a good "no" is dated and reasoned, never reflexive.

The repatriation arithmetic from Class Three

Put Campux's two shapes side by side and keep capex and opex apart, or the arithmetic lies to you. The storefront needs three units of compute most months and ten in November, so scaling with demand costs it roughly $6,450 a year — against the roughly $18,000 it would cost, paid once, to buy servers sized for the November peak and leave them mostly idle the other eleven months. That gap, a yearly bill smaller than a single purchase, is the saving Class Two banked. Now take a workload with the opposite shape: an analytics job that grinds at ten units every hour of every day, month in and month out. It has no trough to release and no peak to amortise, so metered pricing bills all ten units, every month, forever — on the order of $18,000 a year, not once. Buy the same ten units of hardware outright instead and that $18,000 is spent a single time; the box then keeps working for however many years it lasts, while the cloud bill for the same workload keeps repeating. That is the arithmetic behind repatriation, and it holds only if you also count what a server room costs beyond the hardware — power, space, a refresh cycle, the people who rack and patch it. Add those in before you trust the comparison. Leave them out and you have only shown that the cloud is not free, which nobody claimed. Elasticity you cannot use is a discount you cannot claim; a bill that repeats every year is a different thing from a purchase that does not, and that difference, not a vague sense that owning is cheaper, is what sends a flat, steady workload back on-premises.