A water-quality API must build JSON response objects and arrays for sensor readings entirely in T-SQL. Which functions should construct those payloads?
Select an answer to reveal the explanation.
Short Explanation
You can build the sensor response object and readings array right in T-SQL with JSON_OBJECT and JSON_ARRAY, without client-side serialization. Relational constraints, row numbering, and a ledger digest serve different purposes; they do not construct these JSON payloads.
Full Explanation
A water-quality API that must build JSON response objects and arrays for sensor readings entirely in T-SQL needs JSON constructor functions. JSON_OBJECT builds the response object, including sensor ID, site, and timestamp metadata, while JSON_ARRAY assembles the readings collection. Together, they let a query or procedure return a complete JSON document without client-side serialization. PRIMARY KEY and FOREIGN KEY constraints enforce relational integrity between sensor records; they do not serialize those records as JSON. ROW_NUMBER assigns ranking ordinals, but without JSON constructors it cannot emit API response documents. A ledger digest supports integrity verification of ledger tables; it is not a JSON serialization substitute for sensor APIs. Exam caveat: constructor function names and support can vary across Azure SQL, Fabric Warehouse, and Synapse, so know which JSON builders your exam surface supports; the key distinction is server-side JSON construction rather than relational constraints, window numbering, or ledger integrity verification. Practical check: select a known sensor’s latest readings through the constructing query, parse its output as JSON in a test client, and verify that the object fields and array length match the relational source.