Transit needs a rider-alerts HTTP API backed by Azure SQL. Which deployment approach aligns with DP-800 Azure integration skills?
Select an answer to reveal the explanation.
Short Explanation
DAB is the ticket window in front of Azure SQL—deploy it so rider apps buy alerts through a proper API, not by waltzing into the database lobby.
Full Explanation
Transit needs a rider-alerts HTTP API backed by Azure SQL. The deployment approach that aligns with DP-800 Azure integration skills is to deploy Data API builder alongside Azure SQL to serve the rider-alerts API from configured entities. DAB provides a managed REST/GraphQL façade over SQL entities so rider apps call an HTTP API instead of opening database connections—fit for municipal transit alerting without custom middle-tier boilerplate for basic entity access.
Requiring every rider app to open direct admin SQL connections from phones fails security and architecture: mobile clients should not hold admin SQL credentials or speak TDS to production. Hosting only a static HTML page with no API in front of the alerts tables fails the HTTP API requirement—the stem asks for an API, not a brochure page. Exposing the database RDP endpoint to the public internet for alert lookups fails by publishing an administrative remote-desktop surface that is irrelevant to HTTP APIs and dangerously exposed.
Exam caveat: DAB + Azure SQL is the first-party pattern for entity HTTP APIs in this skill area. Direct SQL from clients, RDP exposure, or static-only sites are distractors.
Operational check: deploy DAB configured for rider-alert entities against Azure SQL, call the HTTP endpoints from a test client, verify authentication and read scopes, and confirm no admin SQL endpoints or RDP are publicly reachable as part of the transit alert solution.