A city’s 311 team needs neighborhood lookup rows available in every environment after SQL Database Project deploy. How should they ship that static data?

A city’s 311 team needs neighborhood lookup rows available in every environment after SQL Database Project deploy. The correct approach is to include seed neighborhood lookup data in post-deploy scripts managed with the SQL Database Project so reference data ships with the same versioned artifact as schema. Post-deploy scripts give municipal teams a repeatable, reviewable way to plant static codes—neighborhood identifiers used for routing 311 requests—consistently across development, test, and production without relying on tribal knowledge.

Hand-editing production lookup rows after every deploy with no script history fails by concept: manual edits are not environment-portable, not code-reviewed, and drift silently between clinics of environments. Omitting reference data from the project and hoping each environment invents its own codes fails consistency—311 analytics and routing break when neighborhood keys diverge. Storing neighborhood seeds only in a personal spreadsheet outside source control fails durability and collaboration: the spreadsheet is not tied to project versions, PRs, or pipeline execution.

Exam caveat: for static or reference data that must appear after deploy, SQL Database Project post-deployment scripts are the standard pattern. Do not confuse this with ad-hoc production DML or unmanaged files; the exam wants the seed under source control with the project.

Operational check: add a post-deploy script that upserts the canonical neighborhood lookup set, deploy the project to a clean test database, and query the lookup table to confirm expected 311 neighborhood codes exist. Redeploy to a second environment and verify the same codes and keys; review the script in a PR so changes to neighborhood seeds follow the same branching policy as schema DDL.