Microsoft DP-300: Finding the SQL Bottleneck

A database can be reachable, backed up and apparently healthy while an application waits thirty seconds for a simple query. Fixing that symptom requires more than a storage upgrade: the administrator must determine whether the problem is blocking, a changed execution plan, limited resources, connection behavior or a workload that has grown beyond its current design. Microsoft DP-300 tests that investigative discipline across Azure SQL and hybrid SQL Server environments.

The active exam is Administering Microsoft Azure SQL Solutions, supporting the Azure Database Administrator Associate role. Microsoft’s April 2026 objectives cover deployment and migration, security, monitoring and optimization, automation, and high availability/disaster recovery.

Decide what the platform will manage

Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure virtual machines and on-premises SQL Server expose different management responsibilities. A highly managed service can reduce infrastructure maintenance, but the administrator still owns database permissions, workload design, query quality and data recovery decisions. Managed Instance can help with specific instance-level compatibility needs; a SQL Server VM preserves more engine and operating-system control while expanding patching and availability responsibilities.

Before a migration, inventory compatibility requirements, SQL Agent jobs, cross-database dependencies, linked servers, authentication and network connectivity. A migration method that moves tables but omits important jobs has not moved the application. Estimate downtime tolerance and whether dual-running or cutover verification is possible. Choose a target based on actual workload requirements, not solely on a promise of lower maintenance.

Follow the query before buying capacity

When latency rises, start with a time window and the workload that changed. Query Store can help identify plan regressions in supported environments; wait statistics and execution plans provide different views of contention and cost. A missing index may cause large reads, but an index is not free: it consumes storage and can slow writes. Updating statistics can help the optimizer, yet it will not repair inappropriate transaction boundaries or an overloaded connection pool.

Imagine two jobs updating the same account table. Short queries wait because a long-running transaction holds locks. Adding more CPU will not remove that blocking relationship. Understand isolation levels, transaction duration and concurrency behavior before modifying resource tiers. If the application has suddenly started issuing thousands of single-row queries, the better fix may be application batching rather than a larger database SKU.

Identity and network security are complementary

Database access can depend on Microsoft Entra authentication, SQL authentication, role membership, firewall rules and private networking. Restricting a public endpoint helps network exposure, but a compromised privileged credential may still grant broad data access. Likewise, encrypting a database at rest does not prevent an authorized account from downloading sensitive rows. Least-privilege roles, auditing, secret rotation and threat-detection controls must address the full request path.

Practise reproducing an authorization failure without weakening security. Determine whether the client is blocked by the network, cannot authenticate, lacks an object-level permission or is affected by a conditional configuration. Use database audit evidence and application logs to identify the stage. A well-run environment also has a defined method for granting temporary elevated access and reviewing what it was used for.

Backups answer different questions from replicas

High availability seeks to keep a service running through certain failures; disaster recovery seeks to restore service after larger disruptions. Read replicas can serve workloads or support availability patterns, but they are not a substitute for point-in-time recovery after an accidental destructive change. Recovery point and recovery time objectives should guide geo-replication, automated backups, failover groups and operational runbooks.

Suppose a deployment deletes a critical set of rows and the mistake is detected an hour later. A replica may have copied the deletion. The administrator needs to understand the restore options, retention and recovery workflow available for that service. Always test recovery in a separate environment. A backup retention policy that has never produced a working restored database is still an unverified assumption.

Automation must make failures visible

Routine jobs include patch preparation, index and statistics maintenance where appropriate, monitoring configuration, backup verification and access reviews. Automation reduces repetitive work but can also repeat an incorrect action at scale. Deployment scripts should be versioned, reviewed and idempotent where possible; job failures need alerts routed to someone who can act.

For a DP-300 lab, run a small transactional workload, capture baseline waits and query plans, deliberately introduce blocking, then resolve it without blindly scaling compute. Restore the database to a prior point in a separate target, compare permissions and test application connectivity. Finally, write a short operational note describing the cause, the evidence, the repair and the prevention measure. That is the mindset the Azure database administrator role requires.