Azure Well-Architected Framework & Cloud Adoption Framework for Databases
Why WAF & CAF Matter for DP-300
DP-300 tests database-specific decisions within the broader Azure architecture context. WAF tells you how to build it right, CAF tells you how to get there.
Azure Well-Architected Framework — The 5 Pillars for Databases
Pillar 1: Reliability
Goal: Database can withstand failures and recover within acceptable RTO/RPO.
| Reliability Checklist | Azure SQL DB | MI | SQL VM |
|---|---|---|---|
| Automated backups | ✅ Built-in | ✅ Built-in | ✅ With IaaS Agent |
| Zone redundancy | ✅ GP + BC | ✅ GP + BC | Via Availability Zones |
| Cross-region DR | Failover Groups | Failover Groups | AG async replica |
| Auto failover | ✅ Failover Groups | ✅ Failover Groups | ✅ AG + WSFC |
| Connection retry logic | Required in app | Required in app | Required in app |
Reliability on exam: "Design for failure" — always implement connection retry logic with exponential backoff. Transient faults are expected in Azure SQL. Use SqlConnection with ConnectRetryCount and ConnectRetryInterval.
Pillar 2: Security
Goal: Protect data at rest, in transit, and in use. Least-privilege access.
| Security Checkpoint | Best Practice | Anti-Pattern |
|---|---|---|
| Network | Private Endpoint + disable public access | Allow all Azure services (0.0.0.0) |
| Authentication | Entra ID + Managed Identity | SQL auth with passwords in code |
| Authorization | Least privilege, custom roles | db_owner for all users |
| Encryption at rest | TDE (default) + BYOK for compliance | Disable TDE |
| Encryption in transit | TLS 1.2 enforced | Allow TLS 1.0 |
| Sensitive data | Always Encrypted for PII | Store PII in plaintext |
| Auditing | Log Analytics + Storage | Auditing disabled |
Pillar 3: Cost Optimization
Goal: Maximize value, minimize waste.
| Strategy | Savings | When to Use |
|---|---|---|
| Azure Hybrid Benefit | Up to 55% | You have SQL Server licenses with SA |
| AHB + Reserved (3yr) | Up to 80% | Long-term production workloads |
| Serverless | Pay only when active | Dev/test, intermittent workloads |
| Elastic Pools | 30-60% vs individual DBs | Multi-tenant SaaS |
| Right-sizing | 20-50% | Over-provisioned databases |
| GP instead of BC | ~50-60% | When < 2ms latency isn't needed |
Exam cost questions: "Minimize cost for a database that's idle 18 hours/day" → Serverless. "Existing SQL licenses" → AHB + vCore. "50 tenant databases with variable load" → Elastic Pool. "Long-term production" → Reserved Capacity.
Pillar 4: Performance Efficiency
Goal: Right resources for the workload, scale efficiently.
| Performance Decision | Options | Decision Factor |
|---|---|---|
| Compute model | DTU vs vCore, Provisioned vs Serverless | Predictable vs variable workload |
| Service tier | GP vs BC vs Hyperscale | Latency requirements, DB size |
| Read scale | BC read replica, Geo-rep secondary, Named replica | Offload reporting/analytics |
| Caching | Azure Cache for Redis | Hot data, session state |
| Indexing | Automatic tuning, manual design | Query patterns |
| Partitioning | Table partitioning, sharding | Very large tables (100M+ rows) |
Pillar 5: Operational Excellence
Goal: Automate operations, monitor proactively, respond to incidents.
Oracle DBA parallel: WAF Operational Excellence = your Oracle ITIL practices (change management, incident management, capacity planning) translated to Azure-native tools. IaC replaces manual portal clicks. CI/CD for schema = Oracle Liquibase/Flyway. Monitoring = OEM → Azure Monitor.
Cloud Adoption Framework — Database Migration Journey
The 7 Phases
Phase 1: Strategy — Define Motivations
| Motivation | Database Impact |
|---|---|
| Cost savings | Eliminate Oracle/SQL licensing costs → Azure PaaS |
| Data center exit | All databases must migrate → assess MI vs SQL DB vs VM |
| End of support | SQL 2012/2014 → migrate for security patches |
| Performance | On-prem hardware limits → Azure elastic scaling |
| Innovation | AI/ML capabilities, vector search, Copilot integration |
Phase 2: Plan — Assess & Prioritize
Wave planning strategy:
- Wave 1: Dev/test, non-critical databases (learn the process)
- Wave 2: Standard production databases (MI lift-and-shift)
- Wave 3: Complex databases with dependencies (custom migration)
- Wave 4: Mission-critical databases (last, with proven playbook)
Phase 3: Ready — Landing Zone
A landing zone is the pre-configured Azure environment databases land in.
Landing zone essentials for databases: 1) VNet with dedicated MI subnet (/27+) and PE subnet. 2) Key Vault for secrets/keys. 3) Log Analytics for monitoring. 4) Azure Policy to enforce security baselines (TDE on, auditing on, min TLS 1.2).
Phase 4: Migrate — Execute
See the Migration Strategy page for detailed migration methods (DMS, MI Link, LRS, BACPAC).
Phase 5: Innovate — Modernize
| Innovation | What It Means |
|---|---|
| PaaS migration | SQL VM → MI or SQL DB (reduce management overhead) |
| AI integration | Add vector search, Copilot, Azure OpenAI to SQL workloads |
| Real-time analytics | Add Synapse Link or Fabric mirroring |
| Event-driven | CDC → Event Hub → real-time processing |
| Global distribution | Failover Groups + read replicas across regions |
Phase 6: Govern — Policies & Compliance
| Governance Control | Azure Implementation |
|---|---|
| Enforce encryption | Azure Policy: TDE must be enabled |
| Enforce auditing | Azure Policy: Auditing must be enabled |
| Enforce network security | Policy: Public access disabled, PE required |
| Cost management | Budgets + Cost Management alerts |
| Naming convention | Policy: Require tags, naming pattern |
| Data classification | Purview: Auto-classify sensitive data |
| Compliance | Defender for SQL: Vulnerability Assessment |
Phase 7: Manage — Ongoing Operations
| Operations Area | Tools |
|---|---|
| Monitoring | Azure Monitor, Query Store, Intelligent Insights |
| Backup/Restore | Automated backups, LTR, geo-restore |
| Patching | Automatic (PaaS) or Update Management (VM) |
| Performance | Automatic tuning, index maintenance, stats |
| Security | Defender scans, audit reviews, access reviews |
| Cost | Advisor recommendations, Reserved Capacity |
| Incident response | Action Groups → email/SMS/Teams/PagerDuty |
WAF Assessment for Azure SQL — Quick Checklist
Use this checklist to score your database deployment against WAF pillars:
| # | Check | Pillar | Status |
|---|---|---|---|
| 1 | Zone-redundant deployment enabled? | Reliability | ☐ |
| 2 | Cross-region DR (Failover Group or Geo-Rep)? | Reliability | ☐ |
| 3 | Connection retry logic in application? | Reliability | ☐ |
| 4 | Backup retention configured (7-35 days)? | Reliability | ☐ |
| 5 | LTR configured for compliance? | Reliability | ☐ |
| 6 | Private Endpoint enabled, public access disabled? | Security | ☐ |
| 7 | Entra ID authentication (no SQL auth)? | Security | ☐ |
| 8 | TDE enabled with BYOK? | Security | ☐ |
| 9 | Auditing → Log Analytics? | Security | ☐ |
| 10 | Defender for SQL enabled? | Security | ☐ |
| 11 | Data classified (PII labeled)? | Security | ☐ |
| 12 | Azure Hybrid Benefit applied? | Cost | ☐ |
| 13 | Reserved Capacity for production? | Cost | ☐ |
| 14 | Serverless for dev/test? | Cost | ☐ |
| 15 | Right-sized (not over-provisioned)? | Cost | ☐ |
| 16 | Query Store enabled and reviewed? | Performance | ☐ |
| 17 | Automatic tuning on? | Performance | ☐ |
| 18 | Index maintenance scheduled? | Performance | ☐ |
| 19 | Statistics up to date? | Performance | ☐ |
| 20 | Infrastructure as Code (Bicep/Terraform)? | Operations | ☐ |
| 21 | CI/CD for schema changes? | Operations | ☐ |
| 22 | Alert rules configured? | Operations | ☐ |
| 23 | Tags applied (env, owner, cost center)? | Operations | ☐ |
| 24 | Maintenance window configured? | Operations | ☐ |
Use this checklist with your DCSA customers. Walk through it during discovery calls — it immediately surfaces gaps and creates action items. Customers respect structured assessments over ad-hoc recommendations.