The permits office needs fee-schedule lookup rows versioned with the schema so every environment gets the same reference values. Where should that data live?
Select an answer to reveal the explanation.
Short Explanation
Keep the fee schedule in source-controlled static data with the SQL Database Project, so you get the same reference values in every environment. That beats relying on clerks to retype rows, emailed spreadsheets, or a manually updated desktop Access file.
Full Explanation
Fee-schedule lookup rows that must be identical across environments belong in source-controlled static data scripts with the SQL Database Project. Versioning reference data beside the schema means every permits-office environment—development, test, staging, and production—receives the same fee values through deployment rather than drifting through manual edits. Asking clerks to retype fee rows after every deployment is error-prone and can produce environment differences. Emailing a spreadsheet and hoping staging matches production does not provide an auditable deployment artifact. Keeping schedules only in a shared desktop Access file, updated manually so environments can have their own values, breaks repeatability and leaves the Database Project incomplete as a release unit. Exam caveat: distinguish reference or static data, such as fee codes and carefully effective-dated rates, from transactional data, such as issued permits; static scripts should not overwrite transactional records. Seed or MERGE scripts should be idempotent. Effective-dated fee changes may require coordination with an application release so mid-day rate changes do not surprise cashiers. Practical check: add idempotent fee-schedule scripts to the project, deploy to two empty environments, and compare fee-row checksums. Change a rate in source control, run the pipeline, and confirm both environments receive the same new value without manual clerk entry.