Create, build, and validate database models by using SQL Database Projects, including SDK-style models – Part 2 (DP-800 Exam Prep)

This post is a part of the DP-800: Developing AI-Enabled Database Solutions Exam Prep Hub.
This topic falls under these sections:
Secure, optimize, and deploy database solutions (35–40%)
   --> Implement CI/CD by using SQL Database Projects
      --> Create, build, and validate database models by using SQL Database Projects, including SDK-style models


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

In Part 1, you learned about SQL Database Projects, database models, SDK-style projects, build validation, and DACPAC generation. In this section, we’ll examine how developers work with existing databases, manage dependencies, validate projects, deploy changes, and implement modern DevOps practices.


Importing an Existing Database into a SQL Database Project

Many organizations already have production databases before adopting Database-as-Code practices. Rather than starting from scratch, developers can import an existing schema into a SQL Database Project.

The import process typically:

  1. Connects to an existing SQL Server or Azure SQL Database.
  2. Reads the database schema.
  3. Extracts supported objects.
  4. Creates corresponding .sql files.
  5. Generates the SQL Database Project.

Objects that are typically imported include:

  • Tables
  • Views
  • Stored procedures
  • Functions
  • User-defined data types
  • Schemas
  • Security objects
  • Synonyms
  • Sequences

Data itself is not imported into the project.


Reverse Engineering a Database

Importing is often called reverse engineering because the project is generated from an existing database rather than the database being created from source code.

Example workflow:

Production Database
Extract Schema
Generate SQL Project
Commit to Git
Future Changes Through Source Control

This allows teams to transition from manual database administration to modern DevOps practices.


Source Control Integration

One of the biggest advantages of SQL Database Projects is seamless integration with Git.

A repository may contain:

DatabaseProject/
├── Tables/
├── Views/
├── Procedures/
├── Security/
├── Scripts/
├── Database.sqlproj
└── README.md

Each change becomes a Git commit, providing:

  • Version history
  • Code reviews
  • Branching
  • Pull requests
  • Rollback capabilities
  • Team collaboration

Branching Strategies

Common Git workflows include:

Feature Branches

Each developer works in an isolated branch.

Main
├── Feature-A
├── Feature-B
└── Feature-C

Changes are merged only after review and successful validation.


Release Branches

Organizations often create release branches for production deployments.

Example:

Main
Release 1.0
Production

This ensures stable production releases.


Database References

Large enterprise systems often contain multiple databases.

Examples include:

  • Sales
  • Inventory
  • Human Resources
  • Finance

Applications frequently reference objects across databases.

SQL Database Projects support database references to resolve these dependencies during the build process.


Example of a Cross-Database Reference

Suppose a stored procedure references another database:

SELECT *
FROM Inventory.dbo.Products;

Without a database reference, the build reports an unresolved reference.

Adding a database reference informs the build engine where the referenced objects reside.


Project References

A SQL Database Project can reference another SQL Database Project.

Example:

SalesDatabase
References
SharedDatabase

This allows developers to:

  • Reuse shared schemas
  • Validate dependencies
  • Build multiple databases together

Schema Compare

Schema Compare is one of the most valuable tools in SQL Database Projects.

It compares:

  • Project vs Database
  • Database vs Database
  • Project vs DACPAC
  • DACPAC vs Database

The comparison identifies differences before deployment.


Schema Compare Example

Suppose the project contains:

CustomerName NVARCHAR(200)

Production contains:

CustomerName NVARCHAR(100)

Schema Compare highlights the difference before deployment.


Why Schema Compare Matters

Schema Compare helps prevent:

  • Missing objects
  • Accidental deletions
  • Unexpected schema drift
  • Incorrect deployments
  • Manual mistakes

It also generates deployment scripts automatically.


Schema Drift

Schema drift occurs when changes are made directly to a production database instead of through the SQL Database Project.

Example:

Project:

Employee
Salary

Production:

Employee
Salary
Bonus

The project is now out of sync.

Schema Compare identifies this difference.


Build Process

Building a SQL Database Project performs several validation steps:

  1. Parse SQL files
  2. Validate syntax
  3. Resolve dependencies
  4. Build the database model
  5. Detect conflicts
  6. Generate the DACPAC

Only after these steps succeed is the project considered buildable.


Common Build Errors

Examples include:

Missing Table

SELECT *
FROM Orders;

If the Orders table does not exist, the build fails.


Invalid Column

SELECT CustomerAge
FROM Customers;

If CustomerAge is absent, validation reports an error.


Duplicate Object

Two files define:

CREATE TABLE Customers

The project cannot determine which definition is correct, so the build fails.


Circular Dependency

View A depends on View B.

View B depends on View A.

This circular dependency prevents successful validation.


Build Warnings vs Build Errors

WarningError
Build succeedsBuild fails
Potential issueMust be fixed
Deployment possibleDeployment blocked
Review recommendedImmediate action required

Developers should investigate warnings even if the build succeeds.


Pre-Deployment Scripts

Pre-deployment scripts execute before schema deployment.

Typical uses include:

  • Backups
  • Temporary objects
  • Data preparation
  • Environment validation
  • Configuration checks

Example:

PRINT 'Preparing deployment';

Post-Deployment Scripts

Post-deployment scripts execute after schema deployment.

Typical tasks include:

  • Insert lookup data
  • Populate configuration tables
  • Create default users
  • Update permissions
  • Seed application settings

Example:

INSERT INTO Status
VALUES ('Active');

SQLPackage

SQLPackage is Microsoft’s command-line utility for SQL Database Projects.

It can:

  • Build projects
  • Publish DACPACs
  • Extract schemas
  • Generate deployment scripts
  • Compare schemas
  • Export DACPACs

SQLPackage is widely used in automated deployment pipelines.


Common SQLPackage Operations

Developers commonly use SQLPackage to:

  • Publish a DACPAC to Azure SQL Database.
  • Extract a DACPAC from an existing database.
  • Generate deployment scripts without applying them.
  • Compare source and target schemas.

This enables repeatable, automated deployments.


Continuous Integration (CI)

A CI pipeline typically performs:

Git Commit
Restore
Build SQL Project
Validate Model
Run Tests
Generate DACPAC
Publish Build Artifact

Every commit is validated automatically.


Continuous Delivery (CD)

The CD pipeline deploys validated artifacts.

Typical workflow:

DACPAC
Development
Testing
Staging
Production

Promotion between environments follows organizational approval policies.


Deployment Validation

Before deployment, the deployment engine evaluates:

  • Schema differences
  • Data loss risks
  • Object dependencies
  • Permission changes
  • Unsupported operations

Potentially destructive changes, such as dropping a populated table, are flagged for review.


Environment-Specific Configuration

Projects should avoid hard-coding environment-specific settings.

Instead, deployment profiles or pipeline variables should define values such as:

  • Server name
  • Database name
  • Authentication method
  • Connection strings
  • Environment-specific options

This supports consistent deployments across development, test, and production.


SDK-Style Project Best Practices

Microsoft recommends the following practices:

  • Store every schema object in its own file.
  • Use meaningful folder structures.
  • Commit all schema changes to source control.
  • Build frequently.
  • Resolve warnings before deployment.
  • Validate pull requests automatically.
  • Use deployment profiles for different environments.
  • Automate builds with CI/CD pipelines.
  • Minimize manual production changes.
  • Keep database references current.

Common DP-800 Exam Scenarios

Scenario 1

A developer changes a table directly in production.

Question: What problem has occurred?

Answer: Schema drift.


Scenario 2

A project builds successfully but deployment has not occurred.

Question: What artifact was created?

Answer: A DACPAC.


Scenario 3

A stored procedure references another database and validation fails.

Question: What should be added?

Answer: A database reference (or project reference, where appropriate).


Scenario 4

A team wants every schema change reviewed before deployment.

Recommended approach:

  • Git repository
  • Pull requests
  • SQL Database Projects
  • Automated build validation
  • DACPAC deployment

DP-800 Exam Tips

  • Understand the difference between project references and database references.
  • Know how Schema Compare identifies schema drift and deployment differences.
  • Recognize when to use pre-deployment versus post-deployment scripts.
  • Be familiar with SQLPackage as the primary command-line deployment tool.
  • Understand that CI pipelines build, validate, and generate DACPACs, while CD pipelines deploy those validated artifacts.
  • Remember that schema validation occurs before deployment, helping detect unresolved references, duplicate objects, and dependency issues.

Key Takeaways

  • Existing databases can be reverse engineered into SQL Database Projects.
  • Source control enables collaboration, auditing, and rollback.
  • Database and project references resolve dependencies across databases.
  • Schema Compare identifies schema differences and drift.
  • SQLPackage automates building, extracting, comparing, and deploying database projects.
  • CI/CD pipelines automate validation and deployment.
  • Pre-deployment and post-deployment scripts help manage operational tasks during deployment.
  • SDK-style projects reduce maintenance while supporting modern DevOps workflows.

Practice Exam Questions

Question 1

A development team wants to ensure that all database schema changes are version controlled, reviewed through pull requests, and automatically validated before deployment.

Which approach should they implement?

A. Store the database schema in a SQL Database Project managed in Git and use CI/CD pipelines.

B. Allow developers to make schema changes directly in production and back up the database daily.

C. Export a database backup after every schema change.

D. Maintain documentation of schema changes in a shared spreadsheet.

Correct Answer: A

Explanation

SQL Database Projects support Database-as-Code practices by storing database objects in source control. Combined with Git and CI/CD pipelines, schema changes can be reviewed, validated, tested, and deployed consistently. The other options lack automation, version control, and build validation.


Question 2

What is the primary output generated when a SQL Database Project is successfully built?

A. A transaction log

B. A DACPAC

C. A backup (.bak) file

D. A SQL trace file

Correct Answer: B

Explanation

A successful build generates a DACPAC (Data-tier Application Package) that contains the compiled database model. It serves as the deployment artifact for publishing schema changes. A backup file and transaction log contain database data, not compiled schema definitions.


Question 3

A stored procedure references a table in another database. During the build process, an unresolved reference error occurs.

What should you configure?

A. A post-deployment script

B. A schema comparison

C. A database reference

D. Query Store

Correct Answer: C

Explanation

Database references inform the build engine about objects located in external databases, allowing dependency validation during compilation. Without the reference, the build engine cannot resolve cross-database object names.


Question 4

Which statement accurately describes an SDK-style SQL Database Project?

A. It requires every SQL file to be manually added to the project file.

B. It supports only Azure SQL Database.

C. It cannot be used with Git.

D. It automatically discovers SQL files and uses a simplified project format.

Correct Answer: D

Explanation

SDK-style projects simplify project configuration by automatically discovering SQL files and using a modern SDK-based project structure. This reduces maintenance, improves Git compatibility, and supports cross-platform development.


Question 5

During a build, a view references a table that no longer exists.

What is the expected outcome?

A. The build reports a validation error.

B. The DACPAC is generated without warnings.

C. The table is automatically recreated.

D. The deployment succeeds and fixes the dependency.

Correct Answer: A

Explanation

The build engine validates object dependencies while constructing the database model. Missing referenced objects generate validation errors that prevent a successful build until the dependency is resolved.


Question 6

Your team notices that a production database contains several tables that are not present in the SQL Database Project because administrators modified production directly.

What situation does this describe?

A. Database normalization

B. Incremental deployment

C. Schema drift

D. Model optimization

Correct Answer: C

Explanation

Schema drift occurs whenever changes are made outside the controlled development process, causing production and source control to diverge. Schema Compare is commonly used to detect these differences.


Question 7

Which tool is specifically designed to compare differences between a SQL Database Project and a target database before deployment?

A. Query Store

B. SQL Profiler

C. SQL Server Agent

D. Schema Compare

Correct Answer: D

Explanation

Schema Compare analyzes differences between schemas stored in projects, DACPACs, and databases. It helps identify schema drift and generates deployment scripts before changes are applied.


Question 8

Why is compile-time validation an important feature of SQL Database Projects?

A. It encrypts the deployed database automatically.

B. It detects schema and dependency problems before deployment.

C. It improves query execution speed.

D. It compresses database backups.

Correct Answer: B

Explanation

Compile-time validation identifies syntax errors, unresolved references, duplicate objects, and dependency problems before deployment, reducing production failures and improving deployment reliability.


Question 9

Which activity is most appropriate for a post-deployment script?

A. Building the DACPAC

B. Validating SQL syntax

C. Inserting lookup or reference data after schema deployment

D. Resolving project references

Correct Answer: C

Explanation

Post-deployment scripts execute after schema changes have been applied. Common tasks include inserting lookup data, populating configuration tables, creating default records, and updating permissions.


Question 10

Which statement best describes the relationship between Continuous Integration (CI) and SQL Database Projects?

A. CI replaces the need for SQL Database Projects.

B. CI automatically converts databases into NoSQL databases.

C. CI performs backups before every deployment.

D. CI automatically builds, validates, and produces deployment artifacts whenever changes are committed.

Correct Answer: D

Explanation

Continuous Integration automates the process of building SQL Database Projects, validating database models, detecting errors, and generating DACPAC deployment artifacts whenever developers commit changes. This enables early detection of issues and supports reliable, repeatable deployments.


Exam Tips

  • Know the difference between a SQL Database Project, a database model, and a DACPAC.
  • Remember that SDK-style projects automatically discover SQL files and simplify project maintenance.
  • Understand the purpose of database references and project references.
  • Be able to identify scenarios involving schema drift and understand how Schema Compare addresses them.
  • Know the difference between pre-deployment and post-deployment scripts.
  • Understand how SQLPackage, CI/CD pipelines, and Git work together to automate database deployments.
  • Expect scenario-based questions that ask you to choose the appropriate development or deployment strategy for a given situation.

Go to the DP-800 Exam Prep Hub main page

Leave a comment