DP-900 Practice Question: Identify considerations for relational data on Azure

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Built-in high availability with automatic failover

  Why this is correct

  Azure SQL Database's built-in high availability uses multiple synchronous replicas and automatic failover at the database level, so if a node fails, connections are transparently redirected to a healthy replica. This is provisioned and managed by Microsoft without you having to configure Always On Availability Groups or deploy additional VMs. Consequently, you receive a 99.99% uptime SLA while avoiding the operational burden of designing your own HA stack.

• ✓

  Automated patching and updates

  Why this is correct

  With Azure SQL Database, Microsoft owns and executes the entire patching lifecycle: it applies security updates and service fixes to both the OS and the SQL engine, typically during a scheduled, non-arbitrary maintenance window. This means you no longer need to plan, test, or manually install patches as you would on a SQL Server VM. The automation also closes known vulnerabilities promptly, reducing your security overhead and helping meet compliance requirements.

• ✗

  Lower cost because you can choose any number of vCores

  Why it's wrong here

  Choosing a specific number of vCores does not guarantee lower cost; your bill is driven by service tier, DTU/vCore model, storage size, and additional features like geo-replication or long-term backup retention. Moreover, the vCore options are discrete steps rather than any arbitrary value, and an IaaS SQL Server VM can also be scaled to a flexible vCore count. In many steady-state workloads, a SQL Server VM may even be cheaper, so vCore selection alone is not a cost benefit.

• ✗

  Ability to install custom software on the database server

  Why it's wrong here

  Azure SQL Database is a fully managed PaaS offering, so there is no server OS or host environment to access—you cannot install software, agents, or middleware on the underlying server. Even features that seem extensible, such as custom CLR assemblies, are executed inside the database and cannot modify the server. If your application depends on running third-party software on the database server, you would need an IaaS VM instead.

• ✗

  Full control over the operating system

  Why it's wrong here

  Because Azure SQL Database is a PaaS service, Microsoft abstracts the operating system and exposes only database-level management tools like T-SQL and the Azure Portal. You cannot RDP to the server, change Windows registry values, or configure OS-level security policies. Full OS control remains with Microsoft, so for workloads requiring complete administrative control, a SQL Server on an Azure VM is the appropriate choice.

Go deeper

Related to this question