Tag: Source Control for Database Projects

Data Development, Data Governance, Databases, DP-800, Microsoft Certification

Manage branching, pull requests, and conflict resolution (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
      --> Manage branching, pull requests, and conflict resolution

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

Modern database development follows the same DevOps practices used in application development. Rather than making changes directly in production databases, developers define database objects in SQL Database Projects, store them in Git repositories, collaborate through branches, validate changes with pull requests (PRs), and deploy them using automated CI/CD pipelines.

Branching strategies, code reviews, and conflict resolution are critical to maintaining database quality and enabling multiple developers to work on the same project without interfering with one another. For the DP-800: Developing AI-Enabled Database Solutions exam, candidates should understand how SQL Database Projects integrate with GitHub and Azure DevOps, how branches support parallel development, how pull requests improve code quality, and how merge conflicts are identified and resolved.

Why Branching Matters

Without branching, every developer would modify the same code base simultaneously, leading to:

  • Frequent overwriting of changes
  • Lost work
  • Deployment failures
  • Unstable builds
  • Difficult troubleshooting

Branching allows developers to:

  • Work independently
  • Develop multiple features simultaneously
  • Fix bugs without affecting ongoing work
  • Experiment safely
  • Test changes before merging
  • Support multiple release versions

Git branches isolate work until it is ready to become part of the main code base.

Git Branch Fundamentals

A branch represents an independent line of development.

Instead of editing the main branch directly, developers create a separate branch.

Example:

main
 ├── feature/customer-search
 ├── feature/new-index
 ├── bugfix/order-total
 └── feature/security

Each branch contains:

  • Database objects
  • SQL scripts
  • Project files
  • Build configurations
  • Deployment scripts

Developers commit changes to their own branches until the work is complete.

Common Branch Types

Many organizations follow a branching strategy with defined branch purposes.

Main Branch

Usually called:

  • main
  • master (older repositories)

Characteristics:

  • Production-ready
  • Stable
  • Protected
  • Deployable

Direct commits are generally prohibited.

Develop Branch

Some teams maintain a separate develop branch.

Example:

main
↓
develop
↓
feature branches

Develop serves as the integration branch where completed features are merged before being promoted to production.

Feature Branches

Feature branches are created for new development work.

Examples:

feature/add-order-table
feature/customer-report
feature/inventory
feature/security-update

Feature branches should:

  • Be short-lived
  • Focus on one feature
  • Merge back quickly
  • Be deleted after merging

Bug Fix Branches

Bug fix branches address defects.

Examples:

bugfix/null-reference
bugfix/index-performance
bugfix/security

Hotfix Branches

Hotfixes repair urgent production issues.

Example:

main
↓
hotfix/login-timeout
↓
production

Hotfixes bypass normal feature development to resolve critical issues quickly.

Branching Strategies

Several branching strategies are commonly used.

GitHub Flow

Simplified workflow:

main
↓
feature branch
↓
Pull Request
↓
Review
↓
Merge
↓
Deploy

GitHub Flow is commonly used for cloud-native and continuous deployment environments.

Git Flow

Git Flow introduces additional branches:

  • main
  • develop
  • feature
  • release
  • hotfix

This strategy supports complex release cycles but introduces more branch management overhead.

Trunk-Based Development

In trunk-based development:

  • Developers create very short-lived branches.
  • Changes are merged frequently.
  • Continuous integration runs constantly.

Benefits include:

  • Smaller merges
  • Faster feedback
  • Reduced conflicts

Creating a Branch

Typical workflow:

git checkout main
git pull
git checkout -b feature/add-customer-address

The developer now works independently without affecting the main branch.

Keeping Branches Updated

Long-lived branches increase merge conflicts.

Regularly synchronize with the latest changes:

git fetch
git merge main

or

git rebase main

This keeps the feature branch aligned with current development.

Commits Within Branches

A feature branch should contain logical commits.

Good examples:

Add Customer table
Create Orders view
Implement RLS policy
Add clustered index
Fix foreign key constraint

Avoid combining unrelated changes into a single commit.

Push Changes to the Remote Repository

After committing:

git push origin feature/add-customer-address

The branch becomes available for collaboration and review.

Pull Requests (PRs)

A pull request is a request to merge one branch into another.

Example:

feature/add-orders
↓
Pull Request
↓
main

A PR provides:

  • Code review
  • Discussion
  • Automated validation
  • Build verification
  • Test execution
  • Approval workflow

Pull Request Workflow

Typical process:

Developer
↓
Push Branch
↓
Open Pull Request
↓
Automated Build
↓
Automated Tests
↓
Code Review
↓
Approval
↓
Merge
↓
Delete Branch

Benefits of Pull Requests

Pull requests improve quality by allowing reviewers to evaluate:

  • SQL syntax
  • Naming conventions
  • Security
  • Performance
  • Index usage
  • Constraints
  • Foreign keys
  • Deployment impact
  • Maintainability

Multiple reviewers often reduce production defects.

Branch Protection Policies

Production branches should be protected.

Typical policies include:

  • No direct commits
  • Pull request required
  • Minimum reviewer approval
  • Successful build required
  • Passing automated tests
  • Signed commits (optional)
  • Status checks

Protected branches reduce accidental deployments and unauthorized changes.

Automated Validation

Many organizations configure PR validation pipelines.

Before merging, the pipeline may:

  • Build the SQL Database Project
  • Generate a DACPAC
  • Run static code analysis
  • Execute unit tests
  • Validate SQL syntax
  • Verify deployment scripts

Only successful builds may be merged.

Merge Strategies

Git supports multiple merge methods.

Merge Commit

Preserves complete branch history.

Main ----A----B------M
          \
           C----D

Squash Merge

Combines all commits into one.

Useful when a feature contains many small commits.

History remains cleaner.

Rebase and Merge

Replays commits onto the latest branch.

Produces a linear commit history.

Some organizations prefer rebasing to simplify repository history.

Merge Conflicts

A merge conflict occurs when Git cannot determine which change should be preserved.

Example:

Developer A:

ALTER TABLE Customers
ADD Phone VARCHAR(20);

Developer B:

ALTER TABLE Customers
ADD PhoneNumber VARCHAR(25);

Git cannot determine which version is correct.

Human intervention is required.

Common Causes of Merge Conflicts

Conflicts often occur when developers modify:

  • The same SQL file
  • The same stored procedure
  • The same table definition
  • Shared configuration files
  • Database project files
  • Static data scripts

The longer branches remain separate, the greater the chance of conflicts.

Conflict Resolution Process

Typical workflow:

Merge Attempt
↓
Conflict Detected
↓
Review Differences
↓
Choose Correct Changes
↓
Edit File
↓
Test
↓
Commit Resolution
↓
Complete Merge

Best Practices for Conflict Resolution

When resolving conflicts:

  • Understand both developers’ changes.
  • Communicate with teammates if necessary.
  • Preserve intended functionality.
  • Rebuild the project.
  • Run automated tests.
  • Validate deployment scripts.
  • Review schema differences carefully.

Never resolve conflicts without understanding the impact.

Database-Specific Merge Challenges

Database development introduces unique considerations.

Examples include:

  • Simultaneous column additions
  • Conflicting index definitions
  • Different foreign key changes
  • Constraint modifications
  • Stored procedure rewrites
  • Permission changes
  • Seed data updates

Successful merges require understanding both Git operations and database semantics.

Preventing Merge Conflicts

Good practices include:

  • Keep branches short-lived.
  • Merge frequently.
  • Pull latest changes often.
  • Break large features into smaller tasks.
  • Communicate with team members.
  • Avoid editing unrelated files.
  • Use atomic commits.
  • Review changes before pushing.

Reviewing SQL Changes

Reviewers should examine:

  • Table modifications
  • New indexes
  • Dropped indexes
  • Constraints
  • Stored procedures
  • Views
  • Security changes
  • RLS policies
  • Permissions
  • Deployment scripts

Reviewing deployment impact is as important as reviewing SQL syntax.

CI/CD Integration

Branching and pull requests integrate naturally with CI/CD.

Example workflow:

Developer
↓
Feature Branch
↓
Commit
↓
Push
↓
Pull Request
↓
Automated Build
↓
Unit Tests
↓
Generate DACPAC
↓
Approval
↓
Merge
↓
Deployment Pipeline
↓
Development
↓
Test
↓
Production

Azure DevOps Integration

Azure DevOps supports:

  • Azure Repos
  • Pull requests
  • Branch policies
  • Build validation
  • Release pipelines
  • Work item linking
  • Reviewer assignment

Branch policies can require:

  • Minimum reviewers
  • Successful pipeline execution
  • Linked work items
  • Comment resolution

GitHub Integration

GitHub provides:

  • Feature branches
  • Pull requests
  • Protected branches
  • Required reviewers
  • GitHub Actions
  • Required status checks
  • Merge queues
  • Code Owners

GitHub Actions can automatically:

  • Build SQL Database Projects
  • Generate DACPACs
  • Execute validation
  • Publish build artifacts
  • Trigger deployment workflows

Best Practices

Microsoft recommends:

  • Never develop directly in the main branch.
  • Use descriptive branch names.
  • Keep branches short-lived.
  • Create focused commits.
  • Open pull requests early.
  • Require peer reviews.
  • Enable automated validation.
  • Protect production branches.
  • Resolve conflicts carefully.
  • Delete merged branches.
  • Continuously synchronize feature branches.
  • Validate deployments before merging.

DP-800 Exam Tips

Remember the following:

  • Feature branches isolate work.
  • Pull requests enable code review and automated validation.
  • Branch protection prevents unauthorized changes.
  • Merge conflicts require manual resolution.
  • Short-lived branches reduce conflicts.
  • CI pipelines should validate SQL Database Projects before merge.
  • SQL Database Projects work naturally with GitHub and Azure DevOps.
  • Automated testing should occur before deployment.
  • Merge strategies affect repository history but not database functionality.
  • Database schema changes should always originate from source-controlled projects.

Practice Exam Questions

Question 1

A development team wants to ensure that database schema changes are reviewed before being merged into the production branch. Which Git feature should they use?

A. Git tags

B. Pull requests

C. Git stash

D. Detached HEAD

Answer: B

Explanation: Pull requests provide a structured review process that allows team members to examine database changes, discuss modifications, run automated validation, and approve changes before merging.

Question 2

A developer needs to implement a new stored procedure without affecting the stability of the production branch. What is the recommended approach?

A. Commit directly to the main branch

B. Modify the production database directly

C. Create a feature branch

D. Disable branch protection

Answer: C

Explanation: Feature branches isolate development work, allowing changes to be tested and reviewed independently before being merged.

Question 3

What is the primary purpose of branch protection rules?

A. Encrypt the Git repository

B. Prevent unauthorized or unreviewed changes to important branches

C. Improve SQL query performance

D. Automatically resolve merge conflicts

Answer: B

Explanation: Branch protection policies enforce requirements such as pull requests, reviewer approvals, and successful build validation before changes are merged.

Question 4

Two developers modify the same table definition in separate branches. Git cannot determine which version should be kept during the merge. What has occurred?

A. Branch rebasing

B. Repository corruption

C. Detached HEAD

D. Merge conflict

Answer: D

Explanation: A merge conflict occurs when Git cannot automatically reconcile competing changes made to the same portion of a file.

Question 5

Which branching strategy typically uses a single production branch with short-lived feature branches and continuous integration?

A. GitHub Flow

B. Waterfall branching

C. Circular branching

D. Centralized version control

Answer: A

Explanation: GitHub Flow emphasizes a simple workflow consisting of feature branches, pull requests, continuous integration, and frequent deployment.

Question 6

What is the greatest benefit of keeping feature branches short-lived?

A. They eliminate the need for pull requests.

B. They reduce the likelihood of merge conflicts.

C. They prevent database backups.

D. They automatically optimize SQL queries.

Answer: B

Explanation: Frequent integration minimizes divergence between branches, making merges simpler and reducing the risk of conflicts.

Question 7

Which activity is commonly performed automatically when a pull request is opened?

A. Database restoration

B. Manual production deployment

C. Build validation and automated testing

D. SQL Server installation

Answer: C

Explanation: CI pipelines commonly build SQL Database Projects, validate SQL syntax, generate DACPACs, and execute automated tests before allowing a merge.

Question 8

A reviewer notices that a pull request includes unrelated changes to multiple database objects. Which best practice was violated?

A. Protected branches

B. Atomic commits and focused feature branches

C. Continuous deployment

D. Repository cloning

Answer: B

Explanation: Feature branches and commits should focus on a single logical change, making reviews easier and reducing deployment risk.

Question 9

After a pull request has been successfully merged into the main branch, what is the recommended next step for the feature branch?

A. Convert it into the production branch.

B. Rename it as “archive.”

C. Continue developing additional unrelated features.

D. Delete the merged branch.

Answer: D

Explanation: Deleting merged feature branches keeps the repository organized and encourages developers to create fresh branches for new work.

Question 10

During conflict resolution, what should a developer do before completing the merge?

A. Skip testing to save time.

B. Delete both conflicting changes.

C. Rebuild the SQL Database Project and validate the merged changes.

D. Commit the conflict markers to the repository.

Answer: C

Explanation: After resolving conflicts, the project should be rebuilt and validated to ensure the merged schema compiles successfully and behaves as expected before the merge is finalized.

Go to the DP-800 Exam Prep Hub main page

Data Development, Data Governance, Databases, DP-800, Microsoft Certification

Configure source control for SQL Database Projects (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
      --> Configure source control for SQL Database Projects

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

Modern database development follows the same software engineering principles as application development. Rather than making changes directly in production databases, database objects are stored as source code, versioned, reviewed, tested, and deployed through automated pipelines.

SQL Database Projects provide a declarative approach to database development, where the desired database schema is maintained as source-controlled code. The database project becomes the single source of truth, and deployment tools compare the project with the target database to determine the required changes.

For the DP-800: Developing AI-Enabled Database Solutions certification exam, you should understand:

  • Why source control is essential
  • How SQL Database Projects integrate with Git
  • Repository structure
  • Branching strategies
  • Pull requests and code reviews
  • Handling schema changes
  • Managing deployment artifacts
  • Best practices for collaborative development
  • Integration with Azure DevOps and GitHub

Why Source Control Matters

Without source control:

  • Database scripts become scattered.
  • Multiple developers overwrite one another’s work.
  • Changes cannot be audited.
  • Rollbacks are difficult.
  • Production drift becomes common.

Source control provides:

  • Version history
  • Change tracking
  • Collaboration
  • Branching
  • Merging
  • Code reviews
  • Automated deployment
  • Rollback capability
  • Compliance auditing

Instead of the database being the authoritative copy, the SQL Database Project stored in Git becomes the authoritative definition.

SQL Database Projects Overview

A SQL Database Project stores database objects as files.

Typical objects include:

  • Tables
  • Views
  • Stored procedures
  • Functions
  • Triggers
  • Users
  • Roles
  • Schemas
  • Security objects
  • Static data scripts

When the project is built:

  • A DACPAC is generated.
  • Deployment compares the DACPAC with the target database.
  • Required schema changes are produced automatically.

Supported Source Control Systems

Microsoft primarily supports:

  • GitHub
  • Azure Repos (Azure DevOps)
  • Local Git repositories

Older systems such as Team Foundation Version Control (TFVC) are largely superseded by Git for modern development.

Typical Repository Structure

A repository commonly contains:

DatabaseProject/
    Database.sqlproj
    Tables/
        Customers.sql
        Orders.sql
    Views/
        vwSales.sql
    Stored Procedures/
        uspInsertOrder.sql
    Functions/
    Security/
    PostDeployment/
    PreDeployment/
    RefData/
    .gitignore
    README.md

Organizing objects into logical folders makes navigation and maintenance easier.

Initializing Git

After creating a SQL Database Project:

  1. Initialize Git.
  2. Create the repository.
  3. Commit the initial project.
  4. Push to GitHub or Azure DevOps.
  5. Begin collaborative development.

Typical workflow:

Create Project
↓
Initialize Git
↓
Commit
↓
Push
↓
Create Branches
↓
Develop
↓
Pull Request
↓
Merge
↓
Deploy

Git Ignore Files

A .gitignore file prevents unnecessary files from entering source control.

Common exclusions include:

  • bin/
  • obj/
  • build outputs
  • temporary files
  • IDE cache files
  • user-specific settings

Only source code should be versioned.

What Should Be Stored in Git?

Typically stored:

  • SQL object definitions
  • SQL project file
  • Pre-deployment scripts
  • Post-deployment scripts
  • Static data scripts
  • Build configuration
  • Documentation
  • CI/CD pipeline definitions

Usually not stored:

  • DACPAC outputs
  • Temporary files
  • Build artifacts
  • IDE-generated cache
  • Local configuration files
  • Secrets
  • Passwords
  • Connection strings containing credentials

Branching Strategy

Most organizations use a branching strategy.

Example:

main
├── develop
│      ├── feature/customer-table
│      ├── feature/new-index
│      ├── bugfix/login
│      └── feature/security

Benefits include:

  • Parallel development
  • Safer releases
  • Easier testing
  • Isolated changes

Common Git Workflow

Developer workflow:

Pull latest code
↓
Create feature branch
↓
Modify SQL objects
↓
Build project
↓
Run tests
↓
Commit
↓
Push
↓
Open Pull Request
↓
Review
↓
Merge
↓
CI/CD deployment

Pull Requests

Pull requests (PRs) are central to database DevOps.

A PR allows reviewers to:

  • Inspect schema changes
  • Validate naming conventions
  • Review indexes
  • Evaluate security
  • Check performance
  • Ensure coding standards

This reduces production issues.

Merge Conflicts

Multiple developers may modify the same object.

Example:

Developer A edits:

Customers.sql

Developer B edits:

Customers.sql

Git cannot automatically determine which change is correct.

Conflict resolution requires:

  • Reviewing differences
  • Selecting the correct version
  • Combining changes
  • Testing
  • Rebuilding the project

Commit Best Practices

Good commit messages describe why changes were made.

Good examples:

Add CustomerStatus lookup table
Create uspProcessOrders procedure
Add index for OrderDate queries
Implement row-level security
Fix foreign key constraint

Poor examples:

Changes
Stuff
Update
Fix
Work

Atomic Commits

Each commit should represent a single logical change.

Good:

Commit 1

Add Customer table

Commit 2

Create stored procedure

Commit 3

Add index

Bad:

200 unrelated changes

Atomic commits simplify reviews and rollbacks.

Reviewing Schema Changes

Before merging:

Review:

  • New tables
  • New columns
  • Dropped columns
  • Constraint changes
  • Index additions
  • Foreign keys
  • Permissions
  • Views
  • Stored procedures

Ensure no unintended schema changes exist.

Database Drift

Database drift occurs when production changes bypass source control.

Example:

Developer directly executes:

ALTER TABLE Customers
ADD PhoneNumber VARCHAR(20)

The SQL Database Project remains unchanged.

Consequences:

  • Future deployments may remove the column.
  • Schema becomes inconsistent.
  • Production no longer matches source control.

Best practice:

All changes originate in the SQL Database Project.

Working with Azure DevOps

Azure DevOps integrates SQL Database Projects with:

  • Azure Repos
  • Azure Pipelines
  • Pull Requests
  • Branch Policies
  • Work Items
  • Release Pipelines

Typical flow:

Developer
↓
Azure Repos
↓
Pull Request
↓
Build Pipeline
↓
Validation
↓
Merge
↓
Release Pipeline
↓
Azure SQL Database

Working with GitHub

GitHub supports:

  • Git repositories
  • Pull requests
  • Protected branches
  • GitHub Actions
  • Issue tracking
  • Code review
  • Automated deployments

GitHub Actions can automatically:

  • Build SQL Database Projects
  • Generate DACPAC files
  • Execute validation
  • Deploy to staging
  • Deploy to production after approval

Branch Protection

Production branches should be protected.

Common policies:

  • Pull request required
  • Minimum reviewers
  • Successful build required
  • No direct commits
  • Signed commits (optional)
  • Required status checks

This greatly improves deployment quality.

Handling Secrets

Never commit:

  • SQL passwords
  • Azure keys
  • API keys
  • Tokens
  • Certificates
  • Connection strings with credentials

Instead use:

  • Azure Key Vault
  • GitHub Secrets
  • Azure DevOps Variable Groups
  • Managed Identity

CI/CD Integration

Source control enables continuous integration.

Typical process:

Commit
↓
Build
↓
Validate SQL
↓
Run Tests
↓
Create DACPAC
↓
Publish Artifact
↓
Deploy Dev
↓
Deploy Test
↓
Deploy Production

Source Control Best Practices

Microsoft recommends:

  • Keep database definitions in Git.
  • Use feature branches.
  • Require pull requests.
  • Keep commits small.
  • Review schema changes.
  • Build every commit.
  • Automate deployments.
  • Protect production branches.
  • Never commit secrets.
  • Use SQL Database Projects as the source of truth.
  • Avoid direct production changes.
  • Keep repository structure organized.

DP-800 Exam Tips

Remember these key points:

  • SQL Database Projects integrate naturally with Git.
  • GitHub and Azure DevOps are the primary source control platforms.
  • Use feature branches instead of committing directly to main.
  • Protect production branches with policies.
  • Pull requests enable peer review.
  • Source control prevents database drift.
  • Build validation should occur before merging.
  • Store database definitions—not deployed databases—in source control.
  • Secrets belong in secure secret stores, not Git repositories.
  • CI/CD pipelines should deploy from source-controlled SQL Database Projects.

Practice Exam Questions

Question 1

A development team wants every database schema change to be reviewed before deployment. Which Git feature best supports this requirement?

A. Git tags

B. Pull requests

C. Local branches

D. Git stash

Answer: B

Explanation:
Pull requests enable peer review, discussion, automated validation, and approval before changes are merged into protected branches.

Question 2

Which item should generally NOT be committed to a SQL Database Project repository?

A. Stored procedures

B. Table definitions

C. Build output DACPAC files

D. Database project file

Answer: C

Explanation:
Build artifacts such as generated DACPAC files can be recreated and are typically excluded via .gitignore.

Question 3

A developer needs to implement a new reporting view without affecting ongoing work by teammates. What is the recommended approach?

A. Commit directly to the main branch

B. Modify the production database first

C. Create a feature branch

D. Disable branch protection

Answer: C

Explanation:
Feature branches isolate development work, allowing changes to be tested and reviewed before merging.

Question 4

What is the primary purpose of branch protection rules?

A. Improve query execution speed

B. Encrypt repository contents

C. Automatically resolve merge conflicts

D. Prevent unauthorized or unreviewed changes to critical branches

Answer: D

Explanation:
Branch protection enforces policies such as required reviews and successful builds before changes can be merged.

Question 5

A production database contains schema changes that were made directly using SQL Server Management Studio instead of through the SQL Database Project. This situation is known as:

A. Database drift

B. Schema normalization

C. Dependency injection

D. Continuous deployment

Answer: A

Explanation:
Database drift occurs when deployed databases differ from the schema defined in source control.

Question 6

Why should commits generally be small and focused?

A. They eliminate the need for testing.

B. They increase deployment speed automatically.

C. They simplify reviews, troubleshooting, and rollbacks.

D. They prevent merge conflicts entirely.

Answer: C

Explanation:
Atomic commits make it easier to understand changes, review code, identify issues, and revert individual modifications if necessary.

Question 7

Where should sensitive connection strings and passwords typically be stored?

A. README.md

B. SQL project file

C. Source-controlled configuration file

D. Azure Key Vault or another secure secret store

Answer: D

Explanation:
Secrets should never be committed to source control. Secure secret management services protect sensitive credentials.

Question 8

Which activity is commonly performed automatically by a CI pipeline after code is committed?

A. Manual code review

B. Physical database backup

C. Building the SQL Database Project and validating it

D. Creating user accounts

Answer: C

Explanation:
Continuous Integration pipelines commonly build the project, validate the schema, execute automated tests, and produce deployment artifacts.

Question 9

What is the primary benefit of using pull requests for SQL Database Projects?

A. They provide structured code review before merging changes.

B. They replace source control.

C. They eliminate the need for deployment pipelines.

D. They permanently lock database objects.

Answer: A

Explanation:
Pull requests facilitate collaboration, improve code quality, and ensure that schema changes are reviewed before becoming part of the main codebase.

Question 10

Which statement best describes the role of a SQL Database Project in a DevOps workflow?

A. It stores only database backups.

B. It replaces Git repositories.

C. It serves as the authoritative, source-controlled definition of the database schema.

D. It is used only during production deployment.

Answer: C

Explanation:
In modern database DevOps, the SQL Database Project is the single source of truth for the database schema. Deployment tools compare this project with target databases to generate the required schema changes automatically.

Go to the DP-800 Exam Prep Hub main page