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.

• ✗

  A) Read replicas

  Why it's wrong here

  Read replicas in Azure SQL Database are asynchronous secondary copies that process only read-only workloads such as reports or analytics. They offload query traffic from the primary replica, but they cannot absorb or manage compute demand from write-heavy spikes because all inserts, updates, and deletes still hit the primary's compute. Furthermore, creating or removing replicas requires manual configuration; they do not react to load changes by themselves, so they fail to meet the automatic scaling requirement of an unpredictable write spike.

• ✗

  B) Active geo-replication

  Why it's wrong here

  Active geo-replication maintains a readable secondary database in a different Azure region, and its primary purpose is disaster recovery and regional failover, not workload performance. While the secondary can technically serve read-only traffic for read scaling, its compute capacity is fixed at the service objective you choose when configuring it, and no automatic monitoring or adjustment occurs based on bursty demand. You would manually need to alter the secondary's tier or vCores, and it cannot help scale the write path, which remains the critical bottleneck during a spike.

• ✓

  C) Serverless compute tier

  Why this is correct

  The serverless compute tier for Azure SQL Database is engineered precisely for unpredictable workloads: it automatically scales the compute resources between a configured minimum and maximum vCores based on actual demand, and it can pause the database entirely during prolonged inactivity while continuing to store data. This tier bills per-second for the compute actually used, so a sudden surge in write or read activity triggers immediate scale-up without manual intervention, then scales back down when demand subsides. This is the only listed option that directly provides automatic, demand-driven compute scaling for the primary workload.

• ✗

  D) Elastic pool

  Why it's wrong here

  An elastic pool shares a fixed pool of eDTUs or vCores among multiple databases, letting each database burst up to a per-database maximum within that shared allocation. However, the pool's overall limit is set manually when you create or configure it, and the pool does not automatically increase its total capacity when aggregate demand exceeds that limit. To handle a sustained heap of traffic, you would still have to manually scale up the pool, and bursty spikes for a single database can be throttled or only use the pre-configured budget; hence it is not true automatic scaling for an unpredictable workload.

Go deeper

Related to this question