Database Projects: 10 practice questions

Question 1 of 10

What does a successful SQL project build produce for a Fabric SQL database update?

1. AA copy of every row from the live database
2. BA deployment history entry without a model
3. CA new Fabric workspace with populated tables
4. DA dacpac containing the validated database model

Question 2 of 10

What happens to a manual edit in Fabric's generated SQL project file?

1. AFabric overwrites it on the next commit from the service.
2. BSqlPackage applies it directly without building the project.
3. CFabric preserves it as the authoritative database setting.
4. DThe edit automatically becomes a post-deployment script.

Question 3 of 10

What data state does a branched Fabric SQL database receive from committed project content?

1. ANeither definitions nor empty database objects are created.
2. BOnly table rows are copied, while definitions remain in Git.
3. CThe complete schema and every source table row are copied.
4. DThe object definitions are present, but the new tables are empty.

Question 4 of 10

How does the generated SQL project treat the .sharedQueries folder?

1. AIt validates the folder as tables and removes the scripts from Git.
2. BIt ignores the folder and prevents deployment scripts from running.
3. CIt tracks the scripts but excludes the folder from model validation.
4. DIt converts every shared query into a stored procedure automatically.

Question 5 of 10

Which sequence applies repository database code to a Fabric SQL database?

1. APublish raw SQL files first, then create a project without validation.
2. BCopy table data first, then infer object definitions from the copied rows.
3. CApply database settings first, then skip the SqlPackage publish operation.
4. DBuild the SQL project, create a dacpac, then publish differential changes.

Question 6 of 10

What is required after a repository change uses invalid SQL syntax or an unsupported Fabric feature?

1. ACommit the failure so Fabric can generate smart defaults for it.
2. BPopulate the target tables before rebuilding the invalid project.
3. CManually revert the source-control change before continuing.
4. DEdit the generated project file and wait for the next Fabric commit.

Question 7 of 10

How should a team apply a supported compatibility-level setting that is absent from database-project deployment?

1. APlace it in a table row so SqlPackage treats it as metadata.
2. BStore it only in the generated project file and commit from Fabric.
3. CExpect the branch workspace to infer it from the source database.
4. DRun a supported database script after the database deployment.

Question 8 of 10

A developer prefers Visual Studio Code and must catch syntax problems before a table definition reaches the remote branch. The final change must still be applied through Fabric source control. Which workflow meets both constraints?

1. AEdit the generated project metadata in Fabric, then copy the live table locally.
2. BBuild the local SQL project, commit and push it, then update from Fabric.
3. CCreate table rows locally, then branch out without committing object definitions.
4. DPush the SQL file without a build, then rely on Fabric to rewrite invalid syntax.

Question 9 of 10

A lookup table must contain the same controlled rows after both Git updates and deployment-pipeline releases. The rows change occasionally and should remain reviewable as code. What should the project use?

1. AA repeatable MERGE marked as a post-deployment script in Shared Queries
2. BA manual data copy performed after every source-control update
3. CA branch workspace whose empty tables become the production data source
4. DA generated project-file edit that embeds every lookup row

Question 10 of 10

A team needs isolated database development and pull-request review. Merging approved code must not change the primary database until a release decision is made. Which implementation provides that separation?

1. ABranch to a new workspace, merge the pull request, then update the primary workspace.
2. BClone only the table data, then apply definitions without a repository update.
3. CBranch to a new workspace and expect the merge to publish the primary database.
4. DEdit the primary database directly and let the merge create a secondary workspace.