CAMPUX Cloud Bootcamp Recap · Phase One · After Class Nine ← Class Nine
Phase One — Recap
Classes 1–9 · Foundations · AZ-900
Read in ten minutes before Build I
Phase One Recap

Foundations, in review.

Nine classes ago the cloud was a word on a job posting. It is now a set of instincts: what the thing is, when not to use it, and how to lay out an Azure estate that a stranger can trust. This page gathers all of it into one place — so you can feel the arc before you build the proof of it.

§1

The nine, one line each

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, Policy decides 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.
§2

The ideas that stay

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.

§3

What you can now do

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.

Phase One — capabilities gained
You can…Built on
Explain to a non-engineer what the cloud is and when it is the wrong choiceClasses 1–3
Place a workload on the IaaS/PaaS/SaaS ladder and say who is responsible for whatClasses 4–5
Lay out an Azure hierarchy — management group, subscriptions, resource groups — to a naming convention you can defendClass 7
Assign least-privilege RBAC at the correct scope, holding the highest privilege yourselfClass 8
Write and assign an Azure Policy that denies non-compliant resources, inherited from the topClass 8
Give a workload a managed identity so no secret is ever stored or rotatedClass 9
Case File · Campux Retail

The estate you watched being born

Phase One, seen through one client

Across these nine classes, Campux Retail stopped being a shop that "wanted to move to the cloud" and became a governed tenant: the hierarchy drawn in Class Seven, the roles and the two policies set in Class Eight, the machine identity in Class Nine. You watched it happen in prose. In Build I you do it with your hands — and because prose cannot be inspected and your estate can, that is the version an interviewer will believe.

§4

In your head

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.

A founder wants everything in the cloud by Friday. Name one reason it might be the wrong call — and the one thing you'd insist exists before a single resource is created.
The thread · Classes 3, 7–8A steady, predictable workload can be cheaper on-premises (Class 3), so "cloud" is a decision, not a reflex. And the non-negotiable-before-anything is governance: the hierarchy, an RBAC model, and at least one policy — because an estate that grows before it is governed cannot be governed later without pain.
A developer must be able to deploy to test but must never be able to touch production. What single mechanism enforces that, and at what scope?
The thread · Class 8An RBAC role assignment — Contributor granted at the nonprod scope only. The wall is structural, not a promise: their permission simply ends at that boundary, and nobody but you holds Owner.
Your application needs to read a database password from Key Vault. Explain why there is no password of its own to store.
The thread · Class 9The app authenticates with a managed identity, not a secret. Azure vouches for the identity; the app presents no stored credential, so there is nothing to leak and nothing to rotate. A secret would only be a leak with a delay.
An executive asks, "Is our data safe now that it's in a SaaS tool?" What actually determines the answer?
The thread · Classes 4–5The shared-responsibility line. In SaaS the provider runs almost everything, but identity, access, and data-handling stay yours — "safe" depends on the half you still own, not the half they advertise.
A resource is refused because it was created in the wrong region. Where was that rule set, and why not simply set it on each subscription?
The thread · Classes 7–8An allowed-locations Policy with a deny effect, assigned once at the management group. Rules set high inherit downward — set it per subscription and the next subscription is born ungoverned. Inheritance is the whole reason the hierarchy exists.
Notes
  1. This recap deliberately holds no new material — if a line here is the first time an idea feels solid, the class it points to is one click up in the index, and re-reading it now is time well spent, not lost. ↩
  2. Phase One aligns to the AZ-900 (Azure Fundamentals) outline. The recap is not exam prep in itself, but if you can do everything in §3 without notes, the exam holds few surprises. ↩