Azure SQL administration is not simply about writing T-SQL or managing databases.
The deeper architectural challenge is understanding how compute, storage, networking, security, performance, availability, and disaster recovery interact across Azure SQL services.
For DP-300, the goal is to understand the architecture behind the administrative decisions.
1. The Azure SQL Architecture Landscape
Azure provides several ways to run SQL workloads:
Azure
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Azure SQL Managed SQL Server
Database Instance on Azure VM
│ │ │
└─────────────┼─────────────┘
▼
SQL Workloads
The architectural decision depends on how much control the workload requires.
Azure SQL Database is a highly managed PaaS database service.
Azure SQL Managed Instance provides broader SQL Server compatibility while retaining many PaaS management benefits.
SQL Server on Azure Virtual Machines provides the greatest infrastructure-level control because the SQL Server engine runs inside a customer-managed VM.
The DP-300 architecture question is therefore often:
How much database and infrastructure control does the workload actually require?
Microsoft's current DP-300 study guide explicitly covers Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VMs, and on-premises SQL Server.
2. Azure SQL Database: Managed Architecture
A simplified Azure SQL Database architecture looks like this:
Application
│
▼
Network / Private Endpoint
│
▼
Azure SQL Database
│
├── Compute
├── Database Engine
├── Storage
├── Backups
└── Replication
The important architectural difference from traditional SQL Server is that Microsoft manages many infrastructure operations.
Azure SQL Database automatically handles tasks such as patching, backups, upgrades, and infrastructure failure recovery.
Therefore, the administrator spends less time managing operating-system infrastructure and more time managing:
- database configuration
- security
- performance
- availability
- backup and recovery
- workload optimization
This is the fundamental PaaS operating model.
3. Compute and Storage
A key architectural concept in Azure SQL is the relationship between compute and storage.
Application
│
▼
SQL Engine
│
┌─────┴─────┐
▼ ▼
Compute Storage
│ │
└─────┬─────┘
▼
Persistent Data
Compute handles query execution, transactions, memory usage, and database engine processing.
Storage provides persistence for database data.
Different Azure SQL architectures use these resources differently.
This distinction becomes especially important when evaluating performance, scaling, availability, and service tiers.
4. Hyperscale: Separating Compute from Storage
Hyperscale provides a more distributed architecture.
Application
│
▼
Compute Node
│
┌────────────┼────────────┐
▼ ▼ ▼
Page Server Log Service Replicas
│
▼
Azure Storage
Instead of relying on one traditional database engine process to manage everything, Hyperscale separates query processing from components responsible for storage and durability.
Microsoft describes the architecture as separate compute and storage components, with page servers, a log service, and high-availability replicas.
This architecture allows workloads to scale compute independently from the underlying data storage.
It also explains why Hyperscale can provide fast scaling, read scale-out, and rapid backup/restore capabilities.
5. Security Is a Layered Architecture
Database security should not be treated as a single feature.
A typical Azure SQL security architecture looks like:
Network
│
▼
Firewall / Private Link
│
▼
Authentication
│
▼
Authorization
│
▼
Database Permissions
│
▼
Data Protection
Different layers solve different problems.
For example:
- Microsoft Entra ID → identity and authentication
- Firewall / Private Link → network access control
- Database roles and permissions → authorization
- TDE → encryption at rest
- Always Encrypted → protection of sensitive column data
- Row-Level Security → restricting rows returned to users
- Dynamic Data Masking → limiting exposure of sensitive values
- Auditing → recording database activity
The current DP-300 objectives explicitly include Microsoft Entra authentication, least privilege, TDE, Always Encrypted, Private Link, auditing, dynamic data masking, and row-level security.
The architectural principle is:
Identity, network, database permissions, and data protection should work together rather than replace one another.
6. Performance Architecture
Database performance is not controlled by one setting.
A simplified performance pipeline is:
Application
│
▼
Connection
│
▼
Query
│
▼
Execution Plan
│
▼
CPU / Memory / I/O
│
▼
Storage
DP-300 administrators need to understand where bottlenecks originate.
For example:
High CPU
→ Query execution / inefficient queries
High I/O
→ Storage access / indexing / data volume
Blocking
→ Transaction and locking behavior
Poor query plan
→ Statistics / indexes / query structure
Resource saturation
→ Workload exceeds current capacity
Tools such as Query Store, Dynamic Management Views, Extended Events, execution plans, and Intelligent Insights help identify the actual source of performance problems.
The important point is that performance tuning should begin with measurement, not configuration changes.
7. High Availability vs. Disaster Recovery
These concepts are related but architecturally different.
Database
│
┌──────────┴──────────┐
▼ ▼
High Availability Disaster Recovery
│ │
Local / Zone Regional
Resilience Resilience
│ │
▼ ▼
Zone Redundancy Geo-Replication
Failover Groups
Geo-Restore
High availability protects against failures within the primary environment.
Disaster recovery protects against larger failures such as regional outages.
Azure SQL Database can use zone redundancy for resilience against availability-zone failures, while geo-replication and failover groups can provide regional disaster-recovery capabilities.
This distinction becomes critical when designing around:
- RTO — Recovery Time Objective
- RPO — Recovery Point Objective
The architecture should be selected according to business recovery requirements rather than simply enabling every available feature.
8. Backup and Recovery Architecture
Backup is another layer of the reliability model.
Azure SQL
│
┌─────────┴─────────┐
▼ ▼
Point-in-Time Geo-Restore
Restore │
│ │
▼ ▼
Human Error Recovery Regional Recovery
Point-in-time restore is particularly useful for accidental data changes or deletion.
Geo-restore is designed for recovering databases into another Azure region when regional recovery is required.
Azure SQL Database provides automated backups, while retention and redundancy options should be designed around the application's recovery requirements.
9. Automation Is Part of Database Architecture
Modern database administration should not depend entirely on manual operations.
A practical architecture can look like:
Infrastructure as Code
│
▼
Database Deployment
│
▼
Configuration
│
▼
Monitoring
│
▼
Alerts
│
▼
Automated Response
Automation can be applied to:
- database deployment
- schema changes
- configuration
- backups
- monitoring
- maintenance
- scaling
- administrative tasks
This is why DP-300 includes automation as a dedicated skill area rather than treating it as an optional operational technique.
10. The DP-300 Architecture Mental Model
A useful way to understand the entire certification is:
Application
│
▼
Network / Identity
│
▼
┌─────────────────┐
│ Azure SQL │
│ Service │
└────────┬────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Compute Storage Security
│ │ │
└───────────────┼───────────────┘
▼
Performance
│
┌──────────┴──────────┐
▼ ▼
HA / Zone DR / Geo
Redundancy Recovery
│ │
└──────────┬──────────┘
▼
Operations
& Automation
The central idea is simple:
DP-300 is fundamentally about operating SQL workloads reliably, securely, and efficiently across Azure.
Once the relationship between compute, storage, security, performance, availability, recovery, and automation is clear, individual Azure SQL features become much easier to understand.
Top comments (0)