Provision a database, pull the connection string via a Key Vault reference, and run a query.
The one thing you cannot redeploy
A database has two parts to think about: the engine, which runs queries, and the data, which holds the business's orders, customers and prices. A deployment template can recreate the engine. It cannot recreate yesterday's customer orders unless those changes were saved elsewhere. In Class One's fictional outage, a failed disk stopped the service for nine hours. To plan recovery, ask two separate questions: how old is the latest usable copy, and how long will it take to make the application usable again?
With SQL Server on a VM, your team manages the guest operating system, SQL Server configuration and recovery design. A managed platform database such as Azure SQL Database handles platform patching and automatic backups. Your team still owns the schema, access, retention choices, regional recovery design and restore tests. Managed backups reduce operating work; they do not decide how much loss the business accepts.
Code rebuilds the engine. A usable backup recovers the data.
The Azure SQL family — three shapes of the same engine
A relational database keeps related records in tables. A query asks it to read or change those records; a transaction groups changes so they succeed or fail together. Azure offers the SQL Server engine in three shapes. Start with what the application needs, then choose who will manage the server:
| 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, you also choose how to pay for compute. vCore separates compute and storage; DTU bundles resources into a unit. Compare actual workload and prices before choosing.1 With provisioned compute, capacity stays allocated. Serverless is a General Purpose vCore option that scales compute with demand and can auto-pause after an idle period; storage continues to be billed, and some features or open sessions prevent pausing. It can suit a development database that sleeps often. A storefront that must answer immediately should test the wake-up delay before considering auto-pause.
The service tier — performance and availability trade-offs
The service tier shapes performance, storage and high-availability options. It does not replace a backup or an application recovery plan. Ask how the application behaves during a failed node, not only which tier appears on its invoice.
- General Purpose
- Separates compute from storage and is a useful starting point for many workloads. The platform can recover from a failed compute node, but the application can still see interrupted connections. Test its behavior against your availability target.
- Business Critical
- Uses local storage and multiple replicas for lower-latency, high-availability workloads. Read scale-out may be available. Measure whether its added cost solves a real latency or recovery requirement; a replica does not replace a restore plan.
- Hyperscale
- Separates compute, log and page storage to support large and growing databases. Its backup and restore architecture differs from the other tiers. Test restore duration with your own database size and configuration before promising a recovery time.1
Choose a tier by the workload's size, latency, availability and recovery needs. Start with General Purpose if those needs fit, then test the application through a failover and a restore. Business Critical and Hyperscale solve different constraints; neither supplies an application-wide recovery guarantee by its name alone.
Elastic pools — one budget for many databases
The shapes above assume one database sizes one bill. The moment you run many databases whose busy hours do not line up, that assumption overspends: provision each for its own peak and you pay for forty peaks that never happen at once. An elastic pool is one purchased block of vCores that a set of databases share — one database spikes while thirty-nine idle, and the pool absorbs it without any of them holding private, wasted headroom. It is the native shape of the per-tenant SaaS design: a database per customer, isolated for blast-radius and compliance, but billed against one shared floor.
Campux does not need a pool today — it runs one storefront database, and forcing a lone database into a pool only adds a knob. But the shape is worth holding, because it is where the estate could grow: the day Campux gives each of its forty stores its own database — for tenant isolation, per-store restore, a clean compliance boundary — the pool is what stops that decision from meaning forty times the bill. Store peaks are staggered by geography and local promotion; uncorrelated peaks are exactly what a pool is priced to feed.
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
- A document database with configurable regional distribution and throughput. Requests consume Request Units, which measure the work they require. It can suit session stores, catalogs and IoT events when the access pattern and partition design fit; measure cost and query behavior before moving an existing orders ledger.
- 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.
Choose a data model for the operations the application must perform. A relational database supports joins across tables and transactions across related records. Cosmos DB for NoSQL supports flexible documents and ACID transactions within one logical partition key; its JOIN works within an item, not across independent documents. If one order needs coordinated changes across several entities, map the partition and transaction boundaries before choosing a document store. Situation 02 asks you to defend that choice without claiming Cosmos has no transactions.
When Cosmos does earn a workload — the catalog cache, session state — three facts run its life, and all three are decided on day one. The partition key is the property Cosmos uses to spread documents across physical storage, and it is the one choice you cannot easily change: changing it means migrating the container, so choose for even distribution — a high-cardinality value like customer id, not store number, where forty values would have to carry a November. Every operation is priced in Request Units: each read, write, and query burns RUs against the throughput you provisioned, which means a badly shaped query has a visible per-execution price — Class Thirty-Two arrives on every single read. And consistency is tunable, five levels running from strong (every read sees the latest write, paid for in latency) to eventual (fast, and briefly wrong); the level worth memorising is session, the default most applications keep, because it gives one caller read-your-own-writes without charging everyone strong's price.
Choose the API your application actually needs
Azure Cosmos DB offers several APIs, including NoSQL, MongoDB, Cassandra, Gremlin and Table. The API for NoSQL is a natural choice for a new document application designed around it. Compatibility APIs can reduce some migration work for existing applications, but protocol compatibility does not guarantee identical features or a connection-string-only migration. Test queries, data types, indexes, transactions and drivers before committing. Gremlin addresses graph workloads; Table addresses key-value table patterns. Pick the API after checking the current product documentation and your application's requirements.
The five consistency levels, as a spectrum
Section prose named three of the levels; the exam and the design review want all five, in order, because they are a dial, not a menu. Every step down from strong buys latency, throughput, and write availability across regions — and pays for it in a weaker promise about what a reader might see. The two middle levels are the ones candidates forget, and they are precisely the useful compromises.
| Level | The promise | The price, and where it fits |
|---|---|---|
| Strong | A read always returns the most recent committed write. Linearizable — there is one true "now". | Highest latency; constrains multi-region writes. Financial ledgers where a stale read is a wrong answer. |
| Bounded staleness | Reads may lag, but by no more than a stated bound — K versions or T seconds — never further. | Global reads with a written SLA on how stale is too stale. A leaderboard that may trail by five seconds but not five minutes. |
| Session | Within one client session: read-your-own-writes and monotonic reads. The default. | Cheap where it counts. The user who just posted sees their post; another user might wait a beat. Most applications, correctly. |
| Consistent prefix | Reads never see writes out of order — you may get stale data, never a reordered or missing middle. | Order matters, absolute freshness does not. A comment thread that must not show reply-before-question. |
| Eventual | No ordering guarantee; replicas converge in time. Lowest latency and cost. | Like-counts and view-counts, where briefly wrong and eventually right is entirely fine. |
Regional distribution is a design choice, not an automatic guarantee. Add the regions the application needs, configure the client's preferred regions, and test routing and failover. With single-region writes, one region accepts writes and others may serve reads. With multi-region writes, multiple regions accept writes, so conflicting updates need an explicit resolution policy. Choose consistency, write topology and failover behavior together, then measure latency and data freshness from each user location.
Flexible Server, in more than one line
Azure Database for PostgreSQL and Azure Database for MySQL offer managed Flexible Server options for applications already built around those engines. Depending on the service and configuration, you can choose burstable compute, high availability and read replicas. Check each product’s current backup retention, restore behavior and regional recovery options separately; the two services do not inherit Azure SQL Database’s exact contract.
Play it through
Four minutes. Compare a global catalogue and an existing order ledger. More than one engine may work; explain the data, transaction, query and regional trade-offs behind your choice.
The vocabulary of loss — backups, RPO, RTO
RPO (recovery point objective) is the maximum age of data the business agrees it may lose. RTO (recovery time objective) is the maximum time it agrees the service may be unavailable. These are targets set before an incident. The latest usable recovery point's age and the actual time to restore are measured after a test or incident. In Campux's fictional disk outage, service was down for nine hours; that was an observed recovery time, not an agreed nine-hour RTO. A nightly backup was a candidate for a roughly one-day data-loss target only if the last job succeeded and its copy was usable.
- 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.
Azure SQL Database takes automatic full, differential and transaction-log backups on a schedule; log backups are generally about ten minutes apart. Point-in-time restore (PITR) creates a new database at a selected available time within its retention window, which is seven days by default for many new databases. Check the current retention and earliest restorable time in your own database.2 This helps recover from an accidental DELETE or bad migration: replication can copy the mistake, while a backup lets you return to an earlier point. Inspect the restored copy, reconcile legitimate writes made afterward, and only then redirect the application. A failover group can provide a secondary database in another region and a listener endpoint for regional failover; it still needs a rehearsed application procedure, and its actual data loss and downtime must be measured. Geo-restore instead creates a database in another region from geo-replicated backups and can have a different recovery profile. Neither feature by itself proves the business's RPO or RTO.
Connecting like it's this decade
The database is provisioned; now secure the connection. Identity: configure Microsoft Entra authentication and grant the storefront's managed identity only the database permissions it needs. With Entra-only authentication enabled, the application need not store a SQL password. Network: a private endpoint plus correct private DNS gives clients a private path; disable public network access separately if the design requires private-only access. Least privilege: grant the app the required reads and writes, rather than the broad db_owner role.
Managed services can interrupt connections during maintenance or failover. For a temporary connection error, use bounded retries with backoff and jitter, and record failures in telemetry.3 A retry of a write is safe only when the operation is idempotent—repeating it cannot create another charge or order—or when the application checks whether the first attempt succeeded. Test the entire customer request during a failover: a driver reconnecting does not prove that checkout stayed available.
The closet's last tenant moves out
In this fictional estate, the storefront still runs SQL Server on a VM. The team owns OS patches, SQL Server configuration and a nightly backup job. That job may leave many hours of changes without a usable recovery point if a failure happens just before the next backup. An assessment finds no instance-level feature that requires the VM, so the team evaluates Azure SQL Database against compatibility, cost and recovery requirements. It chooses provisioned compute for the steady storefront and tests General Purpose serverless for a separate development copy.
The team rehearses the data migration, application cutover and rollback before scheduling production work. It configures Entra-only authentication and a managed identity, restricts network access, and tests a regional failover group and a separate point-in-time restore. The exercise records the newest usable recovery point and the full time to make checkout work again; those results are compared with the agreed RPO and RTO. Only after validation does the team retire the old VM. The managed service reduces routine patching and backup work, but the recovery outcome remains the team’s responsibility.
Create it serverless, query it, read its backup promise
This optional lab creates a real, billable Azure SQL Database. Check your subscription's pricing and quota first. Use a fresh resource group so cleanup is clear. You will create a small table, inspect backup settings and, once point-in-time restore becomes available, optionally test a restore.
In Bash-based Cloud Shell, sign in as a user, then create a logical server with that user as its Microsoft Entra administrator. The server name must be globally unique:
AZ_USER_UPN=$(az ad signed-in-user show --query userPrincipalName -o tsv) AZ_USER_ID=$(az ad signed-in-user show --query id -o tsv) RG_NAME="rg-db-lab-$RANDOM-$RANDOM" SERVER_NAME="campux-sql-$RANDOM-$RANDOM" LOC=westus2 # eastus refused new SQL servers in our October 2026 run # if the server create fails, set a new SERVER_NAME before retrying in another region: # the failed attempt keeps holding the old name az group create --name "$RG_NAME" --location "$LOC" az sql server create --name "$SERVER_NAME" \ --resource-group "$RG_NAME" --location "$LOC" \ --enable-ad-only-auth \ --external-admin-principal-type User \ --external-admin-name "$AZ_USER_UPN" \ --external-admin-sid "$AZ_USER_ID" az sql db create --name lab-db --server "$SERVER_NAME" \ --resource-group "$RG_NAME" \ --edition GeneralPurpose --compute-model Serverless \ --family Gen5 --capacity 2 --auto-pause-delay 60
What to notice: the logical server groups database authentication and network settings; it is not a VM you patch. General Purpose serverless charges for compute while active and storage throughout. Auto-pause is possible after the configured idle time, but open sessions and some features can prevent it. No reusable administrator password appears in the lesson.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 and sign in. Before you run anything, read the three statements. SQL reads close to English:
CREATE TABLE orders (...)makes an empty table with three columns:id, a whole number that must be unique (PRIMARY KEY);item, text up to 50 characters; andplaced_at, a date and time the database fills in itself when you leave it out.INSERT INTO orders (id, item) VALUES (1, 'Alpine 7 boot')adds one row, giving values only for the two columns you name.SELECT * FROM ordersreads every column of every row back.
Predict what the result grid will show, then run all three:
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;
Checkpoint: one row: 1 · Alpine 7 boot · today's date and time. Run the whole block again and it stops at CREATE TABLE, because the table already exists. Run only the INSERT line again and it fails with a primary-key violation, because id 1 is taken. Both errors are the database keeping its promises. On your own: insert order 2 for a different item, then change the last line to SELECT item FROM orders WHERE id = 2; and predict the single value it returns. What to notice: the firewall must allow your current client address before a public query-editor connection works. Keep the rule narrow. A production private endpoint also needs private DNS and access policy; it is a separate network design, not just a replacement checkbox.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: Azure configures automatic full, differential and log backups. Check the displayed retention and earliest restorable time. A new database needs its initial full and subsequent log backup before point-in-time restore becomes available; do not assume it is ready immediately.After the portal shows an earliest restorable time, optionally restore to a new database named lab-db-restored. Check that the row exists and record the recovery-point time and total restore duration. Then delete the lab-only resource group and confirm it is gone:
az group delete --name "$RG_NAME" --yes az group exists --name "$RG_NAME"
The lesson: the restore makes a new database. Its elapsed time is a measurement for this tiny test database, not the full application RTO. The selected point's age describes this restore; it does not prove that every future incident loses only a few minutes of data. The final command should return false.
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 a geo-secondary to survive a lost region. Check replication lag and who authorizes failover. What happens to writes accepted just before the outage, and how will the application reconnect?
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.
A restore you have actually timed
A stateless service can be rebuilt from a template; the database holding every order needs recoverable data. Set RPO and RTO targets with the business. Then rehearse a point-in-time restore and application reconnection, record the selected recovery point and elapsed downtime, and compare those measurements with the targets. Entra-only authentication and a private endpoint address access, not recovery.
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 configured by the service, but PITR becomes available only after the initial backup sequence — the lab made you verify the earliest restorable time. 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.
C — the requirement is named in Table 2's own words. "Read your own writes" is the session guarantee, exactly: the caller who just wrote sees it on their next read, while another shopper's copy is allowed to lag by a beat — which is fine, because nobody asked for that. Session is the default most applications keep for precisely this reason: it delivers the one guarantee people actually notice missing (my own edit disappeared) without charging the whole system strong's global-ordering price.
A is correct but overpriced: strong gives every reader everywhere the same instant "now," which is more than this requirement asks for, and it is the level that fights hardest against multi-region writes and latency. B solves a different problem — a written bound on staleness for reads that are not tied to one caller's session, like a leaderboard that may trail by five seconds but never five minutes; there is no session tied to it here. D drops the one guarantee the requirement explicitly needs — a shopper could refresh and briefly not see their own edit, which is the bug being asked to prevent, not a cost worth paying to avoid it. Choosing a consistency level is choosing whose complaint you are willing to receive; here, only one caller's complaint (their own missing edit) is in scope, and session is the cheapest level that rules it out.
# 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 a second region, 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 is to keep both mechanisms: use point-in-time restore for bad writes and a failover group for regional loss. Retention is the length of history available for restore; it is not the RPO. Set data-loss and downtime targets with the business, then test each recovery path against them. The other lines are reasonable starting choices, but serverless wake-up, private DNS, retry safety and full checkout recovery still need testing.
Start with the evidence. Four years of uptime and a working backup job matter. Ask when that job last produced a usable copy and when the team last restored it. A nightly schedule alone does not define the business RPO, and an unmeasured rebuild does not establish the RTO. Compare the VM’s patching, compatibility and recovery work with the proposed managed service, including migration risk and cost. Rehearse a copy migration, application cutover and rollback before making the change.
Migration itself can fail, so keep the current service available during a rehearsed cutover and confirm that the application can return to it if the new path fails. Document any SQL Server features the application uses and test them on Azure SQL Database. Use measured restore and failover exercises, not a tier name, to decide whether the new design meets the business targets.
The operations lead still has critical work: define recovery targets, review access, verify backups, run restores and failover drills, and watch the application during maintenance. The role shifts from maintaining a VM to proving that the data and customer workflow can recover.
Start with the workload. The existing orders application uses T-SQL, joins across order and customer tables, and transactions for related changes. Azure SQL Database preserves that model with less migration work. Cosmos DB can support transactions within one logical partition key, so the design question is whether all required changes share that boundary and whether query rewrites, partition choice and data migration are justified. A payment provider is outside either database transaction; use idempotent payment requests and reconciliation to handle a partial checkout. Regional reads alone do not settle the engine choice: both systems can be designed to serve readers in more than one region.
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 has three management levels: SQL Database for a managed database, Managed Instance when instance features matter, and SQL Server on a VM when OS and engine control are required. Compare vCore and DTU pricing; test General Purpose serverless for intermittent workloads.
- 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 helps with bad writes by creating a new database; rehearse both paths and compare the measured recovery with agreed targets.
- Use Entra authentication and least privilege; combine a private endpoint with private DNS and an explicit public-access setting. Retry temporary faults with limits, and make writes idempotent.
- 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: automatic backup scheduling begins with the database, but the earliest restorable time appears only after the initial backup sequence; restore targets a new database rather than overwriting. Treat specific day-counts on this page with suspicion; treat the contract as settled. ↩
- Microsoft's connection guidance explains transient faults and retry design. Use timeouts and backoff; verify whether a write committed before repeating it. ↩
Choose between Azure SQL, Managed Instance, SQL on a VM and Cosmos DB, and say what each costs you in operations.
Play the lesson above to stamp this class.