Parks and recreation wants every pull request to prove the SDK-style SQL Database Project still builds before merge. Which CI step should they add?
Select an answer to reveal the explanation.
Short Explanation
CI build is the dress rehearsal for the parks schema—if the SDK project won’t compile in the PR, you don’t roll it onto the stage.
Full Explanation
Parks and recreation needs every pull request to prove the SDK-style SQL Database Project still builds before merge, so the correct CI step is an automated SDK-style SQL project build and model validation on each PR. SDK-style projects compile into a consistent model that CI can validate for syntax, unresolved references, and packaging readiness. Running that build in the pull-request pipeline gives municipal engineers a dress rehearsal before schema for facilities, permits, or program enrollment lands on shared branches—exactly the secure-optimize-deploy pattern DP-800 expects for database-as-code.
Skipping builds whenever the PR title contains “urgent” fails by replacing objective validation with a social bypass; urgency does not make invalid DDL safe for parks production. Validating only manually on a developer laptop after production deploy fails temporally and environmentally: post-production laptop checks cannot prevent bad merges and are not reproducible CI evidence. Disabling continuous integration so schema syntax errors surface only in production fails by design—it moves detection to the highest-cost environment and abandons the PR gate the stem asks for.
Exam caveat: when a stem specifies SDK-style SQL Database Projects and pull-request proof, prefer automated build/model validation in CI over manual-after-prod or “skip for urgency” distractors. SDK-style tooling is highlighted because it integrates cleanly with modern pipeline tasks; legacy-only manual rituals are not the intended answer.
Operational check: open a PR that introduces a deliberate reference error (for example a view pointing at a missing parks column), confirm the SDK build task fails and blocks merge, then fix the model and verify a green build is required before the PR can complete. Also confirm the same validation task runs on the default branch after merge so parks releases never ship an unbuilt project package.