About this wiki

A practical field guide for Microsoft engineers working on Azure SQL, SQL Server, Azure data platform, and AI services — combining certification prep, real-world engineering judgement, and reusable customer conversation support.

Why this wiki exists

Most product documentation tells you what a service does. This wiki tells you when to use it, what to watch for, and what to say to a customer — in language you can paste into an email or a whiteboard the same day.

Every page is written to be:

• Short enough to read between meetings
• Concrete enough to act on
• Safe enough to share externally (no internal-only material, no customer data)
• Honest about trade-offs (no "best practice" without context)

Who this is for

You are…	You'll use this for…
A Cloud Solution Architect (CSA / DCSA)	Customer architecture conversations, decision matrices, talking points
A field engineer studying DP-300 / DP-203 / AI-102	Concept revision, flashcards, exam-trap notes
An Oracle / on-prem DBA moving to Azure	Side-by-side mappings, equivalent feature tables
A partner or new hire onboarding	A curated reading order instead of 200 Microsoft Learn tabs

If you maintain production databases or talk to customers about them, you're the audience.

What belongs here

Type	Examples
Concept pages	Service tier comparison, HADR options, Query Store internals
Decision guides	"When to choose Hyperscale", "Pool vs single DB"
Architecture playbooks	Migration patterns, multi-region designs, AI-on-data
Customer-facing aids	Discovery questions, objection handling, talking points
Cert prep	DP-300 / DP-203 / AI-102 study notes, flashcards, exam traps
Labs	Repeatable, scripted, cleanup-included
Oracle parallels	Side-by-side feature mapping for migrating DBAs

What does NOT belong here

• ❌ Customer data, names, or identifiable account details. Use Contoso, Fabrikam.
• ❌ Microsoft-confidential roadmap or internal-only material. If it can't be public, it can't be here.
• ❌ Marketing copy. "Industry-leading", "seamless", "easy" — strip them.
• ❌ Pure link dumps. Add framing or comparison; otherwise extend an existing page instead of creating a new one.
• ❌ Long-form opinion pieces. Trade-off discussion is welcome; soapboxing is not.
• ❌ Duplicates. Search the wiki first.
• ❌ Anything you couldn't defend in a customer meeting.

Content types and examples

Type	Shape	Example
Concept	Theory + diagram + Oracle parallel + flashcards	Query Store internals
Decision guide	Comparison table + "Pick X if…" summary	GP vs BC vs Hyperscale
Playbook	Steps + decision points + customer-conversation aids	On-prem SQL → Azure migration
Cheatsheet	Dense table or command reference	T-SQL DMVs for performance
Lab	Prereqs → steps → verification → cleanup	Cross-region AlwaysOn
Customer aid	Discovery questions + talking points + objection responses	Why Azure SQL vs RDS

How to write pages that are useful in the field

A page is useful in the field when it does at least one of:

1. Shortens a decision — comparison table the reader can act on today
2. Prevents a mistake — "common pitfalls" section names a real failure mode
3. Frames a customer conversation — discovery questions or whiteboard sketch
4. Closes a knowledge gap fast — single page replaces five Microsoft Learn tabs
5. Provides a copy-paste asset — Bicep, T-SQL, CLI, or a talking point

Pages that do none of these are reference articles — write them only if Microsoft Learn doesn't cover them well.

Before you commit a paragraph, ask:

• Can I cut this sentence in half? Do it.
• Is there a number, name, or limit I can add? Add it.
• Would a customer-safe version of this work? If not, rewrite for one that does.
• Am I hiding behind "it depends"? Surface the trade-off instead.

Standard page anatomy

Every content page should have, in this order:

1. Frontmatter — see Frontmatter standard
2. One-paragraph intro — what this page covers, who should read it
3. Concept / theory — the "what" and "why"
4. Architecture diagram (Mermaid preferred) — when relevant
5. Decision matrix or comparison table — when there are options
6. Practical examples — code, T-SQL, CLI, Bicep
7. Oracle parallel — <TipBox type="oracle-parallel"> whenever applicable
8. Customer conversation aids — for audience: customer-facing pages
9. Common pitfalls / exam traps
10. Flashcards — at least 3, for spaced repetition
11. References — official Microsoft Learn links

The full template lives at pages-template.mdx — copy it as your starting skeleton.

Suggested metadata / frontmatter

Every page must include a small set of required fields. The full specification is in the Frontmatter standard section of the style guide. Minimum example:

---
title: Choosing an Azure SQL service tier
description: Decision guide for GP vs BC vs Hyperscale — trade-offs, sizing, and customer talking points.
sidebar_position: 3
last_reviewed: 2026-04-24
domain: azure-services
status: stable
tags: [azure-sql, decision-guide, performance, cost]
audience: [field-engineer, customer-facing]
---

How customer work benefits

• Pre-meeting prep — open one page per topic, not ten Learn articles
• Whiteboard support — every architecture page has a Mermaid diagram you can sketch from
• Decision defence — comparison tables explain why you recommended Hyperscale over Business Critical
• Reusable assets — talking points, discovery questions, and migration checklists are already written
• Knowledge handover — point new team members at a curated track, not a folder of PDFs

How to contribute

The shortest path:

1. Read CONTRIBUTING.md (5 minutes)
2. Read STYLE_GUIDE.md (5 minutes)
3. Copy pages-template.mdx as your starting skeleton
4. Open a PR — the template checklist tells the reviewer what to look for

If you only have time for one rule: write the page you wish you'd had three months ago.

Next recommended content (gap list)

Top priorities the wiki is missing today, ranked by field utility:

1. Choosing an Azure SQL service tier (GP / BC / Hyperscale) — azure-services/
2. Azure SQL HADR decision guide — failover groups vs geo-replication vs AGs vs MI failover groups
3. Azure SQL security baseline — TDE, Defender for SQL, Entra auth, Private Link, auditing
4. Performance triage runbook — Query Store → wait stats → Intelligent Insights → DMVs
5. Migration patterns: on-prem SQL → Azure — lift, MI, refactor, modernise
6. AI on your data: RAG + Azure SQL + AI Foundry
7. Customer discovery questions for data platforms
8. Objection handling — "we're already on AWS RDS", "we'll stay on Oracle", "Postgres is good enough"
9. Cost optimization for Azure data services — DTU vs vCore, reserved capacity, Hyperscale storage, dev/test, auto-pause
10. Glossary — MSX, MCEM, ACR, TPID, BC, HS, FRA, ACO, AFO, MACC, EA, RRP

House rules

• No customer data. Ever.
• No internal-only links. Summarise instead.
• Cite Microsoft Learn when you assert a fact about a service.
• Date your opinions. Use last_reviewed — Azure changes fast.
• Disagree in PRs, not in pages. Pages are the consensus view; nuance lives in commit messages.

---

Maintained by the field team. See CODEOWNERS for current owners. File issues using the page error or new page request templates.