Azure DP-300 common mistakes
Azure DP-300 · Understand the traps and how to avoid them.
Selecting a service tier or purchasing model (DTU vs. vCore) from the price column alone, without first checking which features the requirement implies (zone redundancy, read-only replicas, up to 100 TB, long-term backup retention, 24-hour PITR for hyperscale, etc.).
Candidates memorize tier names and approximate prices but not the feature boundaries between Basic/Standard/Premium and General Purpose/Business Critical/Hyperscale, so they pick a tier that meets cost but silently violates a stated requirement.
What to do instead
Before answering, extract every hard requirement from the stem into a short list (RPO/RTO, max size, read-scale, zone redundancy, latency, retention). Then map each requirement to a feature and let the feature set determine General Purpose vs. Business Critical vs. Hyperscale and DTU vs. vCore. Treat price as the last filter, not the first.
Choosing serverless compute for a workload described as steady, predictable, or latency-sensitive, or assuming serverless auto-scaling removes the need to set min/max vCores.
Serverless sounds like a free upgrade and 'auto-scaling' sounds universally better; candidates overlook auto-pause cold-start delay, the per-second billing only while active, and that memory/IO limits are tied to the chosen vCore range.
What to do instead
Use serverless only for intermittent, single-database workloads where a cold-start delay is acceptable; lower the min vCores if pause is required, and remember Business Critical is not available in serverless. For continuous or low-latency workloads, choose provisioned General Purpose or Business Critical and justify it with the workload pattern.
Satisfying a 'no public internet exposure' or 'private connectivity only' requirement by adding a server-level firewall rule, enabling 'Allow Azure services and resources to access this server', or relying on a service endpoint, then declaring the database private.
These settings are the easiest knobs to find and they do restrict IP ranges, so they look like private networking; candidates miss that the database still has a public endpoint and still resolves to a public FQDN.
What to do instead
Design a private endpoint into a delegated subnet, link a private DNS zone (privatelink.database.windows.net) so the server name resolves internally, and set the public network access to Disabled. Verify that the firewall rule and the Azure-services toggle are removed or disabled and state how a client inside the VNet resolves the name.
Designing authentication with server-level SQL logins (or assuming logins, SQL Agent jobs, and server-level objects will follow the database to another server) when the database must fail over or be reachable by an application identity.
SQL logins are the default mental model from on-premises SQL Server and work fine on a single server, so the failure only appears during failover or cross-server restore; candidates also forget that an Entra admin must exist before contained users can be created.
What to do instead
Use Microsoft Entra authentication with contained database users (CREATE USER ... FROM EXTERNAL PROVIDER) or a managed identity for the application, and set the Entra admin at the server or instance level first. State explicitly that a failover group requires contained users because server-level logins and SIDs are not replicated.
Diagnosing slow queries by immediately recommending a larger tier or more vCores instead of reading the actual evidence (Query Store top resource consumers, wait statistics, missing index DMVs, blocking chains, parameter sniffing symptoms).
Scaling up is a single-click fix that always 'sounds right' and candidates are more comfortable with sizing than with interpreting DMVs; the stem usually contains a clue that the problem is a bad plan or a missing index, not capacity.
What to do instead
Start from Query Store: identify the specific query, its plan regressions, and its wait types before touching tier. Recommend a plan-level fix (force a good plan, add/adjust an index, update statistics, fix parameter sniffing, address blocking) and only recommend resizing when waits show sustained resource saturation rather than a single bad plan.
Assuming automatic tuning is enabled by default and covers all tuning actions on every Azure SQL offering, e.g., expecting CREATE INDEX and DROP INDEX recommendations on Azure SQL Managed Instance.
Documentation lists three tuning actions together and Query Store must be in READ_WRITE for any of them to work, so candidates flatten the matrix and treat the feature as omniversal.
What to do instead
Remember that automatic tuning requires Query Store in READ_WRITE, can be set at the server or database level, and that Managed Instance supports only FORCE LAST GOOD PLAN while Azure SQL Database supports CREATE INDEX, DROP INDEX, and FORCE LAST GOOD PLAN. When recommending automatic tuning, state the scope (server vs. database) and the Query Store prerequisite.
Scheduling a recurring administrative task in Azure SQL Database with a SQL Server Agent job, or using Azure Automation with an account that has no managed identity or role assignment.
SQL Server Agent is the familiar on-premises scheduler and exists on Managed Instance, so candidates carry it over to Azure SQL Database where it does not exist; separately, runbooks are created but the identity and least-privilege RBAC needed to authenticate to Azure are never specified.
What to do instead
For Azure SQL Database use Elastic Database Jobs (with a job database and target-group credentials) or an Azure Automation runbook; use SQL Server Agent only on Managed Instance or SQL Server on Azure VMs. For Automation, enable a system-assigned managed identity, grant it the minimum role (e.g., Contributor scoped to the server/resource group, or a database-scoped user with the required permissions), and reference it instead of stored credentials.
Recommending active geo-replication when the requirement calls for automatic failover, a single read-write and read-only endpoint, or no connection-string changes after failover; or recommending a failover group when only a manually controlled, per-database secondary is needed.
Both features create a secondary in another region, so they look interchangeable; candidates forget that active geo-replication has no automatic failover policy and requires the application to change its connection string.
What to do instead
Choose auto-failover groups when the requirement mentions automatic failover, a listener endpoint, read-write/read-only routing, or multiple databases failed over as a unit; choose active geo-replication when explicit, manual, per-database control is required. Pair the answer with contained users and state the expected RPO (seconds-to-minutes, asynchronous).
Answering a long-retention requirement (multi-year, compliance, or restore-any-week-in-the-last-3-years) with point-in-time restore or geo-restore, or assuming PITR can be configured beyond its maximum retention.
PITR is the feature candidates practice most, and its 7-35 day window (as low as 24 hours for hyperscale, 1-35 days for Managed Instance) is easy to overlook, so a 'restore to a date six months ago' scenario gets answered with the wrong mechanism.
What to do instead
Route anything beyond the PITR window to long-term retention backups (configured as weekly/monthly/yearly policies on a storage account), restore from LTR to a new database, and remember geo-restore uses geo-replicated backups and is a different operation from PITR and from failover. Always state the retention window of the mechanism you pick.
Treating Dynamic Data Masking or a restricted database role as the answer whenever a stem says data must not be readable by unauthorized users, and assuming masked values are encrypted in storage.
Masking is presented as a 'data protection' feature and the exam stems often use vague wording like 'sensitive data must not be visible'; candidates do not distinguish presentation-layer masking from cryptographic protection of the column.
What to do instead
Ask what threat is described: if it is accidental exposure to non-privileged users who query through the app, DDM is sufficient and the data stays readable to users with UNMASK or privileged roles; if the requirement is that the data not be readable at rest, in transit, or by the DBA/hosting service, use Always Encrypted (or TDE for at-rest-only requirements) and note that TDE does not protect data from a privileged in-database user.