Emergency management models facilities, contractors, and officials as SQL graph nodes and needs a query that finds contractors linked to both a jobsite and a conflicted official. Which T-SQL construct should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Picture a corkboard with pins for jobsites and officials and strings between them—MATCH walks those graph edges to find contractors tied to both.
Full Explanation
MATCH is the correct T-SQL construct when emergency management models facilities, contractors, and officials as SQL graph nodes and needs a query that finds contractors linked to both a jobsite and a conflicted official. MATCH expresses pattern matching over node and edge tables, which is purpose-built for multipath relationship traversal such as conflict-of-interest discovery in a municipal graph.
OPENJSON fails by concept because it parses and shreds JSON; it does not walk graph edges between contractors, jobsites, and officials. TRY_CONVERT fails because it attempts type conversion with null-on-failure semantics—it addresses data-type safety, not relationship pattern matching. PIVOT fails because it rotates row values into columns for crosstab-style reports; it does not traverse node/edge topology.
Exam caveat: On DP-800, SQL graph features (node tables, edge tables, MATCH) are distinct from JSON, conversion, and pivoting tools. If the stem mentions nodes, edges, or multiparty linkage patterns, MATCH is the operator—not a JSON or reporting distractor that happens to appear in other T-SQL objectives.
Operational check: Validate the municipal graph model has the expected edge types (contractor–jobsite, contractor–official), write a MATCH query that returns only contractors connected to both required nodes, spot-check a known conflict case, and ensure the emergency ops report excludes contractors that lack one of the two required relationships.