DP-900 Describe an analytics workload on Azure Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Increase the maximum number of Data Factory activity retries.

  Why it's wrong here

  Increasing the maximum retry count in Azure Data Factory only instructs the orchestrator to reattempt an activity after an error; it does not change the underlying rate at which requests are sent to Azure SQL Database. When the database is throttling due to DTU/vCore limits, retries simply pile up more requests once throttling subsides, which can prolong the overall pipeline duration and even exacerbate contention. Data Factory retry logic is designed for transient, non-rate-related faults, not for capacity planning at the data store level, so this configuration does not address the root cause of throttling errors.

• ✗

  Stage extracted data in Azure Blob Storage before loading into the destination.

  Why it's wrong here

  Staging extracted data in Azure Blob Storage before loading into the destination is a common pattern to decouple source extraction from destination load, but it does not reduce the load placed on the Azure SQL Database during the extraction phase. In this scenario, the throttling errors occur because the pipeline is overwhelming the database with queries or writes; staging changes where the data sits temporarily, not how many operations the database must process per second. If the pipeline still reads from the source database at the same rate and writes to the staging store, the source database's resource limits remain unchanged, so throttling persists.

• ✗

  Use a self-hosted integration runtime in the same region to execute pipelines.

  Why it's wrong here

  Deploying a self-hosted integration runtime in the same Azure region as the source Azure SQL Database can reduce network latency and improve connection reliability, but it has no effect on the database's internal resource consumption or its configured service tier. Throttling in Azure SQL Database is enforced by the database engine based on DTU or vCore quotas, CPU, I/O, and memory usage — metrics that are independent of where the client request originates. The integration runtime is just the compute that executes the pipeline; it does not increase the database's capacity or reduce the number of DTUs consumed per query, so this action cannot prevent throttling errors.

• ✓

  Configure auto-scale on the Azure SQL Database to handle higher load.

  Why this is correct

  Auto-scale on Azure SQL Database (via the serverless compute tier or elastic pool scaling) dynamically adjusts the compute resources (vCores or DTUs) to match the workload, providing additional capacity when the pipeline increases demand. This directly addresses the throttling condition, because throttling occurs when a query or transaction exceeds the resource limits of the current service objective; by scaling up, the database can handle a higher rate of requests without returning error 10928 or 40613. However, auto-scale is not instantaneous — scale-up/scale-down can take minutes — and the database's max size or per-query limits still apply, so pipelines should also be designed to avoid unreasonable bursts. This is the only option that treats the symptom at the resource layer, making it the correct choice for reducing throttling-related failures.

Go deeper

Related to this question