Simulado Microsoft Azure Data Engineer Associate (DP-203)

Configuring Azure Monitor metric alerts on the pool's platform metrics is correct because the dedicated SQL pool emits DWU used percentage, tempdb, and adaptive cache metrics natively to Azure Monitor, and metric alerts with thresholds and evaluation windows give proactive, low-code notification exactly as requested. Scheduling DMV polling with emailed results is unnecessary and incorrect as a claim that DMVs are the only source: these resource metrics are exposed as Azure Monitor platform metrics, and a custom polling/email job is more code, less reliable, and lacks built-in alert evaluation. Azure Defender (Microsoft Defender for SQL) focuses on security threat detection and vulnerability assessment, not compute/cache performance alerting, so it does not raise DWU or cache-pressure alerts. Watching Synapse Studio monitoring charts manually is reactive and limited to when someone is looking, which contradicts the requirement for proactive, threshold-based alerting that fires automatically.

A dedicated SQL pool is correct: predictable, repetitive, high-concurrency star-schema reporting with strict latency targets is exactly the workload provisioned MPP with clustered columnstore and resource classes is built for, and the stable model justifies the ingestion/loading step. A serverless SQL pool for every Power BI refresh is the misconception that serverless always saves money — for high-frequency repetitive queries, pay-per-scan costs accumulate and there is no provisioned compute guaranteeing concurrency and consistent low latency, so it underperforms here. A Spark pool exposing Spark SQL endpoints per report is wrong because Spark is optimized for batch/data-engineering transforms, not concurrent interactive BI; cluster warm-up and per-vCore cost make it a poor BI serving layer. Querying raw CSV directly with no SQL serving layer is wrong because CSV is row-oriented and uncompressed, lacks statistics and columnstore segment elimination, and cannot deliver the demanded concurrency or latency.

A private endpoint plus disabling public network access is correct: the private endpoint projects the storage account into the virtual network with a private IP, so traffic flows over the Microsoft backbone/VNet rather than the public internet, and disabling public network access ensures all public-IP requests are rejected. Allow-listing Synapse outbound IPs in the storage firewall still routes traffic over public endpoints (it just filters by source IP), so it does not keep traffic off the public internet. A service endpoint optimizes routing and lets the storage firewall trust the subnet, but the storage resource still has a public endpoint and traffic does not get a private IP — it does not fully remove public exposure the way a private endpoint with public access disabled does. TDE encrypts data at rest and has nothing to do with network path or public-access controls.