The one thing you cannot redeploy
Phase Three taught you to treat infrastructure as disposable: if the template is in Git, the running copy is a print of it, and the cure for a sick resource is a fresh deploy. One component sits outside that comfort, and it is the one this class is about. The database's engine is replaceable like everything else — but its contents are the accumulated, unrepeatable memory of the business: every order, every customer, every price change. Lose a VM and you redeploy in minutes. Lose the orders table and there is nothing in Git to redeploy it from; there is only whatever copy exists somewhere else, and the gap between that copy and the moment of loss. Campux's founding disaster — Class One's nine-hour outage — was never really a server failure. It was a data failure wearing a server costume: the disk that died held the database, and the nine hours were mostly spent finding out what the last good copy was.
So databases get their own decision, made with the Class Four lens. Running SQL Server on a VM is IaaS: you own the OS, the patching, the backup jobs, the HA design — the exact toil the cloud exists to sell back to you, justified only when you need OS-level control or an unsupported configuration. The alternative this class teaches is the managed tier: PaaS databases, where the engine, the patching, the replicas, and — above all — the backups are the provider's problem, continuously and automatically, and what remains yours is the half that actually differentiates the business: the schema, the queries, the access model, and the recovery decisions. The Class One line runs through the data tier like everywhere else; the difference is that here, the stakes on your side of the line are unrecoverable.
You can redeploy anything except the data.
The Azure SQL family — three shapes of the same engine
Azure sells the SQL Server engine in three shapes, and interviews probe whether you know which is for what:
| Shape | What it is | Choose it when |
|---|---|---|
| SQL Database | A single database as a service — no server you can see, no OS, no patching; automatic backups and built-in HA. The default. | New applications, and most migrated ones. If nothing forces you off this row, stay on it. |
| SQL Managed Instance | A full SQL Server instance as a service — instance-scoped features (cross-database queries, SQL Agent jobs, CLR) intact, sitting in your VNet. | Lift-and-shift of estates that lean on instance-level features the single database cannot offer. Near-compatibility is the product. |
| SQL Server on VM | IaaS — the full engine, the full OS, and the full toil: your patches, your backup jobs, your HA design. | OS access, version pinning, or licensing arithmetic genuinely demands it — and someone signs for the toil, in writing. |
Within SQL Database, two more decisions matter and both are money. Purchase model: vCore is the modern default — compute and storage priced separately, translatable to real hardware, eligible for the Class Thirty-Two reservations; the older DTU model bundles everything into an abstract unit and survives mostly in existing estates.1 Compute model: provisioned pays for capacity around the clock, while serverless bills per second of actual use and can auto-pause when idle — Class Two's elasticity finally arriving at the data tier, and precisely right for dev, test, and the spiky little databases that spend most of their lives asleep. Production storefronts stay provisioned: an auto-paused database greets its first Saturday customer with a cold-start delay nobody enjoys.
Not everything is a table — the rest of the shelf
The relational engine earned its default status honestly — transactions, joins, and forty years of tooling fit most business data, and orders-and-customers is the textbook case. But Azure's shelf holds other shapes, and the engineering skill is matching the shape of the data and its access pattern to the engine, rather than choosing by fashion in either direction:
- Azure Cosmos DB
- Globally distributed, milliseconds-at-any-scale, schema-flexible documents — priced in Request Units, a token-like meter you will recognise from Class 35. Built for planet-scale session stores, catalogs, and IoT streams; expensive superstition when applied to a forty-store orders ledger because a slide said "web scale".
- PostgreSQL & MySQL
- The open-source engines as managed Flexible Server offerings — same PaaS contract (automatic backups, patching, HA options) for the half of the industry that never spoke T-SQL. The default answer when the application already speaks Postgres.
- The specialists
- Redis for cache, the Class 28 workspace for telemetry, blob storage for anything that is really a file. Half of database bloat is data that never belonged in a database — move it out and the database gets smaller, faster, and cheaper to protect.
One honest sentence about the fashionable end: document databases trade away joins, multi-table transactions, and enforced schema to buy their scale and flexibility. If your data is relational — and orders, inventory, and customers are the most relational data in commerce — that trade buys you nothing and costs you the guarantees you were quietly depending on. Situation 02 is the meeting where this sentence gets said out loud.
The vocabulary of loss — backups, RPO, RTO
Every conversation about protecting data reduces to two numbers, and you should be able to define them at a whiteboard without notes. RPO — recovery point objective — is how much data you can afford to lose, measured backward in time from the disaster to the last usable copy. RTO — recovery time objective — is how long you can afford to be down while recovery runs. Campux's nine-hour outage was an RTO of nine hours; the nightly backup tape behind it was an RPO of up to twenty-four — a November day of orders that existed nowhere but on the dead disk.
- RPO / RTO
- The two numbers that price a disaster before it happens: how much data you may lose (recovery point) and how long recovery may take (recovery time) — set by the business in hours and dollars, met by the engineer in configuration.
Here is what the managed tier buys, stated in those two numbers. Azure SQL Database backs itself up continuously — full, differential, and transaction-log backups on an automatic schedule you do not run — giving point-in-time restore to any minute inside the retention window (a week by default, configurable, with long-term retention available for the auditors).2 Two operational facts about PITR matter more than the feature list. First, a restore creates a new database — it does not overwrite the sick one, which means recovery is non-destructive and rehearsable: you can restore to five minutes before the bad deploy, inspect, and swap application connection strings deliberately. Second, PITR is the answer to the failure mode replication cannot touch — the bad write: the fat-fingered DELETE, the migration that mangled a column. Replication faithfully copies your mistake to every replica at the speed of light; only history lets you step back to before it. For RTO across a regional disaster, failover groups keep a geo-secondary warm in a paired region behind a listener endpoint the application never changes — the Class Thirteen indirection trick, applied to the data tier.
Connecting like it's this decade
The database is provisioned; now every lesson of the bootcamp converges on the connection to it. Identity: Azure SQL authenticates against Entra ID, which means the storefront connects with its Class Nine managed identity and the connection string contains no password at all — and the grown-up estate flips the switch that makes Entra authentication the only kind, retiring SQL passwords the way Class Thirty-Four retired API keys. Network: a private endpoint and the Class Fourteen DNS pattern take the database off the public internet entirely; the portal's "allow Azure services" checkbox is the convenient, promiscuous thing you untick on the way to production. Least privilege: the app's database user gets reads and writes on its schema — not db_owner, which is Contributor-on-the-subscription wearing a database costume.
And one behaviour every cloud application must learn, because it is the difference between PaaS theory and PaaS practice: transient faults are normal. A managed database occasionally drops connections — a failover, a patch, a rebalance, each lasting seconds — and the platform's promise is not "never blinks" but "recovers fast." Applications that treat a dropped connection as a fatal error convert a five-second platform blink into a customer-facing outage; applications with retry logic — a few attempts, exponential backoff, the pattern every driver now ships built-in — never notice. When the Class Thirty telemetry shows a burst of connection errors at 3am that resolved in eight seconds and no customer saw, that is not an incident. That is the contract, working.3
The closet's last tenant moves out
Long after the storefront went to containers and the pipeline went to OIDC, one resource kept running like it was on-premises with better weather: campux-sql, SQL Server on a VM, faithfully lifted-and-shifted in Phase Two and quietly accumulating the estate's worst numbers. A nightly backup script — RPO up to twenty-four hours, the same arithmetic that made the founding disaster nine hours long — plus an OS patch window someone owns, an old version pinned "for compatibility" nobody could name, and a Saturday failure mode everybody preferred not to discuss. The migration assessment finds no instance-level features in use — no cross-database queries, no Agent jobs that the pipeline doesn't already do better — so the answer is the Table 1 default: Azure SQL Database, vCore, provisioned for the storefront's steady load, with the dev copy going serverless and auto-pausing at nights and weekends for pennies.
The move itself is an evening: a migration of the data, a failover group with a listener endpoint the connection string points at, Entra-only authentication with the storefront's managed identity as the login — the last SQL password in the company is deleted rather than rotated — and a private endpoint per Class Fourteen. What changes on paper is the part worth a monthly-report line: RPO falls from a day to minutes, restore is a rehearsed drill instead of an archaeology project (the team runs one PITR restore into a scratch database just to watch it work — twelve minutes), and the November what-if from Class One finally has an answer with numbers in it. The old VM is deallocated, snapshotted for thirty days of superstition, then deleted — and its Class Thirty-Two line item goes with it. The closet, at last, is empty.
The official pages, and a CAMPUX overview
What is Azure SQL Database?
learn.microsoft.com/azure/azure-sql/database/sql-database-paas-overview
Automated backups in Azure SQL Database
learn.microsoft.com/azure/azure-sql/database/automated-backups-overview
A serverless database created and queried, the automatic-backup blade read line by line, and a point-in-time restore run to completion — with the stopwatch visible — will live here. Video to be added.
Create it serverless, query it, read its backup promise
Stand up the cheapest real Azure SQL Database, put a table in it, and — the actual point — read the backup and restore machinery you did nothing to configure.
Create a logical server and a serverless database (names are global — adjust yours):
az group create --name rg-db-lab --location eastus az sql server create --name campux-sql-<initials> \ --resource-group rg-db-lab --location eastus \ --enable-ad-only-auth false \ --admin-user labadmin --admin-password 'Rosebud!2026x' az sql db create --name lab-db --server campux-sql-<initials> \ --resource-group rg-db-lab \ --edition GeneralPurpose --compute-model Serverless \ --family Gen5 --capacity 1 --auto-pause-delay 60
What to notice: no VM appeared anywhere. The "server" is a logical name for auth and firewall rules, not a machine you patch — and the serverless flags mean this database bills per second of use and naps after an hour idle. (A lab uses a password for speed; §5 is clear about what production does instead.)Add your IP to the server firewall (portal: the server's Networking blade → add your client IP), then open the database's Query editor in the portal, sign in, and run:
CREATE TABLE orders (id INT PRIMARY KEY, item NVARCHAR(50), placed_at DATETIME2 DEFAULT SYSDATETIME()); INSERT INTO orders (id, item) VALUES (1, 'Alpine 7 boot'); SELECT * FROM orders;
What to notice: the firewall said no until you said otherwise — the database was born refusing the internet, which is the correct default posture meeting you at the door. In production this rule is a private endpoint, not an IP allowance.Now the point of the lab: open the database's Backups / restore experience in the portal and read what is already true.
What to notice: continuous backups are running, point-in-time restore is offered to any minute in the retention window, and you configured none of it. Compare this against the VM in the case file, where every one of these sentences was a script, a schedule, and a human's memory. This blade is what "managed" means.Optional but recommended: kick off a point-in-time restore to a few minutes ago, into a new database named lab-db-restored. Note the time it takes. Then delete everything:
az group delete --name rg-db-lab --yes --no-wait
The lesson: the restore created a new database beside the old — non-destructive, rehearsable, exactly what you want at 2am with shaking hands. You have now personally verified an RPO of minutes and measured an RTO with a stopwatch, which is one more restore drill than most working teams have run this year.
Zoom out: the database is one part of a living system
You have provisioned it, secured it, and connected to it. Now step back and reason about the whole. Systems thinking is the habit of looking past the box you just built to the loops, dependencies, and limits around it — because in production, nothing fails alone. Take a whiteboard and work these five prompts before the exam; there are no marking schemes here, only better questions.
A slow query makes a client retry, retries add load, and load makes queries slower — a reinforcing spiral that turns a hiccup into an outage. What balancing loops (connection pooling, a circuit breaker, a read replica, backoff with jitter) are damping that spiral in your design, and what happens the first day one of them is missing?
This is the one thing you cannot redeploy, and half the estate quietly depends on it. Draw every service that stops working if this database does. Which of those dependencies are written down — and which will you only discover during the incident?
In most systems the database is the wall everyone waits at. If traffic must double, ask what the true limit is — compute, connection count, or IO — because scaling the stateless app tier in front of an unchanged database just sends more cars to the same bottleneck.
You add geo-replication to survive a lost region. Good — and now every write carries more latency, the secondary can lag behind, and failover becomes a decision someone has to make at 3am. Every fix buys a new failure mode; name the one this fix introduced before you ship it.
At ten times the data and ten times the connections, something gives first — the connection limit, the nightly backup window, a query plan that was fine at small sizes. Which of those is a config change you make on a Tuesday, and which is a redesign you should have started last quarter?
The engineer who ships is asked "does it work?" The engineer who gets promoted is asked "and then what?" — and has already drawn the loop.
An RPO you have actually timed
A stateless service can be rebuilt from a template in minutes; the database holding every order cannot. You treat it accordingly — managed PaaS with continuous backups, a rehearsed point-in-time restore, Entra-only authentication, and a private endpoint. When someone asks "what happens if we lose it?", you answer with an RPO in minutes and a restore you have actually timed, not a hope.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — the question named Managed Instance's reason to exist. Cross-database queries and Agent jobs are instance-scoped: they live above any single database, which is exactly the layer SQL Database abstracts away and Managed Instance preserves. Pick A and the migration silently becomes a re-architecture project — every cross-database join rewritten, every Agent job rebuilt as something else — discovered not in the assessment but in week three, as breakage. That gap between "migration" and "rewrite" is measured in quarters, and promising one while delivering the other is how data-platform projects get their reputation. C answers a question nobody asked at maximum cost — relational workloads with instance dependencies are the worst possible Cosmos candidates. D surrenders to the toil the managed tier exists to absorb. The assessment method is the takeaway: list what the workload actually uses, then pick the lowest row of Table 1 that supports all of it.
B — restore is additive, and that design choice is your safety net. The 3:05 copy appears as a new database next to the damaged original, which means the panicking version of you cannot make things worse by restoring: you inspect the copy, confirm 3:05 was actually before the damage (it sometimes is not — check), decide how to reconcile the seven minutes of legitimate orders written between 3:05 and 3:12, and only then repoint the application. A describes the destructive in-place rollback people fear restore to be — believing A makes teams hesitate at exactly the moment hesitation costs data. C is false in the way that matters most: automatic backups are the product, running since the minute the database existed, with zero configuration — the lab made you go look. D confuses PITR with geo-restore. The operational habit: rehearse one restore per quarter, timed, into a scratch database — because the first time you run this procedure should not be the time it matters.
The schema, the door, and the disaster plan. This is Class 1's line drawn through the data tier, and the pattern holds: the provider took the undifferentiated machinery (backup execution, engine patching — the two rejects), and kept none of the judgment. Note the trap hiding in the third correct answer, because it is where PaaS complacency actually bites: Microsoft runs the backups, but Microsoft does not know your RPO — whether a week of retention satisfies your auditors, whether the business can eat an hour of lost orders, whether anyone has ever actually rehearsed the restore. "It's managed" answers who runs the machinery, never whether the machinery is configured to your stakes. The interview form: "what do you still own on a managed database?" — and the answer that lands is these three, closed with "and I rehearse the restore, because a backup nobody has restored is a hypothesis."
# design review: storefront database migration
1. Azure SQL Database, vCore, provisioned for prod;
serverless with auto-pause for dev/test.
2. Entra-only authentication; the app connects via
managed identity; private endpoint per Class 14.
3. Resilience: the failover group replicates every
write to the paired region within seconds, so no
further backup or restore planning is required.
4. App connection code adds retry with exponential
backoff for transient connection faults.
Line three — it defends against the rare disaster and disarms against the common one. Replication and backup answer different questions. Replication answers "what if the region dies?" — a real question, worth the failover group. Backup answers "what if we die?" — the fat-fingered DELETE, the migration that mangles a column, the bad deploy writing garbage — and against that failure class, replication is worse than useless: it propagates the corruption to the secondary within the same seconds it propagates everything else. Run the tape on line three as written: the 3:12 migration accident from Drill 02 arrives, the team fails over to the paired region, and finds the mangled table waiting for them there, faithfully replicated. Now there is no plan, because line three said none was required.
The fix costs one sentence: "PITR covers bad writes (retention set to the business's RPO, restore rehearsed quarterly); the failover group covers regional loss." Two mechanisms, two failure classes, both named. The distractors are the design working: serverless auto-pause is exactly right for dev (A — it is production it embarrasses), private endpoints and Entra auth are orthogonal layers that stack (B — network and identity, Classes 14 and 9), and retry logic is the §5 contract honoured, not error-hiding (D — the telemetry still records the faults; the customer just never meets them). Review data designs by failure class, not by feature count: every mechanism should have a disaster it answers, and every disaster a mechanism.
Concede the record before you audit it. Four years of uptime is real, and the ops lead earned it — say so, because the migration needs this person, not their surrender. Then reframe what "works" is measured in, because uptime is the wrong axis: the VM's actual numbers are an RPO of up to twenty-four hours (the nightly script), an RTO of "however long the last rebuild took, if anyone remembers it," and a steady tax of patch windows, backup verification, and version anxiety — paid in the scarcest currency the team has, senior attention. The database has not failed in four years; that is precisely why nobody has rehearsed what happens when it does. The founding nine-hour outage was this exact configuration, one disk earlier.
Then answer the risk argument on its own terms, because it is the strongest thing they said. Migrations are risk — concentrated, one-time, and controllable: an assessment that checks for instance-feature dependencies (Drill 01's method), a rehearsal against a restored copy, a cutover window with a tested rollback, and the old VM kept deallocated for thirty days. Against that one-time risk stands the standing risk of the status quo: every day of the twenty-four-hour RPO is a day of November orders that exists only on one disk. The honest comparison is not "risk versus no risk"; it is one rehearsed evening against a permanent open bet — Class 3 taught the shape: not migrating is also a decision, and it also has a failure mode.
Close by giving the ops lead the new job, not the pink slip. Resistance to managed services is often quieter than it sounds: the backup script is their competence, and PaaS reads as deletion of it. So say where the work goes: nobody babysits backups anymore — instead someone owns RPO/RTO targets, quarterly restore drills, failover rehearsals, and the access model — the judgment half of §4 and §5, which is a promotion, not a removal. The sentence that usually lands: "The script proved you can run a database. The migration is how the company stops needing you to prove it every night."
The trap is the premise — that engine choice is a modernity contest. Every feature in the pitch is real; none of them is free, and the meeting goes wrong the moment it becomes relational-versus-modern instead of workload-versus-engine. So put the workload on the table first: orders are the most relational data in commerce — an order joins customers, line items, inventory, and payments; the business asks aggregate questions across all of it; and the one non-negotiable property is transactional integrity, because "the payment recorded but the order didn't" is not a bug, it is a lawsuit. Then price the features against that shape: forty stores in one country have no global-distribution problem; millisecond reads solve nothing when checkout latency lives in the payment gateway; and "no schema migrations" does not delete the schema — it moves it, unenforced, into every application that reads the data, where it drifts silently instead of failing loudly. The document model trades away joins and multi-document transactions to buy scale properties this workload does not have.
Give the trade its honest wins, because that is what makes your no credible. Cosmos is the right answer to real shapes Campux may actually grow: the product-catalog cache behind the Class 33 chatbot (documents, read-heavy, schema-flexible), session state, review streams. Offering it a legitimate home does two things: it proves you evaluated the engine rather than defended a habit, and it converts the senior developer from opponent into the owner of a well-fitted pilot. The RU meter deserves one sentence too — Cosmos prices every operation in Request Units, and a join-shaped workload forced through a document engine pays for its awkwardness on every single read, a Class 32 conversation waiting to happen.
Close with the criterion, not the verdict. "We pick engines by the shape of the data and its access patterns: relational shape, relational engine; document shape, document engine. Orders are relational; the catalog cache isn't; let's run both where they fit." That sentence survives the meeting, scales to every future engine debate, and — worth noticing — is the same sentence this bootcamp has used for every technology choice since IaaS-versus-PaaS: fit first, fashion never. The strongest architectures in the room are always the boring ones with reasons.
Five things worth carrying out of this class
- The database is the one component you cannot redeploy from Git — its contents are the business's unrepeatable memory, which is why the data tier gets managed services, rehearsed restores, and more paranoia than anything else.
- The Azure SQL family in one line each: SQL Database is the default; Managed Instance exists for instance-scoped features in lift-and-shifts; SQL on VM is the toil you keep only when something real demands it. vCore over DTU; serverless for the databases that sleep.
- Pick engines by data shape, not fashion: relational for orders and joins, Cosmos where global scale and flexible documents are real requirements — priced in Request Units — and Flexible Server when the app already speaks Postgres or MySQL.
- RPO and RTO are the two brackets around every disaster, and replication is not backup: failover groups answer regional loss, point-in-time restore answers bad writes — it restores to a new database, and a backup nobody has rehearsed is a hypothesis.
- Connect like it's this decade: Entra-only auth via managed identity (no password exists), private endpoint, least-privilege database users, and retry logic — because transient faults are the contract, not an incident.
- The DTU-versus-vCore split is the exam answer; the working-life answer is that you will inherit DTU databases and migrate them opportunistically. Tier names beneath both models — General Purpose, Business Critical, Hyperscale — carry their own trade-offs this class deliberately compresses; Hyperscale in particular has grown from special case toward default for large databases, and its details shift often enough that you should read the current page before quoting it in a design review. ↩
- Retention defaults, maximums, and the exact cadence of full/differential/log backups vary by service, tier, and Microsoft's current documentation — check before you promise an auditor anything. Two things hold across all of it: backups run automatically from the moment the database exists, and restore targets a new database rather than overwriting. Treat specific day-counts on this page with suspicion; treat the contract as settled. ↩
- This class stops where the database administrator's craft begins: query tuning, index strategy, execution plans, and the dark arts of the optimizer are a career, not a section. The boundary sentence, one more time: you build and protect the platform the data lives on; when the queries themselves need surgery, knowing that it is surgery — and that a specialist exists — is the competence. The honest referral is a skill interviews reward. ↩