DP-300 implementation playbook

This page walks every sub-topic in the official Microsoft Learn DP-300 Exam Readiness Zone (Sara El Sayed, FY25) and turns each one into ordered, platform-aware implementation steps. The exam tests what you would do and in what order; this page gives you that map for Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VM, and SQL Server (box / on-prem).

🧠 How to read this page

Each sub-topic has one table. Rows are the mandatory steps. Columns are the platforms. If a cell says n/a the platform doesn't expose that capability; if it says "same as <X>" the platform inherits the steps from the column on its left. Skip commands — the exam asks for the sequence, not the syntax.

Domain map and weights

#	Domain	Weight	Sub-topics
1	Plan and implement data platform resources	20–25%	1.1 deploy · 1.2 scale · 1.3 migrate
2	Implement a secure environment	15–20%	2.1 authN / authZ · 2.2 data protection · 2.3 compliance
3	Monitor, configure, and optimize	20–25%	3.1 resource monitoring · 3.2 query tuning · 3.3 db config
4	Configure and manage automation	15–20%	4.1 Agent jobs · 4.2 deployment · 4.3 Azure-side tasks
5	Plan and configure HA/DR	20–25%	5.1 strategy · 5.2 backup/restore · 5.3 configure

The five domains map 1:1 to Sara's five Exam Readiness Zone episodes. The sub-topic numbering below matches the official chapter markers.

---

Domain 1 — Plan and implement data platform resources

1.1 Plan and deploy Azure SQL database solutions

Reflex: pick the platform first, then the purchase model, then the service tier, then the deployment shape, then provision.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Confirm requirement fits PaaS DB scope (single DB or pool)	Confirm requirement needs instance features (SQL Agent, cross-db, CLR, Service Broker)	Confirm requirement needs OS / SQL feature not in PaaS	Confirm on-prem is required (data residency, hardware control)
2	Pick DTU or vCore purchase model	vCore only	Pick VM family (DSv5/Eds/Mds) and storage class	Size hardware + storage RAID
3	Pick service tier — General Purpose, Business Critical, or Hyperscale	Pick GP, BC, or Next-gen GP; pick hardware generation	Pick marketplace SQL image (preferred) or BYOL	Pick edition (Standard / Enterprise / Developer)
4	Pick deployment shape — single DB, elastic pool, serverless	Provision into a dedicated subnet of a VNet (delegated to MI)	Provision VM + register with SQL IaaS Agent extension (full mode)	Install Windows/Linux + latest CU
5	Create the logical server (admin login, region, AAD admin)	Pick proxy or redirect connection type	Configure storage pools — data, log, tempdb on separate disks	Configure instance — tempdb files, max server memory, MAXDOP
6	Configure server-level firewall, AAD admin, optional private endpoint	Configure NSG, route table, optional public endpoint	Apply patching mode + automated backup via the IaaS extension	Configure SQL Agent, Database Mail, default backup paths
7	Create the database; choose collation, backup storage redundancy	Create databases inside the instance	Restore / attach database	Create database with appropriate recovery model

🎯 Exam Focus

Exam trap: "needs SQL Agent" or "cross-database queries" → never Azure SQL Database. Default to Managed Instance before reaching for SQL VM.

1.2 Configure resources for scale and performance

Reflex: match the scaling axis the question describes (compute, storage, replicas, regions) to the feature the platform actually exposes.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Identify scaling axis — vCore, storage, replicas, regions, bursts	Same	Same	Same
2	Choose shape — single / elastic pool / serverless / Hyperscale	Choose single instance or instance pool (preview where available)	Resize VM SKU (compute) independently of disks	Add cores / memory; relicense if needed
3	Scale compute by changing vCore / DTU (online)	Scale vCore (online); storage scales independently in GP	Add or resize premium / ultra / Premium SSD v2 disks; restripe pools	Add storage; rebalance filegroups
4	Enable read scale-out on BC / Hyperscale	Enable read-only replica on BC	Use Always On AG with read-only routing	Same as SQL VM
5	Add Hyperscale named replicas for read isolation	n/a	Add AG secondary replicas	Add AG secondary replicas
6	Use auto-pause + auto-resume on serverless for spiky low workloads	n/a	Use VM start/stop schedules for non-prod	n/a
7	Tune at DB scope — automatic tuning, MAXDOP, compatibility level	Tune at instance + DB scope	Tune OS + SQL — tempdb files per core, Lock Pages in Memory, IFI	Same as SQL VM

🎯 Exam Focus

Exam trap: Hyperscale is the answer when the database is large (>4 TB), needs fast restore, or needs many read replicas. It is not the answer when the requirement says in-memory OLTP — that is Business Critical only.

1.3 Plan and implement a migration strategy

Reflex: pick the target first (DB vs MI vs VM), assess with Azure Migrate / Data Migration Assistant, then pick online vs offline based on RPO and downtime tolerance.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box, as target)
1	Run Data Migration Assistant (DMA) for compatibility issues	Run Azure Migrate: Database Assessment (formerly DMA) targeting MI	Run DMA targeting SQL Server on Azure VM	DMA against target version
2	Fix blockers — unsupported features, deprecated syntax	Fix MI-specific blockers (e.g., trace flags, CLR if disabled)	Fix only true blockers; SQL VM accepts most features	Fix breaking changes between versions
3	Choose DMS (Azure Database Migration Service) online or offline	Choose DMS (online via Log Replay Service for native backups, or Managed Instance link)	Choose DMS, backup/restore, or distributed AG	Backup/restore or detach/attach
4	Pre-create target server + DB; validate networking	Pre-create instance + verify VNet line-of-sight to source	Pre-create VM + storage; install matching SQL version	Pre-create instance
5	Run schema migration (DMA or DACPAC)	Run schema as part of backup restore	Restore full + diff + log chain	Same
6	Start data migration — DMS online uses CDC; offline uses bulk copy	Run continuous backup replay (LRS) or seed via MI link	Apply log backups until cutover	Apply log chain until cutover
7	Cutover — switch connection strings, verify users / logins, sync orphaned users	Cutover — repoint apps; failover MI link if used	Cutover — break log chain, redirect apps	Same

🎯 Exam Focus

Exam trap: if the question requires minimum downtime to Managed Instance with near-zero RPO, the answer is Managed Instance link (or DMS online with LRS) — not offline backup/restore.

---

Domain 2 — Implement a secure environment

2.1 Configure database authentication and authorization

Reflex: authN = who (logins, users, AAD), authZ = what (roles, GRANT, RLS). Prefer Microsoft Entra ID identities over SQL logins on every Azure platform.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Set an Entra ID admin on the logical server	Set Entra ID admin on the instance	Configure Entra ID authentication via Azure extension; join VM	Configure Windows / AD integration
2	Create contained database users mapped to Entra identities (preferred)	Create Entra logins at instance scope, users at DB scope	Create AD-integrated logins; map DB users	Same
3	Disable / rotate the server admin SQL login; use it only for break-glass	Same	Use AD groups for DBAs; rotate sa and disable where possible	Same
4	Grant via fixed database roles first, custom roles second	Same; instance also has server roles	Same; full server-role surface	Same
5	Apply Row-Level Security (RLS) for tenant isolation	Same	Same	Same
6	Apply Dynamic Data Masking for low-privilege users	Same	Same	Same
7	Audit access — server / DB audit to Log Analytics or Storage	Same	Configure auditing via SQL Server Audit or SQL IaaS extension	SQL Server Audit

🔀 Oracle → Azure

Oracle parallel: SQL contained DB users behind Entra ID map to enterprise users with an external identity store. Server roles are SQL's equivalent of Oracle system privileges; fixed DB roles map to common Oracle object privilege bundles.

2.2 Implement security for data at rest and data in transit

Reflex: at rest = TDE (+ optional Always Encrypted), in transit = TLS + private network path. Customer-managed keys (CMK) live in Azure Key Vault (or Managed HSM).

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	TDE is on by default with service-managed key	Same	Enable TDE on each user database	Enable TDE (Enterprise / Developer; Standard for newer versions)
2	Optionally switch to TDE with CMK in Azure Key Vault	Same	Use EKM provider + Azure Key Vault for CMK	Use EKM + on-prem HSM / Key Vault
3	Enable Always Encrypted (with or without enclaves) for column-level secrets	Same	Same	Same
4	Enforce TLS 1.2 minimum on the logical server	Enforce on instance	Configure SQL Server to require encrypted connections; force protocol via SQL Server Configuration Manager	Same
5	Use private endpoint or service endpoint for app-to-DB traffic	Use VNet + optional public endpoint (disabled by default)	Use NSG + private IP only; deny public IP	Network segmentation via firewall / VLAN
6	Configure firewall rules at server and DB scope	n/a — network is VNet-scoped	NSG rules at subnet and NIC	Host / perimeter firewall
7	Rotate keys per policy; monitor with Defender for SQL	Same	Same	Same

🎯 Exam Focus

Exam trap: Always Encrypted protects data from the DBA. TDE does not — a DBA with db_owner can still read the data. If the scenario hides data from privileged users, the answer is Always Encrypted (use enclaves when comparisons / range queries are required).

2.3 Implement compliance controls for sensitive data

Reflex: classify → audit → detect → respond. The Azure toolset is Data Discovery & Classification → Auditing → Microsoft Defender for SQL → Purview.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Run Data Discovery & Classification to label columns	Same	Same (SSMS classification or Defender)	Same
2	Enable SQL Auditing to Log Analytics / Storage / Event Hub	Same	Configure SQL Server Audit; ship to Log Analytics via IaaS extension	SQL Server Audit
3	Enable Microsoft Defender for SQL (vulnerability assessment + threat detection)	Same	Defender for SQL on Azure VM via the SQL IaaS extension	n/a — use third-party / Defender for Servers
4	Schedule and review Vulnerability Assessment baselines	Same	Same	Run manual security best practice baselines
5	Wire alerts to Logic Apps / Teams / ticketing	Same	Same	SIEM integration
6	Use Dynamic Data Masking + RLS to enforce least exposure	Same	Same	Same
7	Register source in Microsoft Purview for governance and lineage	Same	Same	Same (Purview can scan box SQL)

🎯 Exam Focus

Exam trap: Defender for SQL is the answer for detection (anomalous logins, SQL injection patterns, exfiltration). Auditing is the answer for logging. They are not interchangeable.

---

Domain 3 — Monitor, configure, and optimize database resources

3.1 Monitor resource activity and performance

Reflex: Azure scope → SQL scope. Start in Azure Monitor / Database Watcher, then drop into DMVs / Query Store.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Open Azure Monitor metrics — CPU %, log IO %, data IO %, sessions	Same	Open VM-level metrics (CPU, disk IOPS, network) and SQL-level metrics	Use OS perfmon + SQL DMVs
2	Enable Database Watcher (preview-to-GA) for low-latency telemetry	Same	n/a — use SQL Insights or third-party	n/a
3	Stream diagnostic logs to Log Analytics workspace	Same	Use the SQL IaaS Agent extension to send logs	Forward logs to SIEM or Log Analytics agent
4	Configure metric alerts — static and dynamic thresholds	Same	Configure VM metric alerts + SQL Insights alerts	Use third-party monitoring
5	Use Intelligent Insights for AI-suggested issues	Same	n/a directly; use SQL Insights / Database Watcher	n/a
6	Drop into DMVs — sys.dm_exec_*, sys.dm_os_wait_stats	Same	Same	Same
7	Inspect Extended Events sessions for deep dives	Same	Same	Same

🔀 Oracle → Azure

Oracle parallel: Azure Monitor + Database Watcher ≈ Oracle Enterprise Manager / OEM. DMVs + Query Store ≈ AWR + ASH. Wait stats map almost 1:1.

3.2 Monitor and optimize query performance

Reflex: prove the cause with Query Store before you touch indexes. Plan regression is the most common "fast yesterday, slow today" scenario.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Confirm Query Store is on (default on Azure SQL)	Same	Enable Query Store per user database	Same
2	Find top regressed / top consumer queries in Query Store	Same	Same	Same
3	Inspect actual + estimated plans; compare versions over time	Same	Same	Same
4	Force a known good plan if the regression is plan-shape	Same	Same	Same
5	Review missing index DMV suggestions; validate before applying	Same	Same	Same
6	Update statistics; rebuild / reorganize only when fragmentation justifies it	Same	Same	Same
7	Test with automatic plan correction (Azure) or manual hints (box)	Auto plan correction available	Auto plan correction available	Manual hints / Query Store plan forcing

🎯 Exam Focus

Exam trap: the first answer for plan regression is force the last good plan in Query Store, not "rebuild indexes" and not "update statistics". Indexes and stats are downstream actions.

3.3 Configure database solutions for optimal performance

Reflex: configure the layer the bottleneck lives on — instance settings, database settings, storage layout, or workload isolation.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Set DB-scoped config — MAXDOP, parameter sniffing, legacy CE	Set at DB or instance scope	Set at instance + DB scope	Same
2	Set compatibility level appropriate to workload	Same	Same	Same
3	Configure tempdb — n/a as a knob (managed)	Tempdb is managed; pre-sized files per vCore	Configure tempdb files = logical cores (max 8) on local SSD	Same
4	Use in-memory OLTP on Business Critical for latch hotspots	Same	Same (Enterprise / Developer)	Same
5	Use columnstore for analytical workloads	Same	Same	Same
6	Use Resource Governor — n/a	Limited Resource Governor support	Full Resource Governor	Same
7	Enable automatic tuning — force last good plan, create / drop index	Same	Same	n/a (manual)

---

Domain 4 — Configure and manage automation of tasks

4.1 Create and manage SQL Server Agent jobs

Reflex: SQL Agent exists on Managed Instance, SQL VM, and box SQL Server. It does not exist on Azure SQL Database — use Elastic Jobs there.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Use Elastic Jobs (job agent + DB) — Agent is n/a	Enable SQL Server Agent on the instance	Enable SQL Server Agent service	Same
2	Create target group of databases / servers	Create job with steps (T-SQL, OS, replication)	Same	Same
3	Define job steps; pass credentials securely	Define operators + alerts; configure Database Mail	Same	Same
4	Schedule jobs; track history in the job database	Schedule jobs; review history	Same	Same
5	Wire failure alerts to Logic Apps / Event Grid	Wire alerts via Database Mail / Defender	Same	Same
6	Use Managed Identity where possible for auth	Use Entra-authenticated proxies where supported	Same	Use Windows service accounts
7	Audit / version control job definitions in source	Same	Same	Same

🎯 Exam Focus

Exam trap: "I need to run a T-SQL maintenance job across 200 Azure SQL Databases" → Elastic Jobs, not SQL Agent, not Logic Apps.

4.2 Automate deployment of database resources

Reflex: infrastructure with ARM / Bicep / Terraform, schema with DACPAC / SQL projects, end-to-end with pipelines.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Define logical server + DB in Bicep / ARM / Terraform	Define MI + VNet + subnet + delegation	Define VM + disks + extensions in Bicep	Use config management (DSC, Ansible) for OS / SQL install
2	Parameterize tier, vCore, backup redundancy	Parameterize tier, hardware generation, license type	Parameterize VM SKU, storage layout, SQL image	Parameterize install options
3	Build SQL project (SSDT / SQL Database Projects) → produce DACPAC	Same	Same	Same
4	Deploy DACPAC via Azure DevOps / GitHub Actions pipeline	Same	Same	Same
5	Run post-deployment scripts (idempotent)	Same	Same	Same
6	Gate environments — dev → test → prod with approvals	Same	Same	Same
7	Drift detection — compare schema vs source of truth	Same	Same	Same

🔀 Oracle → Azure

Oracle parallel: DACPAC / SQL projects are equivalent to Oracle schema migrations via Liquibase / Flyway. The contract is the same: declarative schema in source control, deployed by pipeline.

4.3 Create and manage database tasks in Azure

Reflex: if the task runs inside SQL, use Agent / Elastic Jobs. If it runs around SQL (start/stop, scale, orchestrate), use Automation runbooks, Logic Apps, Functions, or Data Factory.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Pick the right Azure runner — Elastic Jobs, Automation runbook, Logic App, Function, or Data Factory	Same	Same; also SQL Agent for in-engine tasks	n/a — orchestrate from on-prem scheduler
2	Use Managed Identity for the runner; grant least-privilege access to DB	Same	Same; or AD-authenticated SPN on the VM	Use service accounts
3	Store secrets in Azure Key Vault referenced by Managed Identity	Same	Same	Use on-prem secret store
4	Schedule via Logic Apps recurrence or Automation schedule	Same	Same	Use Windows Task Scheduler
5	Wire failure alerts to Action Groups → Teams / email / PagerDuty	Same	Same	Same via SIEM
6	Track runs and outputs in Log Analytics	Same	Same	Same
7	Version runbooks / Logic Apps in source control	Same	Same	Same

---

Domain 5 — Plan and configure HA/DR

5.1 Plan an HA/DR strategy for database solutions

Reflex: RPO → backup strategy, RTO → failover topology. Pick features in that order; never the other way around.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Capture business RPO + RTO; pick a tier whose built-in HA matches	Same	Same; HA is your responsibility (AG / FCI)	Same; HA is your responsibility
2	Pick service tier — GP (zone HA add-on), BC / Hyperscale (replica-based HA)	Pick GP or BC; BC has built-in zone-redundant replicas	Pick Always On AG, FCI, or log shipping as the HA topology	Same
3	Choose zone redundancy where available (BC, Hyperscale)	Choose zone redundancy on BC	Pick availability zones for VM placement	Pick rack / site diversity
4	For DR, pick failover group (single region pair)	Same; FG at instance scope	Build multi-region AG; consider Azure Site Recovery as a fallback	Build multi-site AG with shared witness
5	Decide on active geo-replication vs failover group based on app routing	Failover groups (geo-replication is for SQL DB only)	Define listener + read-only routing	Same
6	Define backup retention — short term + LTR for compliance	Same	Configure automated backup with the IaaS extension + LTR target	Configure backup to URL / file share with retention policy
7	Run game days — fail over, validate, fail back	Same	Same	Same

🎯 Exam Focus

Exam trap: active geo-replication is Azure SQL Database only. For MI, the equivalent is failover groups. SQL VM and box SQL Server use Always On Availability Groups.

5.2 Plan and perform backup and restore of a database

Reflex: PaaS backups are automatic (PITR + LTR); your job is to set retention, validate, and know the restore path. IaaS / box = you own everything.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Confirm automated backups + storage redundancy (LRS / ZRS / GRS)	Same	Configure automated backup to URL via SQL IaaS extension, or run native backups	Configure FULL / DIFF / LOG backup chain
2	Set PITR retention (1–35 days)	Same	Set retention on the chosen backup target	Set retention per policy
3	Configure Long-Term Retention (LTR) weekly / monthly / yearly	Same	Configure LTR target in storage; manage lifecycle	Manage tape / object retention
4	Test point-in-time restore to a new DB	Same; restore to the same or another instance	Restore from URL / disk; consider head-of-log restore	Same
5	Test geo-restore to a paired region	Same	Use cross-region restore from geo-redundant backups	Use offsite copies
6	Test restore from LTR	Same	Same	Same
7	Verify CHECKDB integrity after restore	Same (run on restored DB)	Same	Same

🎯 Exam Focus

Exam trap: PITR vs LTR — PITR is for operational recovery (oops-table within 35 days). LTR is for compliance (weekly / monthly / yearly retained for years). They are not substitutes for each other.

5.3 Configure HA/DR for database solutions

Reflex: pick exactly one primary HA mechanism per platform and configure its listener / endpoint, quorum / witness, and monitoring in that order.

Step	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
1	Pick zone-redundant deployment on BC / Hyperscale (HA) and failover group (DR)	Pick zone redundancy on BC (HA) + failover group (DR)	Pick Always On AG (HA + DR); cluster across zones / regions	Same; physical sites
2	Configure failover group — primary, secondary, listener endpoint	Same; instance-scoped listener endpoint	Configure WSFC + AG listener; pick cloud witness for quorum	Configure WSFC + AG listener; file share or disk witness
3	Choose read-write listener + read-only listener	Same	Configure read-only routing list	Same
4	Choose automatic or manual failover policy + grace period	Same	Configure availability mode — synchronous (HA) + asynchronous (DR)	Same
5	Validate endpoint redirection in app connection strings	Same	Validate that apps use the listener, not the node name	Same
6	Monitor with Azure Monitor + failover group health	Same	Monitor AG health via DMVs + Azure Monitor on the VM	DMVs + Windows / Linux cluster monitoring
7	Run a planned failover; verify app behavior and roll back	Same	Run manual failover (planned) and forced failover (DR drill)	Same

🔀 Oracle → Azure

Oracle parallel: Always On AG ≈ Oracle Data Guard. Synchronous AG ≈ maximum availability mode; asynchronous AG ≈ maximum performance mode. Failover group for Azure SQL DB / MI ≈ a managed, single-button Data Guard switchover at the listener layer.

---

Cross-platform decision matrix (one table to memorize)

Use this when the question reduces to "which platform supports it natively?".

Capability	Azure SQL Database	SQL Managed Instance	SQL Server on Azure VM	SQL Server (box)
SQL Server Agent	❌ (use Elastic Jobs)	✅	✅	✅
Cross-database queries	❌ (elastic query — limited)	✅	✅	✅
CLR / Service Broker	❌	✅	✅	✅
In-memory OLTP	✅ (BC only)	✅ (BC)	✅ (Enterprise / Developer)	✅
Hyperscale	✅	❌ (NextGen GP overlaps some scenarios)	❌	❌
Active geo-replication	✅	❌ (use failover groups)	❌ (use AG)	❌ (use AG)
Failover groups	✅	✅	❌	❌
Always On AG	❌	❌ (instance-internal HA only)	✅	✅
TDE (default on)	✅	✅	⚠️ enable per DB	⚠️ enable per DB
Always Encrypted	✅	✅	✅	✅
Built-in PITR (1–35 days)	✅	✅	❌ (build it)	❌ (build it)
LTR (weeks / months / years)	✅	✅	❌ (build it)	❌ (build it)
Microsoft Defender for SQL	✅	✅	✅ (via IaaS extension)	❌ (use Defender for Servers / third-party)

Common exam traps

• Cross-database queries on Azure SQL Database → not native; the answer is Managed Instance unless the question specifically asks for elastic query.
• "SQL Agent on Azure SQL Database" → does not exist. Use Elastic Jobs.
• "In-memory OLTP on Hyperscale" → not supported. Use Business Critical.
• "Active geo-replication for MI / VM" → wrong product. MI uses failover groups; VM / box use Always On AG.
• Plan regression first action → force the last good plan in Query Store, not index rebuild, not stats update.
• TDE vs Always Encrypted → TDE protects data at rest from someone stealing the file. Always Encrypted protects data from the DBA.
• PITR vs LTR → PITR is operational (≤35 days). LTR is compliance (years). They co-exist; they do not replace each other.
• Private endpoint vs firewall rule → firewall rules still expose the public server endpoint. Only private endpoint removes the public data path.

Use this with the rest of the wiki

• For the recall sprint, pair this page with DP-300 exam cram kit.
• For the gap audit vs the official skills measured, see DP-300 coverage map.
• For Oracle-to-Azure crosswalks referenced in callouts above, see Oracle to Azure mapping and the glossary.
• For deeper how-to pages, drill into the per-domain folders — 01-plan-implement/, 02-security/, 03-monitor-optimize/, 04-automation/, 05-hadr/.

References

• Exam DP-300: Azure Database Administrator Associate — study guide
• Exam Readiness Zone: Preparing for DP-300 — Part 1: Plan and implement
• Exam Readiness Zone: Preparing for DP-300 — Part 2: Implement a secure environment
• Exam Readiness Zone: Preparing for DP-300 — Part 3: Monitor, configure, optimize
• Exam Readiness Zone: Preparing for DP-300 — Part 4: Configure and manage automation
• Exam Readiness Zone: Preparing for DP-300 — Part 5: Plan and configure HA/DR
• Azure SQL documentation root

Flashcards

🧠 Smart order (weak cards first)

On Azure SQL Database, how do you schedule a T-SQL maintenance job that runs across 200 databases?

Click to reveal answer

Elastic Jobs — create a job agent + control database, define a target group, and schedule the T-SQL step. SQL Server Agent is not available on Azure SQL Database.

1 / 6