What you are actually buying
Start with a shop. Campux sells outdoor gear from forty stores and one website, and the website runs on two servers in a closet at head office. Every November the site slows to a crawl; every February the same two servers sit nearly idle, still drawing power and still needing someone to patch them. The question this class answers is what changes when those two servers stop being Campux's problem.
In a public cloud such as Azure, you use computing services operated by a provider. You decide how the application uses them, how access is controlled, and what resources to keep. Cloud also includes private and hybrid arrangements; it is broader than renting one computer by the hour.
That last clause is the job. Every posting on the homepage that says Azure core services is asking whether you can make those decisions well, and every class after this one is a decision of that kind. This class gives you the five properties that separate cloud from a server in someone else’s closet, and the line between what you own and what you rent. Hold on to the line; it moves in Class Four, and you will want to know why.
First, the reason anyone rents rather than owns, told through the last utility that made the same journey.
The utility that arrived late
Electricity was, for a while, something a factory made for itself. Each mill kept its own generator, its own engineer, its own reserve of coal. Then the grid arrived, and the question stopped being how much generating capacity do we own and became how much power did we draw last month. Nobody misses the generator.
The switch was not really about technology; the generators worked. It was about economics. A shared grid could build at a scale no single mill could justify, run its plant closer to full, and sell the same capacity many times over as demand rose and fell across a whole city. The owner who clung to his own generator was not wrong that he owned it outright — he was wrong that owning it was the point. Every argument in this class is a version of that one, moved a century forward.
Computing took an extra century to make the same move. Until recently, running an application meant buying physical servers, racking them in a room with expensive cooling, and guessing — eighteen months in advance — how much capacity you would need. Guess low and the site collapses on the busiest day of the year. Guess high and money sits in a closet, depreciating quietly.1
Cloud computing is the grid. A provider — Microsoft Azure, in this bootcamp — owns the buildings, the machines, and the fibre. You provision resources and pay according to the service and offer. Reducing usage does not automatically remove every charge: allocated capacity, retained storage, and other resources can keep billing.
- Definition
- Cloud computing provides on-demand network access to a shared pool of configurable resources that can be provisioned and released quickly. NIST describes five essential characteristics, developed below.
Network access does not require exposing every resource to the public internet. A private cloud or private endpoint can provide controlled access. Metering measures use; it does not mean every service has an identical billing unit or automatically becomes free when an application is idle.
It helps to name the near-misses, because an exam and an interview both probe them. A rented physical server delivered to your building is not cloud — it is self-service in neither direction and metered by the month, not the minute. A colocation cage, where you own the machines and the provider owns the room, is not cloud either; you still bought the hardware and still carry the peak. Even a single virtual machine you rent by the hour is only the shallowest edge of it — virtualization, the trick of running many pretend computers on one real machine, is the enabling technology, but on its own it is one property standing in for five. Cloud is the whole set operating together, which is why "we virtualized our servers" and "we moved to the cloud" are different sentences describing different amounts of work.
| Before | After |
|---|---|
| Servers purchased months in advance | A server exists in minutes |
| Paid for in full whether idle or not | Charges depend on the service and retained resources |
| Capacity is a forecast | Capacity can change with an appropriate scaling design |
| Your staff replace failed disks | Someone else replaces failed disks |
| One room, one failure domain | Regions, zones, deliberate redundancy |
The closet, itemised
"Two servers in a closet" is a tidy phrase that hides a long invoice. Owning a machine meant owning everything beneath it. Someone specified it months ahead and signed a capital purchase order. Someone racked it, cabled it, and burned it in. Something kept the room cold enough that the processors did not throttle, and something else kept the power clean when the grid flickered at four in the morning. A person carried a pager so that the night a disk failed — and disks fail — they could drive in and swap it. None of that appeared in the price of the server; all of it was the cost of the server.
This is the stack the cloud actually rents you out of. Not just the processor and the disk, but the building, the cooling, the power, the physical security, the spare parts, and the labour that turns a box into a running service. When people say Azure "runs the hardware," this whole column is what they mean — and the Phase One recap puts a shape to who now pays for each layer of it.
Where the line falls
Here is the idea most often misunderstood, and the one most reliably asked about in an interview. Moving to the cloud does not hand your problems to Microsoft. It relocates the line between their responsibility and yours — Microsoft calls this the shared responsibility model, and the position of that line is the single most consequential fact in your working life.
Your configuration remains your responsibility.
A public storage container, an overprivileged service account, or a committed access key can expose a workload even when the provider infrastructure operates as intended.2 Provider incidents are also possible. Shared responsibility identifies which controls you own; it does not prove that every incident originates with a customer.
Which is inconvenient for the sales brochure and excellent for you. The half of the model the provider will never take is precisely the half you are paid to hold. Every class after this one is, in some sense, about defending that line.
Make it concrete with the kind of mistake that actually happens. Campux moves its product images to cloud storage and, to make the site "just work," someone sets the container to public. Nothing breaks; the page loads; the ticket closes. Months later a researcher finds the same container also holds the nightly database export, and now every customer record is a public URL. Azure did exactly what it promised — it served the file it was told to make public. The datacentre was never breached. A checkbox above the line was, by a person in a hurry. That is the whole model in one incident, and it is why the classes ahead spend so long on identity, access, and the discipline of least privilege.
The vocabulary worth carrying out of this section is the pair the figure labels on its left edge: security of the cloud and security in the cloud. Everything below the line — the datacentre, the hardware, the hypervisor (the software that splits one physical server into many isolated virtual machines) — is security of the cloud, and it is Microsoft's to guarantee. Everything above it — your data, your accounts, your configuration — is security in the cloud, and it is yours no matter which service you buy. The line's exact height changes with the service model, and Class Four will move it three times as it walks through infrastructure, platform and software services. What never changes is which side of it your name is on.
Hold on to why this is a career fact and not a compliance footnote. These boundaries matter when configuring a service, responding to an incident, and explaining a design. The bootcamp develops practical evidence of those skills. A course completion certificate does not establish every employer requirement or replace a Microsoft certification exam.
Five properties, and the ones that are missing
The formal definition — the one that survives contact with an examiner — lists five characteristics.3 Learn them, because they distinguish cloud from a rented server pretending to be one.
- On-demand self-service
- You provision through a portal or an API. No ticket, no procurement, no waiting on a hardware team.
- Broad network access
- The resource is reachable over the network from wherever it needs to be reached.
- Resource pooling
- Many customers are served from shared physical hardware, isolated from one another.
- Rapid elasticity
- Capacity can expand and contract with demand, automatically in some cases. The chosen service and configuration determine the scaling behavior.
- Measured service
- Consumption is metered by the second, the gigabyte, the transaction. Metering is what makes the rest billable.
The five, read through Campux's window
Abstractions like these only stick once you watch them touch a real company, so put each against the store you are about to inherit. On-demand self-service is the end of the eighteen-month wait: the November capacity Campux needs becomes a configuration you apply, not a purchase order finance approves in spring. Broad network access is why forty stores and one website reach the same systems over the same network, whether the till is on the shop floor or the shopper is on a sofa. Resource pooling is the uncomfortable, load-bearing truth that Campux's virtual machines share physical hardware with strangers — isolated by the platform, but not alone on the metal, which is exactly why the identity and configuration work in later classes earns its place. Rapid elasticity is the November peak met and the January trough released without anyone driving to a datacentre. And measured service is the meter that turns the other four into a bill — the same meter that will one day charge for the virtual machine nobody remembered to switch off.
Read together, the five are less a checklist than a single machine with Campux-shaped consequences. Take away metering and the elasticity has nothing to bill against; take away self-service and the elasticity waits on a ticket; take away pooling and the provider could never have offered the capacity in the first place. The properties earn their keep as a set, which is why an examiner asks for all five and an interviewer listens for whether you can say why each one is there.
Note what is not on the list. Not "cheaper." Not "always available." Not "secure by default." Those are outcomes you may or may not earn, depending on how well you do the job described in the previous section. A cloud is a set of properties, not a set of promises.
One orientation note, since the exam leans on these distinctions. The five characteristics answer "what makes something a cloud at all." Two further questions sit just behind them, and each gets its own class: what you rent — raw infrastructure, a managed platform, or finished software — is the service-model question of Class Four; and where it runs — public, private, or a hybrid of the two — is the deployment-model question of Class Five. Keep the three apart in your head. An interviewer who asks you to "define cloud" wants these five properties, not a recital of Azure product names.
Play it through
Three minutes on the closet Campux is about to leave behind. Drag November onto a fixed rack, then onto Azure, and watch what each one does to the machines nobody remembered to switch off. It plays on its own and stops when it needs your hands.
The accounting argument
Migrations are approved in finance meetings, not engineering standups. It pays to speak the language.
- CapEx
- Capital expenditure. A large purchase, made once, depreciating across years. Servers in a room. On-premises IT.
- OpEx
- Operational expenditure. An ongoing cost, paid as incurred, like the electricity bill. Cloud.
Renting can reduce an upfront hardware purchase and change the spending pattern. Compare the actual workload costs, support effort, and commitments. Resource cleanup and rightsizing are still needed; a migration alone does not establish a saving.
The longer version of this argument, which layers of the bill leave your books when you rent and the sharp edge that comes with paying by the hour, is in the Phase One recap. For now, hold the two words; the rest of this class is about what they buy.
The company you are about to join
Campux Retail
Every November their site slows to a crawl under holiday traffic. Every January those same two machines idle at eighty percent unused, billing full price in electricity, floor space, and the salary of the person who babysits them. Last month a disk failed and the storefront was dark for nine hours.
Leadership has approved a move to Azure. You have been hired as their first cloud engineer. Over the following forty-one classes you will design their identity model, their network, their delivery pipelines, their monitoring, and — eventually — their first AI feature. Every drill and every build in this bootcamp concerns them.
Hold their shape in mind: a sharp seasonal peak, a long idle trough, and a failure that cost real money. Almost everything in §4 and §5 was written for a company that looks exactly like this one.
Zoom out: the line you drew is now the system's fault-line
You have learned where the provider's responsibility ends and yours begins. Now reason about what that line does to the whole organisation, not just to one server — because a boundary this quiet reshapes who is accountable when things go wrong.
The cloud runs the hardware, so the team stops practising ops — and the skills that would settle an incident quietly atrophy until the night one is needed. What keeps the muscle alive: game-days, runbooks, and owning the half of the model that is yours on purpose?
Your uptime now rides on a provider's region, network, and pricing — dependencies you never had with a server in a closet. Map what fails if they have a bad day, and be clear which half of that failure is still yours to answer for.
The reliability ceiling of the whole system is the weaker half of the shared-responsibility line — not the provider's own uptime, which is measured in fractions of a percent, but your patching, your config, your access model. Buying a better provider does not move a wall you own.
The cloud makes spinning up a resource trivial — which is exactly why cost sprawl, shadow environments, and ungoverned growth become the new problem. The flexibility that sold the move is the thing the next forty-two classes exist to govern.
At one VM, "who owns security here" is academic. Across five hundred resources and six teams, it is the single question that decides whether a breach is a footnote or the company.
The engineer who ships is asked "does it run in the cloud?" The engineer who gets promoted is asked "and who is accountable when it does not?" — and has already drawn the line.
Turning a buzzword into a balance sheet
A founder catches you by the coffee machine: "Remind me why we pay Azure instead of buying servers?" You do not hand-wave. You walk her along the shared-responsibility line — what Microsoft runs, what you run — and name the two costs that vanished the day you left the server closet: the capital up front, and the Saturday someone used to spend swapping a dead drive. She nods. You just turned a buzzword into a balance sheet.
No lab this class
Class One stays on paper, on purpose — there is no Azure subscription yet to put your hands in. That starts at Class Seven, the first class with a real resource group to create and delete. Today's hands-on is the game above, dragging November onto a closet and then onto Azure. What is left is checking whether the ideas stuck.
Examination
Four drills, then two situations. Write an answer before revealing the reasoning, then compare your assumptions and proposed checks. These written answers remain on the page; the playable lesson can save its progress in this browser.
B. This is the closest description of the cloud model. A delivered server, an ordinary network drive, or outsourced staffing alone does not establish its five essential characteristics. Network access can be private; public internet exposure is not required.
C. Look again at Figure 2 — the line moves, but never above data and identity. A, B and D sit permanently below it. This is why "we moved to the cloud, so security is handled" is not merely wrong but expensively wrong.
Elasticity, measured service, self-service. Free tiers are bounded by design, and no provider guarantees uninterrupted availability — service agreements are written as a percentage of uptime, never as a certainty, and you will spend Phase Two learning to architect around the gap between them.
MEMORANDUM — Cloud migration, executive summary
1. Renting cloud resources can shift spending from CapEx to OpEx.
2. Supported services can scale automatically when autoscaling is configured.
3. Once we migrate, the provider secures our data and user accounts.
4. Metered usage determines charges; idle resources can still incur costs.
Line three. Lines one, two and four describe OpEx, elasticity and metering correctly. Line three hands the top of the stack to Microsoft, and Microsoft has not agreed to take it.
Consider the consequence rather than the error. Had that memorandum reached the board unchallenged, the security budget would have been written as zero, and the first breach would have been traced to a decision made in a slide nobody read closely. Catching this line is the job.
A strong answer concedes before it argues. He is not wrong that steady, predictable workloads can be cheaper on owned hardware — say so first, and you have his attention rather than his defences.
Then move to his numbers, not yours. The sticker price of a server omits power, cooling, floor space, the disk that failed last month, the nine hours the storefront was dark, and the salary of whoever spent those nine hours fixing it. And owned capacity must be bought for the November peak, then paid for through the January trough. Campux has the sharpest possible seasonal shape — the exact profile that consumption pricing rewards and ownership punishes.
The move that lands is arithmetic in his own units: nine hours of downtime, priced. That is a conversation about money, which is a conversation he wants to have.
The trap is the premise. Cloud was never supposed to be cheaper. It was supposed to be metered. Accept the premise and you spend the next month apologising for a property of the model.
Diagnosis, in order: open Cost Analysis and group by resource, then by tag if anyone bothered to apply them. Look for the four usual findings — machines running through nights and weekends nobody needed, sizes chosen "to be safe," premium storage under test data, and the orphans: disks, addresses and snapshots outliving the resources they belonged to.
The sentence: "Cloud is cheaper when we run it like a utility rather than a purchase — give me a day and I will show you exactly which meters we left running." You are formalising that instinct into budgets, alerts and tags in Class Thirty-Two.
Five things that will still be true in ten years
- Cloud provides on-demand access to pooled resources. Use all five characteristics to assess the model; public internet exposure is not required.
- Responsibility is shared, and the line never rises above your data and your identities.
- Five properties: self-service, broad access, pooling, elasticity, measurement. Cheapness is not among them.
- CapEx became OpEx. The invoice now reflects what you forgot as faithfully as what you use.
- Customer configuration and provider infrastructure can both fail. Know your controls, monitor the workload, and plan recovery.
Technical review · 1 October 2026. The scaling diagram and playable lesson are simplified examples. See Azure autoscale rules and limits and VM states and ongoing resource charges.
- The eighteen-month figure is a convention, not a law — procurement, racking and burn-in simply take longer than anyone plans for. The point survives at six months. ↩
- Microsoft describes the customer/provider split in its shared responsibility guidance. This lesson makes no statistical claim about the proportion of breaches caused by either party. ↩
- The five characteristics originate in NIST Special Publication 800-145, which remains the definition examiners reach for. It is barely three pages of substance and worth the twenty minutes. ↩
Say what makes something cloud rather than someone else's computer, and why a company would move at all.
Play the lesson above to stamp this class.
Then say hello in the common room: one sentence on where you are starting from. Captain O reads every post.
Next, the money reason for the cloud that nobody in the room says out loud.
Next · Why Cloud? →