Tag: Microsoft Certification

Configure REST or GraphQL endpoints (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%)
   --> Integrate SQL solutions with Azure services
      --> Configure REST or GraphQL endpoints


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 applications rarely connect directly to a database. Instead, they communicate with APIs that provide a secure, scalable, and well-defined interface for accessing and modifying data. Microsoft Data API Builder (DAB) simplifies this process by automatically exposing SQL Server and Azure SQL Database objects through REST and GraphQL endpoints with minimal custom code.

For the DP-800: Developing AI-Enabled Database Solutions certification exam, candidates should understand how to configure and secure REST and GraphQL endpoints, determine when each API style is appropriate, configure authentication and authorization, expose database objects as entities, and optimize endpoint performance.

This topic builds on previous areas such as configuring entities and Data API Builder configuration files. While entities define what database objects are exposed, endpoints determine how applications interact with those objects.


Learning Objectives

After completing this topic, you should be able to:

  • Explain the purpose of REST and GraphQL endpoints.
  • Understand how Data API Builder exposes SQL data.
  • Configure REST endpoints.
  • Configure GraphQL endpoints.
  • Understand endpoint routing.
  • Configure CRUD operations.
  • Secure API endpoints.
  • Implement authentication and authorization.
  • Optimize endpoint performance.
  • Choose between REST and GraphQL for various scenarios.
  • Troubleshoot common endpoint issues.

Why APIs Are Important

Without APIs:

Application
Direct Database Connection
SQL Database

Applications require:

  • Database credentials
  • Knowledge of table structures
  • SQL query logic
  • Network connectivity to the database

This approach introduces security and maintenance challenges.

With Data API Builder:

Application
REST / GraphQL API
Data API Builder
Azure SQL Database

Benefits include:

  • Simplified development
  • Better security
  • Centralized authentication
  • Controlled data exposure
  • Consistent API design
  • Easier scalability

Understanding REST

REST (Representational State Transfer) is an architectural style that exposes resources through HTTP methods.

Common HTTP verbs include:

MethodPurpose
GETRetrieve data
POSTCreate data
PUTReplace an existing resource
PATCHUpdate part of a resource
DELETERemove data

Example:

GET /api/products

returns:

[
{
"ProductID":1,
"Name":"Laptop"
}
]

REST Endpoint Structure

Typical endpoint format:

https://server/api/entity

Examples:

GET /api/customers
GET /api/orders
POST /api/products
PATCH /api/orders/25
DELETE /api/customers/10

REST uses URLs to identify resources.


Understanding GraphQL

GraphQL is a query language developed to allow clients to request exactly the data they require.

Unlike REST, GraphQL typically uses a single endpoint.

Example:

/graphql

The client submits queries.

Example:

query {
products {
Name
Price
}
}

Only the requested fields are returned.


REST vs. GraphQL

FeatureRESTGraphQL
EndpointsMultipleUsually one
Data returnedFixed by endpointClient specifies fields
Over-fetchingPossibleMinimized
Under-fetchingPossibleRare
CRUD supportNative HTTP verbsQueries and mutations
Learning curveLowerSlightly higher
CachingExcellent HTTP supportMore complex

Neither approach is universally better.

Microsoft expects developers to choose the appropriate API based on application requirements.


Data API Builder Architecture

Data API Builder sits between applications and the database.

Application
REST / GraphQL
Data API Builder
Azure SQL Database

Responsibilities include:

  • Endpoint generation
  • Authentication
  • Authorization
  • SQL execution
  • CRUD operations
  • Entity mapping
  • Relationship handling

Configuring REST Endpoints

REST endpoints are enabled within the Data API Builder configuration.

Developers specify:

  • Entity
  • Source table
  • Permissions
  • Allowed operations

Example concept:

Entity
Customers
REST Enabled

Automatically creates endpoints similar to:

GET /api/customers
POST /api/customers
PATCH /api/customers/15
DELETE /api/customers/15

Configuring GraphQL Endpoints

When GraphQL is enabled, Data API Builder generates a GraphQL schema automatically.

Example query:

query {
customers {
CustomerName
City
}
}

Mutation example:

mutation {
createCustomer(...)
}

Developers do not manually write the GraphQL schema.


Endpoint Routing

Routing determines how incoming requests reach the appropriate entity.

REST example:

/api/products

Routes to:

Products Entity

GraphQL example:

/GraphQL

Routes all requests through:

GraphQL Engine

The GraphQL engine determines which entities participate in the query.


CRUD Operations

Data API Builder supports CRUD operations.

OperationRESTGraphQL
CreatePOSTMutation
ReadGETQuery
UpdatePATCH/PUTMutation
DeleteDELETEMutation

Organizations often disable unnecessary operations.

Example:

Internal reporting API:

Allowed:

  • GET

Disabled:

  • POST
  • PATCH
  • DELETE

This reduces security risks.


Endpoint Configuration Best Practices

Microsoft recommends exposing only the endpoints required by the application.

Good practices include:

  • Enable only necessary entities.
  • Disable unnecessary CRUD operations.
  • Hide internal tables.
  • Use descriptive endpoint names.
  • Keep URL structures consistent.
  • Avoid exposing sensitive objects.

Authentication

Authentication answers:

Who is making the request?

Common authentication methods include:

  • Microsoft Entra ID
  • Managed Identity
  • JWT Bearer Tokens
  • OAuth 2.0
  • API keys (where appropriate)

Microsoft strongly recommends Microsoft Entra ID for Azure-hosted solutions.


Microsoft Entra ID Integration

Data API Builder integrates with Microsoft Entra ID.

Authentication flow:

User
Microsoft Entra ID
Access Token
REST / GraphQL
Data API Builder
Azure SQL Database

Benefits include:

  • Single sign-on
  • Central identity management
  • Multi-factor authentication
  • Conditional Access
  • Token-based authentication

Authorization

Authentication determines identity.

Authorization determines permissions.

Example:

Developer:

Can:

  • Read
  • Update

Auditor:

Can:

  • Read only

Guest:

Can:

  • View public data only

Authorization should follow the principle of least privilege.


Endpoint Security

APIs should never expose more information than necessary.

Security recommendations include:

  • Use HTTPS exclusively.
  • Require authentication.
  • Use Microsoft Entra ID where possible.
  • Implement role-based authorization.
  • Validate client input.
  • Disable unused operations.
  • Avoid exposing sensitive columns.
  • Log API access.
  • Monitor suspicious activity.

Protecting Sensitive Data

Poor API:

Employee
Name
Salary
SSN
PasswordHash

Better API:

Employee
Name
Department
Title

Sensitive fields should remain inaccessible.

Often this is accomplished through:

  • Database views
  • Entity configuration
  • Role-based permissions

Error Handling

REST commonly returns HTTP status codes.

Examples:

CodeMeaning
200Success
201Created
400Bad Request
401Unauthorized
403Forbidden
404Not Found
500Internal Server Error

Applications should use these responses to handle failures appropriately.


GraphQL Error Responses

GraphQL responses may contain both successful data and error information.

Example concept:

{
"data": {
"products": null
},
"errors": [
{
"message":"Unauthorized"
}
]
}

Unlike REST, GraphQL often returns HTTP 200 while including error details in the response body.

Developers should inspect both the HTTP status code and the GraphQL response payload.


Performance Considerations

Well-designed endpoints improve application performance.

Recommendations include:

  • Return only required data.
  • Filter data at the database.
  • Use pagination.
  • Cache relatively static responses.
  • Index frequently searched columns.
  • Avoid returning excessively large result sets.
  • Reduce unnecessary joins.

GraphQL helps minimize over-fetching because clients specify the required fields.


REST Performance

REST benefits from mature HTTP infrastructure.

Advantages include:

  • Browser caching
  • Proxy caching
  • Azure Front Door
  • Azure API Management caching
  • CDN support

REST is often preferred for:

  • Public APIs
  • High-volume read workloads
  • Static content
  • Mobile applications

GraphQL Performance

GraphQL reduces unnecessary network traffic.

Instead of:

GET Customer
GET Orders
GET Products

A single GraphQL query can retrieve all related information.

Example:

{
customer(id:1){
Name
Orders{
OrderDate
Total
}
}
}

This minimizes the number of client-server round trips.


Monitoring Endpoints

Production APIs should be monitored continuously.

Useful Azure services include:

  • Azure Monitor
  • Application Insights
  • Log Analytics
  • Azure API Management analytics

Monitor:

  • Request counts
  • Response times
  • Error rates
  • Authentication failures
  • Throughput
  • Latency

These metrics help identify bottlenecks and security issues.


Common DP-800 Exam Scenarios

You should be comfortable answering questions such as:

  • When should REST be preferred over GraphQL?
  • When is GraphQL more efficient than REST?
  • How are CRUD operations exposed through each API style?
  • Why should unnecessary CRUD operations be disabled?
  • Which authentication mechanism is recommended for Azure-hosted APIs?
  • How should endpoint authorization be implemented?
  • How can API performance be improved?
  • Why is HTTPS required?
  • How does GraphQL reduce over-fetching?
  • What monitoring information should be collected for production APIs?

DP-800 Exam Tips

  • Know the differences between REST and GraphQL.
  • Understand how Data API Builder automatically generates endpoints.
  • Remember that REST typically uses multiple endpoints, while GraphQL commonly uses a single endpoint.
  • Understand the mapping between CRUD operations and HTTP verbs.
  • Recognize the importance of Microsoft Entra ID authentication.
  • Apply least-privilege authorization principles.
  • Use HTTPS for all endpoint communication.
  • Know when GraphQL reduces over-fetching and when REST benefits from HTTP caching.
  • Understand how endpoint configuration affects security, scalability, and performance.

Summary

Configuring REST and GraphQL endpoints is a core competency for developers building modern SQL-backed applications with Microsoft Data API Builder. REST provides resource-oriented endpoints that align naturally with HTTP methods and benefit from widespread tooling and caching support. GraphQL offers a flexible query model that enables clients to retrieve exactly the data they need, reducing over-fetching and minimizing network traffic.

For the DP-800 exam, candidates should understand how Data API Builder automatically generates these endpoints from configured entities, how CRUD operations map to each API style, how to secure endpoints using Microsoft Entra ID and role-based authorization, and how to optimize performance through pagination, filtering, caching, and efficient query design. Mastering these concepts enables developers to build secure, scalable, and maintainable APIs that integrate SQL databases with modern cloud-native applications.


Practice Exam Questions


Question 1

You are deploying Microsoft Data API builder in front of an Azure SQL Database. The security team requires that users authenticate with Microsoft Entra ID before accessing either the REST or GraphQL endpoints.

Which authentication provider should you configure?

A. Anonymous authentication

B. Microsoft Entra ID authentication

C. Basic Authentication

D. SQL Authentication

Correct Answer:

B. Microsoft Entra ID authentication

Explanation

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s recommended authentication mechanism for cloud services. Data API builder supports Microsoft Entra ID authentication, enabling secure token-based authentication for both REST and GraphQL endpoints.

Why the other answers are incorrect:

  • A: Anonymous authentication provides no identity validation.
  • C: Basic authentication transmits usernames and passwords and is generally discouraged.
  • D: SQL Authentication secures the database connection but is not intended for authenticating API consumers.

Question 2

A development team wants consumers of a REST endpoint to retrieve data using standard HTTP semantics.

Which HTTP method should clients use when reading data?

A. POST

B. PUT

C. GET

D. DELETE

Correct Answer:

C. GET

Explanation

REST follows standard HTTP conventions.

  • GET retrieves data.
  • POST creates resources.
  • PUT replaces existing resources.
  • DELETE removes resources.

Using the appropriate HTTP method improves interoperability and aligns with REST best practices.


Question 3

A GraphQL endpoint exposes Customer information.

A client application only requires the customer’s first name and email address.

What is the primary advantage of GraphQL in this scenario?

A. GraphQL automatically encrypts returned data.

B. GraphQL always executes faster than REST.

C. GraphQL allows clients to request only the required fields.

D. GraphQL eliminates authentication requirements.

Correct Answer:

C. GraphQL allows clients to request only the required fields.

Explanation

GraphQL enables clients to specify exactly which fields should be returned, reducing unnecessary data transfer and improving application efficiency.

The other options are incorrect because:

  • GraphQL does not provide encryption.
  • Performance depends on workload.
  • Authentication remains necessary.

Question 4

An organization wants to expose only the Products table through Data API builder.

The Orders and Customers tables must never be accessible.

What is the best configuration?

A. Configure only the Products entity in the DAB configuration.

B. Create views for all tables.

C. Grant db_owner permissions.

D. Disable GraphQL.

Correct Answer:

A. Configure only the Products entity in the DAB configuration.

Explanation

Only configured entities become accessible through DAB endpoints. Tables not defined in the configuration cannot be queried through the generated APIs.

Granting broad database permissions or disabling GraphQL does not prevent REST access.


Question 5

A developer receives HTTP 401 Unauthorized when calling a secured REST endpoint.

Which issue is the most likely cause?

A. The endpoint uses HTTPS.

B. The client failed to provide a valid authentication token.

C. The SQL query contains joins.

D. Pagination is enabled.

Correct Answer:

B. The client failed to provide a valid authentication token.

Explanation

HTTP 401 indicates that authentication failed or credentials were not supplied.

Typical causes include:

  • Missing bearer token
  • Expired token
  • Invalid token
  • Incorrect authentication configuration

The remaining options are unrelated to authentication failures.


Question 6

Your organization wants GraphQL clients to create new database records.

Which GraphQL operation should the clients perform?

A. Query

B. Subscription

C. Mutation

D. Schema

Correct Answer:

C. Mutation

Explanation

GraphQL defines three primary operation types:

  • Query → Read data
  • Mutation → Insert, update, or delete data
  • Subscription → Receive real-time updates (where supported)

Creating records is accomplished using mutations.


Question 7

An application experiences slower response times because every request repeatedly retrieves identical reference data.

Which feature would most likely improve endpoint performance?

A. Increase SQL authentication timeout.

B. Enable response caching where appropriate.

C. Replace GraphQL with SOAP.

D. Disable indexes.

Correct Answer:

B. Enable response caching where appropriate.

Explanation

Caching reduces repeated database reads for frequently requested data.

Benefits include:

  • Lower latency
  • Reduced database workload
  • Improved scalability

Disabling indexes would significantly reduce performance.


Question 8

Which statement best describes GraphQL schemas?

A. They define the structure of available queries, mutations, and data types.

B. They replace SQL indexes.

C. They encrypt REST endpoints.

D. They create database backups.

Correct Answer:

A. They define the structure of available queries, mutations, and data types.

Explanation

The GraphQL schema acts as the contract between clients and the API.

It specifies:

  • Available object types
  • Fields
  • Queries
  • Mutations
  • Relationships

It does not manage indexing, encryption, or backups.


Question 9

Your organization deploys Data API builder to production.

Which practice best protects REST and GraphQL endpoints?

A. Enable anonymous access for easier testing.

B. Store secrets directly in configuration files.

C. Require HTTPS and strong authentication.

D. Disable authorization checks.

Correct Answer:

C. Require HTTPS and strong authentication.

Explanation

Production APIs should always:

  • Use HTTPS
  • Authenticate users
  • Authorize requests
  • Protect credentials
  • Follow least-privilege principles

Anonymous access and embedded secrets introduce significant security risks.


Question 10

A developer modifies a Data API builder configuration file by adding a new entity.

What must occur before clients can use the new endpoint?

A. Restart or redeploy the Data API builder service so the updated configuration is loaded.

B. Rebuild the Azure SQL Database.

C. Delete the GraphQL schema.

D. Recreate the database indexes.

Correct Answer:

A. Restart or redeploy the Data API builder service so the updated configuration is loaded.

Explanation

After modifying the DAB configuration, the running service must reload the updated configuration. Depending on the hosting environment, this typically involves restarting the application or redeploying the container or service.

Database rebuilding, deleting the GraphQL schema, and recreating indexes are unrelated to exposing newly configured endpoints.


Exam Tips for DP-800

For the exam, you should be comfortable with:

  • Configuring REST and GraphQL endpoints using Microsoft Data API builder.
  • Understanding REST HTTP methods (GET, POST, PUT/PATCH, DELETE).
  • Understanding GraphQL queries, mutations, and schemas.
  • Configuring Microsoft Entra ID authentication.
  • Applying authorization using database permissions and DAB configuration.
  • Exposing only intended database objects.
  • Using HTTPS to secure endpoint communications.
  • Improving performance through caching and efficient endpoint design.
  • Deploying configuration changes safely.
  • Understanding the differences and appropriate use cases for REST versus GraphQL.

Go to the DP-800 Exam Prep Hub main page

Configure entities for REST and GraphQL, including data caching, pagination, searching, and filtering (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%)
   --> Integrate SQL solutions with Azure services
      --> Configure entities for REST and GraphQL, including data caching, pagination, searching, and filtering


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 applications increasingly expose data through APIs rather than allowing applications to connect directly to databases. APIs provide a secure abstraction layer that simplifies application development while protecting the underlying database.

For the DP-800 certification, Microsoft expects candidates to understand how Data API Builder (DAB) exposes SQL Server and Azure SQL Database objects through automatically generated REST and GraphQL endpoints. Candidates should know how to configure entities, control which operations are available, implement pagination, filtering, searching, caching, relationships, and understand the security implications of exposing database objects through APIs.

Unlike traditional custom-built APIs that require significant development effort, Data API Builder allows developers to expose database objects by using a configuration file. Developers describe database objects as entities, define the allowed operations, and configure API behavior.

Understanding entity configuration is an important skill because it enables organizations to rapidly build secure, scalable APIs without writing extensive backend code.


Learning Objectives

After completing this topic, you should be able to:

  • Explain how Data API Builder exposes SQL data.
  • Configure entities in a DAB configuration file.
  • Expose entities through REST and GraphQL.
  • Configure CRUD operations.
  • Configure relationships between entities.
  • Implement pagination.
  • Configure filtering and searching.
  • Configure sorting.
  • Understand caching behavior.
  • Apply security best practices.

What is Data API Builder (DAB)?

Data API Builder is an open-source Microsoft service that automatically creates REST and GraphQL APIs for relational databases.

Supported databases include:

  • Azure SQL Database
  • SQL Server
  • Azure SQL Managed Instance
  • Azure Database for PostgreSQL
  • Azure Cosmos DB (NoSQL support in certain scenarios)

Rather than developing controllers and endpoints manually, developers define a configuration file that describes:

  • Database connection
  • Authentication
  • Authorization
  • Entities
  • API settings
  • Runtime behavior

DAB automatically generates the endpoints.

Example architecture:

Application
REST / GraphQL
Data API Builder
Azure SQL Database

Why Use Data API Builder?

Benefits include:

  • Rapid API development
  • Less custom code
  • Built-in GraphQL
  • Automatic REST endpoints
  • Security integration
  • Microsoft Entra authentication
  • Managed Identity support
  • Authorization rules
  • Entity relationships
  • Simplified deployment

For many internal business applications, DAB eliminates the need to build an entire ASP.NET Web API project.


Understanding Entities

An entity represents a database object that Data API Builder exposes through an API.

Typically an entity maps to:

  • Table
  • View
  • Stored procedure (REST only in specific scenarios)

Example database:

Customers
CustomerID
FirstName
LastName
Email

Entity configuration:

Customers

Automatically becomes

REST

GET /api/Customers
POST /api/Customers
GET /api/Customers/{id}

GraphQL

customers
customer_by_pk
createCustomer
updateCustomer
deleteCustomer

Entity Configuration Basics

Each entity is defined inside the configuration file.

Typical properties include:

  • Source object
  • Permissions
  • REST settings
  • GraphQL settings
  • Relationships
  • Fields
  • Operations

Conceptually:

Entity
Source Table
REST enabled
GraphQL enabled
Permissions
Relationships

Entity Source

The source identifies the database object.

Examples include:

  • Table
  • View

Example concept:

Entity
Product
Source
dbo.Products

The entity name does not have to match the table name.

Example:

Database table

SalesOrders

Exposed as

Orders

This abstraction creates cleaner APIs.


Exposing REST Endpoints

REST endpoints are enabled per entity.

Typical operations include:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE

Example endpoints:

GET /api/products
GET /api/products/10
POST /api/products
PATCH /api/products/10
DELETE /api/products/10

Developers can disable operations they do not want clients to perform.

Example:

Allow:

  • GET

Disable:

  • DELETE

This creates read-only APIs.


Exposing GraphQL Endpoints

When GraphQL is enabled, DAB generates a GraphQL schema automatically.

Example query:

query
{
books
{
BookID
Title
Price
}
}

Mutation example:

mutation
{
createBook(...)
}

GraphQL allows clients to request exactly the fields they need.

Example:

{
products
{
Name
Price
}
}

instead of

SELECT *

This reduces network traffic.


Configuring CRUD Operations

Each entity can expose one or more CRUD operations.

Supported operations include:

OperationRESTGraphQL
CreateYesYes
ReadYesYes
UpdateYesYes
DeleteYesYes

Organizations frequently expose:

  • Read
  • Create

while disabling:

  • Delete

to protect data.


Primary Keys

Entities require primary keys for many operations.

Example

CustomerID

REST endpoint

GET /api/customers/25

GraphQL

customer_by_pk

Without a primary key:

  • Updates become difficult
  • Deletes become difficult
  • Relationships cannot always be generated

Composite Keys

Some tables use multiple columns as a primary key.

Example

OrderID
ProductID

REST requests must uniquely identify both values.

GraphQL also requires all key fields.

Candidates should understand that Data API Builder supports composite keys but requires complete key values for entity identification.


Entity Relationships

Relationships allow clients to retrieve related data.

Database:

Customers
Orders

Relationship

Customer
Many Orders

GraphQL example:

{
customers
{
CustomerName
orders
{
OrderDate
Total
}
}
}

REST clients can also retrieve related resources depending on configuration.

Relationships reduce the need for multiple API requests.


Data Caching

Caching improves API performance by reducing repeated database queries.

Although Data API Builder itself is intentionally lightweight, caching can be implemented through surrounding Azure services such as:

  • Azure Front Door
  • Azure API Management
  • Azure CDN
  • Reverse proxy caches
  • Client-side caching
  • HTTP caching headers

Benefits include:

  • Lower latency
  • Reduced database load
  • Better scalability
  • Faster responses

Example

Without cache:

1000 requests
1000 SQL queries

With cache:

1000 requests
50 SQL queries
950 cached responses

Caching is especially useful for:

  • Product catalogs
  • Reference data
  • Geographic lookup tables
  • Public information
  • Configuration data

It is generally less appropriate for frequently changing transactional data.


Pagination

Returning every row from a large table is inefficient.

Pagination divides results into smaller pages.

Example

Instead of:

100,000 rows

Return:

100 rows
Page 1

then

Page 2
Page 3
Page 4

Benefits include:

  • Faster response time
  • Lower memory usage
  • Better user experience
  • Reduced network traffic

Common pagination parameters include:

Page Size
Offset
Limit
Continuation Tokens

GraphQL implementations may also support cursor-based pagination depending on the configuration and client.


Best Practices for Pagination

Microsoft recommends:

Choose reasonable page sizes.

Avoid unlimited result sets.

Return metadata when appropriate, such as:

  • Total records
  • Current page
  • Next page
  • Previous page

Limit maximum page size to prevent excessive resource consumption.

Example:

Good

50 rows

Better

100 rows

Poor

500,000 rows

Filtering

Filtering reduces the number of returned records.

Example:

Products
Price > 100

Instead of every product:

5000 products

Return only

150 products

Examples include:

Category = 'Electronics'
Status = 'Active'
Price > 100
City = 'London'

Benefits:

  • Reduced bandwidth
  • Faster queries
  • Better application performance
  • Improved user experience

Filtering should be pushed to the database whenever possible rather than filtering results in application code after retrieval.


Searching

Searching differs from filtering.

Filtering matches specific conditions.

Searching finds records based on user-provided values.

Example

Search text:

Laptop

Possible matches:

Gaming Laptop
Business Laptop
Laptop Bag

Search operations commonly involve:

  • LIKE
  • Full-text search
  • Prefix searches
  • Keyword searches

Organizations should consider indexing frequently searched columns to improve performance.


Sorting

Sorting determines the order of results.

Examples:

Ascending:

Product Name
A → Z

Descending:

Price
High → Low

Sorting can be combined with:

  • Filtering
  • Pagination
  • Searching

Example workflow:

Products
Filter
Search
Sort
Page Results

Combining these capabilities creates efficient, user-friendly APIs while minimizing unnecessary data transfer.


Performance Considerations

When configuring entities, developers should avoid exposing inefficient queries.

Recommendations include:

  • Use indexed columns for filtering.
  • Paginate large datasets.
  • Avoid returning unnecessary columns.
  • Limit expensive joins.
  • Optimize frequently executed queries.
  • Use appropriate database indexes.
  • Cache relatively static data where appropriate.
  • Monitor API and query performance using Azure monitoring tools and SQL performance features.

Proper entity design directly affects both API responsiveness and database workload.


Security Considerations

Exposing database objects through APIs introduces additional security considerations.

Best practices include:

  • Expose only required tables and views.
  • Disable unnecessary CRUD operations.
  • Use Microsoft Entra ID authentication whenever possible.
  • Implement role-based authorization.
  • Avoid exposing sensitive columns such as passwords, secrets, or internal identifiers.
  • Validate client input.
  • Use HTTPS for all API traffic.
  • Apply the principle of least privilege.
  • Monitor API usage and audit access.

Remember that DAB simplifies API generation but does not replace the need for a comprehensive security strategy.


Common DP-800 Exam Scenarios

You should be comfortable answering questions such as:

  • When should you expose a table as an entity versus creating a custom API?
  • How do REST and GraphQL differ when exposing SQL data?
  • When should pagination be implemented?
  • Which workloads benefit most from API caching?
  • How do filtering and searching differ?
  • Why should delete operations be disabled for certain entities?
  • Why are primary keys required for update and delete operations?
  • How do entity relationships simplify GraphQL queries?
  • Which API design practices improve performance for large datasets?
  • How should security be enforced when exposing database objects through Data API Builder?

Scenario-based questions may ask you to identify the most appropriate configuration for performance, scalability, or security, requiring an understanding of how entity settings affect API behavior.


DP-800 Exam Tips

  • Understand the differences between REST and GraphQL entity exposure.
  • Know how entities map to database tables and views.
  • Be familiar with CRUD operation configuration.
  • Understand why primary keys and relationships are important.
  • Know when to use pagination, filtering, sorting, and searching.
  • Understand that caching is typically implemented by Azure services surrounding DAB rather than by DAB itself.
  • Apply security best practices, including least privilege and selective exposure of database objects.
  • Recognize performance optimization techniques such as indexing filtered columns, limiting result sets, and avoiding over-fetching.

Summary

Configuring entities in Data API Builder is a foundational skill for developing modern SQL-based APIs. By defining entities that map to database objects, developers can automatically expose secure REST and GraphQL endpoints with minimal code. Effective entity configuration includes selecting appropriate CRUD operations, defining relationships, implementing pagination, filtering, searching, and sorting, and designing for scalability and security. For the DP-800 exam, candidates should understand not only how these features work individually but also how they combine to create performant, maintainable, and secure API solutions that integrate SQL databases with modern cloud applications.


Practice Exam Questions


Question 1

A company uses Azure SQL Database to store product information. Developers want to expose product data through Data API Builder. Customers should be able to view products but must not be able to modify or delete product records.

Which configuration should you implement?

A. Enable only the POST operation for the product entity
B. Enable only read operations for the product entity
C. Disable REST and enable GraphQL mutations only
D. Create a stored procedure that handles all product requests

Correct Answer: B

Explanation

Data API Builder allows developers to control which operations are exposed for each entity. If customers should only view product information, the entity should expose read-only access.

A read-only entity configuration allows:

  • GET operations through REST
  • Query operations through GraphQL

but prevents:

  • INSERT
  • UPDATE
  • DELETE

Why the other options are incorrect:

  • A. POST allows creating new records, which violates the requirement.
  • C. GraphQL mutations allow data modification and should not be enabled.
  • D. A stored procedure is unnecessary for this requirement and does not directly address entity permissions.

Question 2

A developer exposes an Orders table as a Data API Builder entity. The table contains 5 million rows. Users need to browse orders through a web application.

What should the developer implement to improve API performance?

A. Return all rows and allow the browser to filter results
B. Disable indexing because APIs handle optimization automatically
C. Implement pagination with reasonable page sizes
D. Duplicate the table into multiple databases

Correct Answer: C

Explanation

Pagination is the appropriate solution when exposing large datasets through APIs.

Benefits include:

  • Reduced response size
  • Lower memory consumption
  • Faster response times
  • Improved user experience

Why the other options are incorrect:

  • A. Returning millions of rows creates unnecessary network and database overhead.
  • B. Indexing remains important for database performance.
  • D. Database duplication does not solve the API result-size problem.

Question 3

A developer creates a GraphQL endpoint using Data API Builder. Users want to retrieve customers and their related orders in a single query.

What should the developer configure?

A. A relationship between the Customer and Order entities
B. A separate database for each entity
C. A REST-only endpoint for the Orders table
D. A SQL Agent job to combine the tables nightly

Correct Answer: A

Explanation

Entity relationships allow related data to be retrieved together, especially through GraphQL queries.

Example:

{
customers {
CustomerName
orders {
OrderDate
}
}
}

The relationship configuration enables Data API Builder to understand how entities are connected.

Why the other options are incorrect:

  • B. Separate databases do not create entity relationships.
  • C. REST-only endpoints do not enable GraphQL relationship queries.
  • D. Scheduled jobs do not provide real-time relational querying.

Question 4

A company exposes a Product entity through Data API Builder. Users frequently search products by product name. Query performance has degraded as the product catalog grows.

What should you do first?

A. Remove filtering capabilities from the API
B. Store product names in an external file
C. Add appropriate database indexing for search columns
D. Increase the API response size limit

Correct Answer: C

Explanation

Search operations frequently depend on database performance. Adding appropriate indexes improves query execution speed for commonly searched columns.

For example:

CREATE INDEX IX_Product_Name
ON Products(ProductName);

Why the other options are incorrect:

  • A. Removing functionality does not solve the performance problem.
  • B. External files are not an appropriate database optimization strategy.
  • D. Increasing response size can make performance worse.

Question 5

A developer wants users to retrieve only active products from a Data API Builder endpoint.

Which capability should be used?

A. Filtering
B. Pagination
C. Caching
D. Sorting

Correct Answer: A

Explanation

Filtering restricts returned records based on conditions.

Example:

Status = 'Active'

Only matching records are returned.

Why the other options are incorrect:

  • B. Pagination controls the number of results returned, not which records qualify.
  • C. Caching improves performance but does not limit returned data.
  • D. Sorting changes order but does not restrict records.

Question 6

An application displays a product catalog. Product information changes only once per day, but thousands of users access the catalog every hour.

What approach provides the greatest performance benefit?

A. Disable indexes on product tables
B. Implement caching for product API responses
C. Return every product column for every request
D. Disable pagination

Correct Answer: B

Explanation

Caching is ideal for frequently accessed, rarely changing data.

Examples of good caching candidates:

  • Product catalogs
  • Reference data
  • Geographic lookup information
  • Configuration settings

Caching reduces repeated database queries and improves scalability.

Why the other options are incorrect:

  • A. Removing indexes reduces performance.
  • C. Returning unnecessary data increases workload.
  • D. Disabling pagination can create large inefficient responses.

Question 7

A developer configures an entity in Data API Builder but update and delete operations fail. The table does not have a primary key.

What is the most likely reason?

A. GraphQL cannot access SQL databases
B. REST endpoints require Azure Functions
C. Entity identification requires a primary key
D. Pagination prevents updates

Correct Answer: C

Explanation

Primary keys allow Data API Builder to uniquely identify individual records.

Operations such as:

  • Update
  • Delete
  • Retrieve by identifier

typically require a primary key.

Example:

GET /api/customers/100

requires knowing which row represents customer 100.

Why the other options are incorrect:

  • A. GraphQL supports SQL data sources.
  • B. REST endpoints do not require Azure Functions.
  • D. Pagination does not prevent updates.

Question 8

A developer creates a REST endpoint for a Customer entity. The application needs to retrieve customers located in a specific city.

Which capability should be used?

A. Sorting
B. Filtering
C. Caching
D. Relationship mapping

Correct Answer: B

Explanation

Filtering returns only records matching specified criteria.

Example:

City = 'Seattle'

The database performs the filtering before returning results.

Why the other options are incorrect:

  • A. Sorting changes ordering only.
  • C. Caching improves performance but does not select records.
  • D. Relationships connect entities but do not filter records.

Question 9

A developer exposes a table containing employee information through Data API Builder. The table contains salary information that should never be visible to API consumers.

What should the developer do?

A. Expose the table but rely on client applications to hide the salary column
B. Create an entity that exposes only required fields
C. Increase the database timeout value
D. Enable caching for the employee table

Correct Answer: B

Explanation

A secure API design exposes only the data required by consumers.

Possible approaches include:

  • Creating database views
  • Limiting exposed fields
  • Configuring entity permissions

Sensitive information should not be sent to clients and hidden only through application logic.

Why the other options are incorrect:

  • A. Client-side hiding is not a security control.
  • C. Timeout settings do not protect sensitive data.
  • D. Caching sensitive data can increase risk.

Question 10

A company uses GraphQL through Data API Builder. Developers want clients to request only the fields they need instead of receiving large unnecessary payloads.

Which GraphQL capability supports this requirement?

A. Field selection in queries
B. Database replication
C. SQL Server Agent scheduling
D. Data compression only

Correct Answer: A

Explanation

One of GraphQL’s primary advantages is allowing clients to specify exactly which fields they need.

Example:

{
products {
Name
Price
}
}

Only the requested fields are returned.

Benefits include:

  • Reduced network traffic
  • Smaller responses
  • Improved application performance

Why the other options are incorrect:

  • B. Replication improves availability but does not control query fields.
  • C. SQL Agent scheduling is unrelated to API responses.
  • D. Compression reduces payload size but does not allow field selection.

Topic Summary

Key concepts tested in this section:

ConceptKey Exam Point
EntitiesMap database objects to API resources
RESTAutomatically exposes HTTP CRUD operations
GraphQLProvides flexible queries and field selection
Primary keysRequired for identifying individual records
RelationshipsEnable related entity retrieval
PaginationImproves performance for large datasets
FilteringLimits returned records
SearchingFinds matching records based on values
SortingControls result ordering
CachingImproves scalability for frequently accessed static data
SecurityExpose only required data and operations

Go to the DP-800 Exam Prep Hub main page

Create configuration files for Data API builder (DAB) – 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%)
   --> Integrate SQL solutions with Azure services
      --> Create configuration files for Data API builder (DAB)


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.

Advanced Entity Configuration

While a basic DAB configuration can expose an entire table with only a few lines of JSON, enterprise applications typically require much more granular control. Developers can customize how entities are exposed, which operations are permitted, and who can access specific data.

Advanced entity configuration allows you to:

  • Rename API endpoints
  • Restrict CRUD operations
  • Configure role-based permissions
  • Expose only selected database objects
  • Map views and stored procedures
  • Customize GraphQL object names
  • Define relationships between entities

This flexibility allows developers to build secure APIs without writing application code.


Configuring Entity Permissions

One of the most important sections of a DAB configuration file is the permissions section.

Example:

"permissions": [
{
"role": "anonymous",
"actions": [ "read" ]
}
]

Permissions determine which operations a role may perform.

Supported actions include:

  • Read
  • Create
  • Update
  • Delete
  • Execute (stored procedures)

For DP-800, understand that permissions are configured at the entity level rather than the database level.


Role-Based Authorization

DAB uses roles to authorize requests after a user has been authenticated.

Example roles might include:

  • anonymous
  • authenticated
  • reader
  • contributor
  • manager
  • administrator

Example:

"permissions": [
{
"role": "reader",
"actions": [ "read" ]
},
{
"role": "administrator",
"actions": [ "create","read","update","delete" ]
}
]

In this example:

Readers can only retrieve data.

Administrators can perform all CRUD operations.


Field-Level Permissions

Some applications should expose only specific columns.

For example:

Employee table

  • EmployeeID
  • Name
  • Department
  • Salary
  • SocialSecurityNumber

Instead of exposing every column, DAB can restrict access through permissions and by configuring the entity to expose only approved fields (combined with database permissions where appropriate).

Although SQL permissions remain the primary security boundary, DAB provides another layer of API security.


Using Views Instead of Tables

Many organizations expose SQL views instead of tables.

Advantages include:

  • Hide sensitive columns
  • Simplify queries
  • Enforce business rules
  • Reduce accidental data exposure

Example

"source": {
"object": "dbo.vwCustomerSummary",
"type": "view"
}

Views are often considered a security best practice.


Exposing Stored Procedures

DAB supports stored procedures as API endpoints.

Example

"source": {
"object": "dbo.GetSalesSummary",
"type": "stored-procedure"
}

REST example

POST /api/GetSalesSummary

GraphQL example

mutation

Stored procedures are especially useful when:

  • Complex business logic exists
  • Multiple tables must be updated
  • Validation is required
  • Reporting queries are expensive

Authentication Providers

Authentication determines who a user is.

Authorization determines what that user may do.

Data API builder supports multiple authentication providers.

Common providers include:

  • Anonymous
  • Microsoft Entra ID
  • Azure Static Web Apps Authentication
  • JSON Web Tokens (JWT)
  • OAuth providers

The authentication provider is configured in the runtime section.


Microsoft Entra ID Authentication

Microsoft recommends Microsoft Entra ID for production environments.

Benefits include:

  • Enterprise identity management
  • Single Sign-On (SSO)
  • Multi-factor authentication
  • Conditional Access
  • Managed identities
  • Centralized security

Using Entra ID reduces the need to manage usernames and passwords within applications.


Azure Static Web Apps Authentication

When DAB is deployed alongside Azure Static Web Apps, authentication can be handled automatically.

Supported providers include:

  • Microsoft
  • GitHub
  • Google
  • X (formerly Twitter) (where supported)
  • Custom OpenID Connect providers

The application receives authenticated user information without requiring developers to implement custom login functionality.


JSON Web Tokens (JWT)

JWT authentication is commonly used in REST APIs.

Workflow:

  1. User authenticates.
  2. Identity provider issues a JWT.
  3. Client sends the JWT with each request.
  4. DAB validates the token.
  5. Permissions are applied.

JWT authentication enables stateless API security.


Managed Identity

Managed Identity is one of Microsoft’s preferred authentication methods for Azure resources.

Instead of storing credentials:

Username
Password

Azure automatically manages an identity for the application.

The application authenticates using Azure Active Directory (Microsoft Entra ID).

Benefits include:

  • No passwords
  • Automatic credential rotation
  • Improved security
  • Easier administration
  • Reduced risk of credential leakage

This is a frequently tested DP-800 topic.


Connecting DAB to Azure SQL with Managed Identity

Typical flow:

Azure App Service
Managed Identity
Microsoft Entra ID
Azure SQL Database

No SQL username or password needs to be stored in the configuration file.


Connection Strings with Managed Identity

Instead of:

Server=...
User ID=admin
Password=...

Developers use an authentication method supported by Azure SQL that relies on Managed Identity (for example, Authentication=Active Directory Managed Identity in the connection string, depending on the client and environment).

Benefits include:

  • No secrets
  • Easier rotation
  • Improved compliance
  • Better security posture

Cross-Origin Resource Sharing (CORS)

Modern web applications often call APIs hosted on different domains.

Example:

Website

https://contoso.com

API

https://api.contoso.com

Without CORS configuration:

Browser blocks the request.

DAB allows developers to configure permitted origins.

Example

Allowed Origins
https://contoso.com

This prevents unauthorized websites from making browser-based requests to the API.


Azure App Service Deployment

DAB is frequently deployed to Azure App Service.

Deployment steps typically include:

  1. Publish DAB.
  2. Upload configuration file.
  3. Configure environment variables.
  4. Configure Managed Identity.
  5. Grant Azure SQL permissions.
  6. Enable HTTPS.
  7. Test REST endpoints.
  8. Test GraphQL endpoints.

Azure Container Apps

Container Apps provide a lightweight alternative to Kubernetes.

Benefits include:

  • Autoscaling
  • Container support
  • Easy deployment
  • Native Azure integration
  • Lower operational overhead than managing a Kubernetes cluster

DAB runs well inside containers.


Azure Kubernetes Service (AKS)

Large organizations often deploy DAB using Kubernetes.

Benefits include:

  • High availability
  • Rolling updates
  • Autoscaling
  • Container orchestration
  • Enterprise management

The configuration file remains largely the same regardless of the hosting platform.


Azure Static Web Apps Integration

One common architecture is:

Static Web App
Data API Builder
Azure SQL Database

Advantages include:

  • Secure authentication
  • Built-in authorization integration
  • REST support
  • GraphQL support
  • Low operational cost
  • Automatic HTTPS

Environment Variables

Instead of storing values inside the configuration file:

Connection String
JWT Secret
API Keys
URLs

Developers store them as environment variables.

Benefits include:

  • Easier deployments
  • Better security
  • CI/CD friendly
  • No secrets in Git
  • Different values for Dev/Test/Production

Azure Key Vault

Environment variables may reference secrets stored in Azure Key Vault.

Typical secrets include:

  • Database passwords
  • Certificates
  • API keys
  • OAuth secrets
  • Encryption keys

Benefits include:

  • Centralized secret management
  • Access auditing
  • Automatic secret rotation
  • Fine-grained access control
  • Compliance support

Logging

Production deployments should enable logging.

Common information includes:

  • Authentication failures
  • API requests
  • SQL errors
  • Performance metrics
  • Authorization failures

Logs can be integrated with:

  • Azure Monitor
  • Application Insights
  • Log Analytics

These tools help diagnose operational issues and monitor API health.


Common Configuration Mistakes

Many deployment failures result from configuration errors rather than application bugs.

Common mistakes include:

  • Invalid JSON syntax
  • Missing commas or braces
  • Incorrect object names
  • Typographical errors in table names
  • Invalid connection strings
  • Missing environment variables
  • Authentication configuration errors
  • Missing permissions
  • Disabled REST endpoints
  • Disabled GraphQL endpoints

Always validate configuration before deployment.


Troubleshooting REST Endpoints

If an endpoint does not respond correctly, verify:

  • Is REST enabled?
  • Does the entity exist?
  • Does the SQL object exist?
  • Is authentication configured correctly?
  • Are permissions assigned?
  • Is the endpoint path correct?
  • Is the API reachable over HTTPS?

These are common troubleshooting steps in real-world deployments.


Troubleshooting GraphQL

If GraphQL queries fail:

  • Verify GraphQL is enabled.
  • Check entity names.
  • Confirm relationships are configured correctly.
  • Validate user permissions.
  • Review authentication settings.
  • Inspect logs for schema generation or query errors.

GraphQL errors are often related to configuration rather than SQL syntax.


DAB Best Practices

Microsoft recommends the following practices:

  • Use Microsoft Entra ID whenever possible.
  • Prefer Managed Identity over passwords.
  • Store secrets in Azure Key Vault.
  • Keep configuration files in source control.
  • Exclude secrets from Git repositories.
  • Use separate environments for development, testing, and production.
  • Follow the principle of least privilege.
  • Expose only the database objects required by the application.
  • Prefer views when exposing sensitive data.
  • Monitor API activity using Azure Monitor and Application Insights.
  • Regularly review permissions and authentication settings.
  • Test configuration changes in a non-production environment before deployment.

Real-World Example

A retail company wants to expose product information to a web application.

Requirements:

  • Customers can view products.
  • Employees can update inventory.
  • Administrators can manage all data.
  • No passwords should be stored in source control.
  • APIs should support both REST and GraphQL.
  • Azure SQL Database is used as the backend.

A recommended DAB solution would include:

  • Azure SQL Database as the data source.
  • Microsoft Entra ID for authentication.
  • Managed Identity for connecting to Azure SQL.
  • Entity permissions granting read access to customers, update access to employees, and full CRUD access to administrators.
  • REST and GraphQL endpoints enabled.
  • Environment variables and Azure Key Vault for configuration and secrets.
  • Deployment to Azure App Service or Azure Container Apps with HTTPS enabled.

DP-800 Exam Tips

When preparing for the DP-800 exam, be sure you can:

  • Explain the purpose of each major section in a DAB configuration file.
  • Configure data sources for Azure SQL Database.
  • Understand how entities map to tables, views, and stored procedures.
  • Configure REST and GraphQL endpoints.
  • Implement role-based permissions.
  • Distinguish authentication from authorization.
  • Explain the benefits of Microsoft Entra ID and Managed Identity.
  • Describe how environment variables and Azure Key Vault improve security.
  • Recognize appropriate Azure hosting options for DAB.
  • Identify common configuration and deployment errors.
  • Apply security best practices when exposing database objects through APIs.

Practice Exam Questions


Question 1

Your organization wants to expose data from an Azure SQL Database through Data API builder. You want to specify the database connection information in the DAB configuration file.

Which section of the configuration file should you modify?

A. runtime

B. entities

C. data-source

D. authentication

Correct Answer: C

Explanation

The data-source section defines the backend database used by Data API builder. It contains information such as the database type, connection string, and provider.

  • The runtime section controls API behavior.
  • The entities section defines which database objects are exposed.
  • Authentication settings belong under the runtime configuration.

Question 2

A development team wants to avoid storing database passwords in the DAB configuration file stored in GitHub.

What is the recommended approach?

A. Encrypt the password using Base64.

B. Store the connection string in an environment variable or Azure Key Vault.

C. Place the password in a separate JSON file.

D. Store the password inside the runtime section.

Correct Answer: B

Explanation

Microsoft recommends storing sensitive information such as connection strings and secrets outside the configuration file by using environment variables or Azure Key Vault. This improves security and supports multiple deployment environments.

Base64 encoding is not encryption and does not protect credentials.


Question 3

A developer creates an entity that maps to the Products table.

What is the primary purpose of the entity definition?

A. Configure Azure authentication.

B. Define database backup policies.

C. Specify which database object is exposed through REST and GraphQL endpoints.

D. Enable SQL auditing.

Correct Answer: C

Explanation

Entities map database objects—such as tables, views, or stored procedures—to automatically generated REST and GraphQL endpoints.

Authentication, auditing, and backup configuration are handled elsewhere.


Question 4

A company wants every database API to support both REST and GraphQL.

Which runtime configuration should be enabled?

A. Enable REST and GraphQL in the runtime section.

B. Configure only the data-source section.

C. Configure only entity permissions.

D. Enable Azure Monitor.

Correct Answer: A

Explanation

The runtime section controls whether REST and GraphQL endpoints are available. Enabling both services allows clients to access the exposed entities through either API style.

Azure Monitor provides monitoring but does not enable APIs.


Question 5

A developer wants to expose a SQL view instead of a table.

Why is this commonly recommended?

A. Views automatically improve SQL Server performance.

B. Views prevent SQL injection attacks.

C. Views can simplify data exposure and hide sensitive columns.

D. Views eliminate the need for permissions.

Correct Answer: C

Explanation

Views allow organizations to expose only the required columns and business logic while hiding sensitive information. They also simplify complex joins and provide an additional abstraction layer.

Views do not automatically improve performance or eliminate security requirements.


Question 6

Your Data API builder application is deployed to Azure App Service.

How should the application authenticate to Azure SQL Database without storing credentials?

A. SQL Authentication

B. Windows Authentication

C. Shared Access Signature (SAS)

D. Managed Identity

Correct Answer: D

Explanation

Managed Identity allows Azure resources to authenticate securely without storing usernames or passwords. Azure automatically manages credential creation and rotation.

This is Microsoft’s recommended authentication approach for Azure-hosted applications.


Question 7

A company wants to expose a stored procedure through Data API builder.

Which object type should be configured?

A. Table

B. View

C. Function

D. Stored-procedure

Correct Answer: D

Explanation

When exposing stored procedures through DAB, the entity’s source type should be configured as stored-procedure.

Tables and views are configured using their respective object types.


Question 8

A web application hosted at https://contoso.com calls a Data API builder service hosted at https://api.contoso.com, but the browser blocks the request.

Which feature should be configured?

A. Transparent Data Encryption

B. Always Encrypted

C. Cross-Origin Resource Sharing (CORS)

D. Dynamic Data Masking

Correct Answer: C

Explanation

Because the application and API are hosted on different origins, the browser enforces the Same-Origin Policy. Configuring CORS allows approved origins to access the API.

Database encryption technologies do not affect browser security policies.


Question 9

An organization uses Microsoft Entra ID to authenticate users accessing Data API builder.

What is the primary benefit?

A. Automatic SQL indexing

B. Enterprise identity management with centralized authentication

C. Automatic query optimization

D. Elimination of REST endpoints

Correct Answer: B

Explanation

Microsoft Entra ID provides centralized authentication, Single Sign-On, Conditional Access, Multi-Factor Authentication, and enterprise identity management.

It does not optimize SQL queries or change API functionality.


Question 10

A development team stores its DAB configuration file in Git and uses Azure DevOps pipelines to deploy to Development, Test, and Production.

Which design best supports this deployment strategy?

A. Maintain separate configuration files containing hardcoded credentials for every environment.

B. Store all passwords directly inside the JSON configuration file.

C. Disable authentication during deployment.

D. Store secrets externally using environment variables or Azure Key Vault while using a common configuration file.

Correct Answer: D

Explanation

A single configuration file combined with environment-specific variables or Azure Key Vault simplifies CI/CD deployments while keeping secrets out of source control. This approach follows Microsoft’s security best practices and makes deployments easier to maintain across multiple environments.


Exam Essentials

For the DP-800 exam, be comfortable with the following concepts:

  • Understand the purpose of the data-source, runtime, and entities sections of a DAB configuration file.
  • Know how Data API builder automatically exposes SQL tables, views, and stored procedures as REST and GraphQL APIs.
  • Recognize when to use tables, views, or stored procedures as entities.
  • Understand how REST and GraphQL endpoints are enabled and configured.
  • Know the difference between authentication and authorization.
  • Understand role-based permissions within DAB.
  • Understand why Microsoft recommends Microsoft Entra ID and Managed Identity for production deployments.
  • Know why secrets should be stored in Azure Key Vault or environment variables instead of configuration files.
  • Understand how CORS enables secure browser-based access across different origins.
  • Recognize common Azure hosting options, including Azure App Service, Azure Container Apps, Azure Kubernetes Service (AKS), and Azure Static Web Apps.
  • Be able to identify common configuration and deployment issues, including invalid JSON, missing environment variables, incorrect entity mappings, and permission misconfigurations.

Final DP-800 Takeaways

Data API builder (DAB) is designed to dramatically simplify API development by exposing database objects through configuration rather than custom code. For the DP-800 exam, Microsoft expects candidates to understand how to configure secure, maintainable, and cloud-ready APIs that integrate with Azure SQL Database and other supported data sources.

Pay particular attention to these frequently tested areas:

  • The structure and purpose of the DAB configuration file.
  • Entity definitions and source object mapping.
  • REST versus GraphQL endpoint configuration.
  • Authentication with Microsoft Entra ID.
  • Passwordless access using Managed Identity.
  • Secrets management with Azure Key Vault and environment variables.
  • Role-based authorization and least-privilege access.
  • Secure deployment practices in Azure environments.

Mastering these concepts will prepare you not only for the DP-800 certification exam but also for implementing secure, production-ready Data API builder solutions in real-world Azure environments.


Go to the DP-800 Exam Prep Hub main page

Create configuration files for Data API builder (DAB) – Part 1 (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%)
   --> Integrate SQL solutions with Azure services
      --> Create configuration files for Data API builder (DAB)


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 application development increasingly relies on APIs rather than direct database connectivity. Instead of allowing client applications to connect directly to a SQL database, developers commonly expose database functionality through secure REST or GraphQL APIs. Microsoft Data API builder (DAB) is designed specifically for this purpose.

Data API builder is an open-source Microsoft tool that automatically creates secure REST and GraphQL endpoints over Azure SQL Database, SQL Server, Azure Database for PostgreSQL, Azure Cosmos DB, and several other supported databases—all from a single configuration file.

Rather than writing thousands of lines of API code, developers describe their database and security requirements in a configuration file. DAB then generates the API automatically.

For the DP-800 certification exam, candidates should understand how to:

  • Create DAB configuration files
  • Configure data sources
  • Define entities
  • Configure REST endpoints
  • Configure GraphQL endpoints
  • Secure APIs
  • Configure authentication
  • Deploy DAB in Azure
  • Manage permissions
  • Configure environment-specific settings

What is Data API Builder?

Data API builder (DAB) is a lightweight API engine that exposes database objects as secure REST and GraphQL endpoints.

Instead of building APIs manually using ASP.NET Core or Node.js, developers configure DAB using a JSON configuration file.

Example:

Database Table

Customers

Automatically becomes

REST

GET /api/Customers

GraphQL

query
{
customers
{
CustomerID
Name
}
}

No custom API coding is required.


Why Microsoft Created Data API Builder

Traditional API development often requires developers to:

  • Design endpoints
  • Write controllers
  • Create models
  • Configure authentication
  • Build CRUD operations
  • Handle serialization
  • Create GraphQL schemas
  • Maintain documentation

This can take weeks.

Data API builder automates these tasks through configuration.

Benefits include:

  • Faster development
  • Less code
  • Standardized APIs
  • Secure default behavior
  • Easy Azure deployment
  • Automatic GraphQL support
  • Automatic OpenAPI generation (REST)

Where DAB Fits in Azure Architecture

Application
Data API Builder
Azure SQL Database

Instead of:

Application
ASP.NET API
Business Layer
Repository Layer
Entity Models
Azure SQL

DAB dramatically reduces application complexity.


Configuration-Driven Development

Everything DAB does is controlled through a configuration file.

The configuration file defines:

  • Database connection
  • Authentication
  • API routes
  • GraphQL schema
  • REST routes
  • Permissions
  • Relationships
  • Stored procedures

This makes the API reproducible and source-control friendly.


Creating a Configuration File

A new configuration file can be created using the DAB CLI.

Example

dab init

This generates a starter configuration file.

Example

dab-config.json

This file becomes the central definition of the API.


Typical Configuration File Structure

A simplified configuration looks like this:

{
"data-source": {
},
"runtime": {
},
"entities": {
}
}

Everything inside these three sections controls the behavior of DAB.


Major Sections of the Configuration File

The most important sections are:

  • data-source
  • runtime
  • entities

Each serves a distinct purpose.


The Data Source Section

The data source defines where the database resides.

Example

"data-source": {
}

Typical information includes:

  • Database type
  • Connection string
  • Database name
  • Authentication method

Example database types

  • SQL Server
  • Azure SQL Database
  • PostgreSQL
  • Azure Cosmos DB

Configuring the Database Type

Example

"database-type": "mssql"

Common supported values

  • mssql
  • postgresql
  • cosmosdb

For DP-800, SQL Server and Azure SQL are the primary focus.


Configuring the Connection String

Example

"connection-string": "@env('SQL_CONNECTION_STRING')"

Notice that the connection string references an environment variable rather than storing credentials directly.

This is considered a security best practice.


Why Environment Variables Are Preferred

Avoid this:

"connection-string":
"Server=myserver;
User=admin;
Password=P@ssword123"

Prefer this:

@env("SQL_CONNECTION_STRING")

Benefits include:

  • No passwords in source control
  • Easier deployment
  • Different environments use different values
  • Improved security

Runtime Configuration

The runtime section controls how the API behaves.

Example

"runtime": {
}

This section contains:

  • REST settings
  • GraphQL settings
  • Host configuration
  • Authentication
  • CORS
  • Logging

Runtime REST Configuration

Example

"rest": {
"enabled": true
}

REST endpoints become available automatically.

Example

GET /api/Products

Runtime GraphQL Configuration

Example

"graphql": {
"enabled": true
}

GraphQL becomes available at

/graphql

Runtime Host Configuration

Example

"host": {
"mode": "development"
}

Common modes include

  • Development
  • Production

Production mode disables many development features.


Authentication Configuration

The runtime section also defines authentication.

Example

"authentication": {
}

Authentication options may include:

  • Anonymous
  • Static Web Apps Authentication
  • Microsoft Entra ID
  • JWT
  • OAuth

Why Authentication Matters

Without authentication:

Anyone can access the API.

With authentication:

  • Users are identified
  • Roles are assigned
  • Permissions are enforced
  • Sensitive data remains protected

Authentication is one of the most tested DAB concepts on the DP-800 exam.


Entities

The most important section is the entity configuration.

Entities represent:

  • Tables
  • Views
  • Stored procedures

Example

"entities": {
}

Each entity becomes one or more API endpoints.


Example Entity

"Products": {
}

This creates

REST

/api/Products

GraphQL

products

Configuring the Source Object

Example

"source": {
"object": "dbo.Products",
"type": "table"
}

The object tells DAB which SQL object to expose.

Supported object types include

  • Table
  • View
  • Stored Procedure

Entity REST Configuration

Example

"rest": {
"enabled": true
}

REST endpoints become available automatically.

Examples

GET /api/Products
POST /api/Products
PUT /api/Products
DELETE /api/Products

depending on permissions.


Custom REST Paths

Instead of

/api/Products

you can configure

/api/catalog

Example

"path": "catalog"

This creates cleaner URLs.


Entity GraphQL Configuration

Example

"graphql": {
"enabled": true
}

GraphQL queries become available.

Example

query
{
products
{
ProductID
Name
}
}

Configuring Relationships

DAB can automatically expose database relationships.

Example

Customers
Orders

Relationship

CustomerID

GraphQL can then retrieve

Customer
Orders

in a single query.

This greatly reduces application complexity.


Stored Procedure Support

Entities may expose stored procedures.

Example

"type": "stored-procedure"

Stored procedures are commonly used for

  • Complex business logic
  • Reporting
  • Batch processing
  • Controlled updates

Environment-Specific Configuration

Different environments often require different settings.

Typical environments include:

  • Development
  • Test
  • QA
  • Staging
  • Production

Rather than maintaining separate configuration files, DAB commonly relies on environment variables.

For example:

Development

SQL_CONNECTION_STRING

points to a local SQL Server.

Production

The same variable name points to an Azure SQL Database.

This approach allows the same configuration file to be deployed across environments while changing only the environment variables.


Common Deployment Scenarios

DP-800 candidates should recognize the most common places where Data API builder is hosted.

Azure App Service

A popular option for enterprise applications. DAB runs as a web application and connects securely to Azure SQL Database.

Azure Container Apps

Suitable for containerized deployments that require scalability and simplified management.

Azure Kubernetes Service (AKS)

Used in large enterprise environments requiring orchestration, high availability, and microservices architectures.

Azure Static Web Apps

Frequently paired with DAB to provide secure APIs for modern JavaScript applications.

Local Development

Developers commonly test DAB locally before deploying to Azure.


Security Best Practices When Creating Configuration Files

When creating DAB configuration files, Microsoft recommends several best practices:

  • Never hardcode passwords or connection strings.
  • Store secrets in environment variables or Azure Key Vault.
  • Use Microsoft Entra ID or Managed Identity whenever possible.
  • Grant only the minimum required database permissions.
  • Disable anonymous access unless explicitly required.
  • Expose only the entities that applications need.
  • Restrict CRUD operations based on user roles.
  • Use HTTPS for all deployments.
  • Keep configuration files under source control while excluding secrets.
  • Regularly review and update authentication and authorization settings.

DP-800 Exam Tips

  • Understand that the configuration file is the core of Data API builder.
  • Be able to identify the purpose of the data-source, runtime, and entities sections.
  • Know how to configure REST and GraphQL endpoints.
  • Understand why environment variables are preferred over hardcoded connection strings.
  • Recognize how tables, views, and stored procedures are exposed as entities.
  • Understand how authentication settings affect API security.
  • Be familiar with common Azure hosting options for DAB.
  • Expect scenario-based questions asking which configuration changes are needed to expose or secure database objects.

Go to the DP-800 Exam Prep Hub main page

Design and implement controls for deployment pipelines, including branching policies, triggers in approvals, authentication tables, and code owners – Part 3 (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
      --> Design and implement controls for deployment pipelines, including branching policies, triggers in approvals, authentication tables, and code owners


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 branching strategies, pull requests, branch protection policies, and Code Owners. In Part 2, you explored deployment triggers, approvals, authentication, Managed Identity, secrets management, and deployment strategies.

This final part focuses on monitoring deployments, auditing changes, troubleshooting common pipeline issues, DP-800 exam tips, and concludes with 10 practice exam questions with answers and explanations.


Monitoring Deployment Pipelines

Monitoring deployment pipelines ensures deployments execute successfully and helps quickly identify failures.

Organizations should continuously monitor:

  • Pipeline execution status
  • Deployment duration
  • Build success rate
  • Deployment frequency
  • Failed deployments
  • Rollback frequency
  • Security events
  • Approval history

Monitoring improves operational reliability and supports continuous improvement.


Pipeline Logs

Every pipeline execution produces logs that document each step performed.

Typical log entries include:

  • Source code version
  • Build start and end times
  • Compilation results
  • Unit test results
  • Deployment scripts executed
  • SQL errors
  • Authentication events
  • Approval actions

Example:

09:12 Build Started
09:14 SQL Project Compiled Successfully
09:15 Unit Tests Passed
09:17 Deployment Started
09:19 Deployment Completed Successfully

Pipeline logs are the first place administrators should investigate deployment failures.


Auditing Deployment Activities

Auditing provides a permanent record of deployment activities.

Common audit information includes:

  • Who approved deployment
  • Who initiated deployment
  • Date and time
  • Target environment
  • Database version
  • Objects modified
  • Authentication method
  • Pipeline identifier

Auditing supports:

  • Compliance
  • Governance
  • Security investigations
  • Operational reporting

Azure Activity Logs

Azure services record deployment-related events in Activity Logs.

Typical recorded events include:

  • Resource creation
  • Database updates
  • Authentication events
  • Role assignments
  • Managed Identity usage
  • Key Vault access
  • Deployment failures

These logs help administrators investigate operational and security issues.


Azure DevOps Audit Logs

Azure DevOps also records pipeline activities such as:

  • Repository changes
  • Pull request approvals
  • Pipeline executions
  • Variable modifications
  • Permission changes
  • Service connection updates

Audit logs improve accountability and simplify compliance reporting.


Security Monitoring

Security monitoring should detect:

  • Unauthorized deployment attempts
  • Failed authentication
  • Excessive permission changes
  • Secret access
  • Unusual deployment times
  • Unexpected production deployments

Security teams often integrate monitoring with Microsoft Sentinel or other SIEM platforms.


Common Deployment Failures

Several issues commonly prevent successful deployments.

Authentication Failure

Example:

Pipeline
Access Denied
Deployment Stops

Possible causes:

  • Expired credentials
  • Incorrect permissions
  • Disabled Managed Identity
  • Invalid service connection

Approval Timeout

Example:

Deployment Waiting
Approval Not Received
Pipeline Timeout

Possible causes:

  • Missing approver
  • Incorrect approval configuration
  • Vacation or unavailable reviewer

Build Failure

Common causes include:

  • SQL syntax errors
  • Invalid references
  • Missing objects
  • Compilation failures

CI validation should detect these issues before deployment.


Test Failure

Deployment should stop automatically if:

  • Unit tests fail
  • Integration tests fail
  • Security scans fail
  • Static code analysis fails

Stopping deployment early prevents production issues.


Merge Conflicts

Two developers may modify the same SQL object simultaneously.

Example:

Developer A

CREATE PROCEDURE usp_GetOrders

Developer B

ALTER PROCEDURE usp_GetOrders

Git cannot determine which version is correct until the conflict is resolved manually.


Troubleshooting Deployment Problems

A systematic approach helps resolve deployment issues efficiently.

Step 1

Verify pipeline logs.

Step 2

Review build output.

Step 3

Confirm authentication.

Step 4

Check approval status.

Step 5

Review deployment scripts.

Step 6

Validate environment configuration.

Step 7

Retry deployment after correcting the issue.


Common Best Practices

Microsoft recommends several practices for enterprise SQL deployments.

Automate Everything Possible

Automate:

  • Builds
  • Testing
  • Validation
  • Packaging
  • Deployment

Automation reduces human error.


Protect Production

Require:

  • Manual approvals
  • Branch protection
  • Code reviews
  • Environment protection
  • Audit logging

Production should never allow direct deployments from developer workstations.


Use Managed Identity

Whenever Azure services are involved:

  • Prefer Managed Identity.
  • Avoid passwords.
  • Avoid embedded secrets.
  • Minimize credential management.

Store Secrets Securely

Never store:

  • Passwords
  • API keys
  • Connection strings
  • Certificates

inside:

  • Git repositories
  • SQL scripts
  • Configuration files

Instead use:

  • Azure Key Vault
  • Secure pipeline variables

Implement Least Privilege

Deployment identities should receive only the permissions required.

Avoid excessive privileges such as:

  • sysadmin
  • Owner
  • Global Administrator

Smaller permission scopes reduce security risk.


Require Peer Review

Require pull requests before merging into protected branches.

Benefits include:

  • Better quality
  • Better documentation
  • Knowledge sharing
  • Earlier bug detection

DP-800 Exam Tips

Expect scenario-based questions that require selecting the most secure and maintainable solution.

Remember these key concepts:

Branch Protection

Protect production branches using:

  • Required reviews
  • Successful builds
  • Status checks
  • Merge restrictions

Code Owners

Automatically assign reviewers for sensitive SQL objects.


Pull Requests

Never merge directly into protected production branches.


Managed Identity

Microsoft’s preferred authentication method for Azure-hosted resources.


Service Principal

Best for automated deployments when Managed Identity is unavailable.


Azure Key Vault

Store secrets securely instead of embedding credentials.


Deployment Approvals

Require approvals before:

  • Production deployments
  • High-risk schema changes
  • Security-related modifications

Deployment Gates

Prevent deployment unless:

  • Tests pass
  • Security scans succeed
  • Required approvals exist

Audit Logs

Understand where deployment history is recorded and how it supports compliance.


End-of-Topic Summary

A successful SQL deployment pipeline combines automation with governance.

The typical enterprise deployment process follows this sequence:

Developer
Feature Branch
Pull Request
Code Review
Build
Unit Tests
Integration Tests
Security Validation
Approval
Deployment
Monitoring
Audit Logging

Microsoft expects DP-800 candidates to understand not only how to deploy SQL Database Projects, but also how to secure those deployments through proper authentication, approvals, source control policies, and auditing.

Mastering these concepts enables developers to build reliable, compliant, and maintainable database deployment pipelines.


Practice Exam Questions

Question 1

A development team wants every database schema change to be reviewed before it can be merged into the main branch. Which feature should be implemented?

A. Scheduled pipeline triggers

B. Pull requests with required reviewers

C. Incremental deployments

D. Query Store

Correct Answer: B

Explanation

Pull requests combined with required reviewers enforce peer review before code reaches protected branches. Scheduled triggers automate pipeline execution, incremental deployments control deployment scope, and Query Store is used for query performance monitoring.


Question 2

A deployment pipeline must authenticate to Azure SQL Database without storing passwords or secrets. Which authentication method should be recommended?

A. SQL Authentication

B. Windows Authentication

C. Managed Identity

D. Shared administrator account

Correct Answer: C

Explanation

Managed Identity eliminates the need to store credentials and automatically manages authentication through Microsoft Entra ID. It is Microsoft’s preferred authentication mechanism for Azure-hosted services.


Question 3

A company wants deployment pipelines to pause before production deployment until a database administrator approves the release. What should be configured?

A. Branch tags

B. Code Owners

C. Manual deployment approval

D. Incremental deployment

Correct Answer: C

Explanation

Manual approvals pause deployment until authorized personnel approve the release. This provides governance for production environments.


Question 4

A deployment pipeline needs to retrieve database connection strings securely during deployment. Where should these secrets be stored?

A. SQL scripts

B. Git repository

C. Configuration files

D. Azure Key Vault

Correct Answer: D

Explanation

Azure Key Vault securely stores secrets, certificates, and connection strings while providing auditing, encryption, and access control.


Question 5

Why should organizations implement branch protection policies?

A. To improve query execution performance

B. To prevent unauthorized or unreviewed changes from being merged

C. To encrypt database columns

D. To eliminate deployment approvals

Correct Answer: B

Explanation

Branch protection policies require reviews, successful builds, and other validations before changes can be merged into protected branches.


Question 6

A SQL deployment pipeline requires an identity that is independent of individual user accounts and can authenticate to Azure resources. Which option is most appropriate?

A. Service Principal

B. SQL login

C. Database user

D. Shared administrator account

Correct Answer: A

Explanation

A Service Principal provides a dedicated application identity for automated deployments. It supports secure, non-interactive authentication and follows enterprise identity management practices.


Question 7

What is the primary purpose of Code Owners in a SQL Database Project repository?

A. Encrypt deployment artifacts

B. Store deployment secrets

C. Automatically assign reviewers for specific files or folders

D. Execute integration tests

Correct Answer: C

Explanation

Code Owners automatically request reviews from designated experts when specific files or directories are modified, improving governance and code quality.


Question 8

Which deployment strategy minimizes downtime by maintaining two production environments and switching traffic after validation?

A. Rolling deployment

B. Incremental deployment

C. Canary deployment

D. Blue-Green deployment

Correct Answer: D

Explanation

Blue-Green deployment maintains separate production environments. After validating the new version, traffic switches to the updated environment, enabling rapid rollback if necessary.


Question 9

A deployment pipeline repeatedly fails immediately after starting because it cannot authenticate to Azure SQL Database. Which troubleshooting step should be performed first?

A. Review pipeline logs and verify authentication configuration

B. Disable branch protection

C. Rebuild the SQL Database Project

D. Delete the deployment pipeline

Correct Answer: A

Explanation

Authentication failures should first be investigated by reviewing pipeline logs and verifying service connections, Managed Identity configuration, or Service Principal permissions.


Question 10

Why should production deployments require manual approvals even when all automated tests have passed?

A. Automated tests replace governance requirements.

B. Manual approvals allow authorized personnel to verify business readiness and organizational compliance before deployment.

C. Manual approvals improve query performance.

D. Production deployments cannot use automated pipelines.

Correct Answer: B

Explanation

Although automated testing validates technical correctness, manual approvals ensure that organizational, operational, and business requirements have also been satisfied before releasing changes into production.


Final DP-800 Exam Preparation Tips

For this objective, remember these high-value exam concepts:

  • Protect important branches with branch protection policies.
  • Require pull requests and peer reviews before merging changes.
  • Use Code Owners to automatically assign reviewers for sensitive database objects.
  • Configure CI pipelines to validate every change through automated builds and tests.
  • Secure deployments with Managed Identity whenever Azure-hosted services support it, or Service Principals when appropriate.
  • Store secrets in Azure Key Vault, not in source control or configuration files.
  • Apply the principle of least privilege to deployment identities.
  • Protect production with deployment approvals, environment protection rules, and deployment gates.
  • Monitor deployment pipelines using logs and audit records to support troubleshooting, governance, and compliance.

These practices align with Microsoft’s recommended DevOps approach for SQL Database Projects and represent the types of deployment governance scenarios you are likely to encounter on the DP-800 certification exam.


Go to the DP-800 Exam Prep Hub main page

Design and implement controls for deployment pipelines, including branching policies, triggers in approvals, authentication tables, and code owners – 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
      --> Design and implement controls for deployment pipelines, including branching policies, triggers in approvals, authentication tables, and code owners


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 how branching strategies, pull requests, branch protection policies, and Code Owners help organizations maintain secure and reliable SQL Database Projects. In this section, we focus on how deployment pipelines automatically execute, how approvals and authentication secure deployments, and how organizations protect production environments.


Pipeline Triggers

A pipeline trigger determines when a build or deployment pipeline starts.

Rather than requiring developers to manually start every pipeline, modern CI/CD systems automatically execute pipelines based on predefined events.

Common trigger types include:

  • Source code commits
  • Pull requests
  • Scheduled executions
  • Manual execution
  • Completion of another pipeline
  • Tag creation
  • Release approvals

Choosing the appropriate trigger helps balance automation with governance.


Continuous Integration Triggers

Continuous Integration (CI) pipelines usually start automatically after code changes.

Typical CI trigger:

Developer Commit
Git Repository
Automatic Build
Compile SQL Database Project
Run Validation
Publish Build Artifact

Benefits include:

  • Immediate feedback
  • Early detection of errors
  • Frequent validation
  • Consistent builds
  • Reduced integration problems

Common CI Trigger Events

Commit Trigger

The pipeline starts whenever a developer commits changes.

Example:

Commit to feature branch
Build Pipeline Starts

Useful for:

  • Early validation
  • Fast feedback
  • Developer productivity

Pull Request Trigger

Instead of triggering on every commit, organizations often build whenever a pull request is created or updated.

Example:

Feature Branch
Create Pull Request
Automatic Validation
Review

Benefits:

  • Ensures only validated code reaches protected branches
  • Prevents broken code from being merged
  • Supports branch protection policies

Scheduled Trigger

Some validation pipelines execute on a schedule.

Example:

Every Night
Run Full Test Suite

Useful for:

  • Long-running tests
  • Security scanning
  • Dependency validation
  • Performance testing

Manual Trigger

Certain deployments should never execute automatically.

Example:

Release Manager
Start Production Deployment

Manual triggers provide additional governance before production releases.


Continuous Delivery Triggers

Continuous Delivery (CD) pipelines move validated artifacts through multiple environments.

Example:

Build Artifact
Development
Testing
Staging
Production

Each stage may have different approval requirements.


Deployment Approvals

Approvals ensure that qualified personnel review changes before deployment.

Instead of automatically deploying to production, pipelines pause until an authorized user approves the release.

Example:

Deployment Ready
Approval Required
Manager Approves
Deployment Continues

Types of Deployment Approvals

Manual Approval

A designated reviewer manually approves deployment.

Common reviewers include:

  • Database Administrator
  • Development Lead
  • Security Team
  • Operations Team
  • Product Owner

Multi-Stage Approval

Different environments require different reviewers.

Example:

EnvironmentRequired Approval
DevelopmentNone
TestTeam Lead
StagingDBA
ProductionDBA + Operations Manager

This layered approval process minimizes production risk.


Conditional Approval

Approval requirements may depend on:

  • Database type
  • Environment
  • Change size
  • Security classification
  • Time of deployment

Example:

Production Deployment
Contains Schema Changes?
Yes
Require DBA Approval

Environment Protection

Modern DevOps platforms allow organizations to protect deployment environments.

Environment protection can require:

  • Manual approvals
  • Deployment windows
  • Authentication verification
  • Security policies
  • Health checks

Example:

Pipeline
Staging
Approval
Production

Only authorized deployments can proceed.


Deployment Gates

Deployment gates evaluate conditions before allowing deployment.

Common gates include:

  • Successful testing
  • Security scan completion
  • Vulnerability assessment
  • Performance validation
  • Business approval
  • Service availability

Example:

Security Scan Passed?
Yes
Continue Deployment

If any gate fails, deployment stops automatically.


Authentication in Deployment Pipelines

Authentication verifies the identity of the pipeline when accessing resources.

The deployment pipeline may need to access:

  • SQL Server
  • Azure SQL Database
  • Azure Key Vault
  • Azure Storage
  • Azure AI Services
  • Microsoft Fabric
  • Azure OpenAI
  • Azure Resource Manager

Secure authentication is essential because deployment pipelines often operate without human intervention.


Authentication Methods

Common authentication methods include:

  • Microsoft Entra ID (Azure AD)
  • Managed Identity
  • Service Principal
  • OAuth tokens
  • Personal Access Tokens (PATs)
  • SQL Authentication (legacy scenarios)

Microsoft recommends avoiding passwords whenever possible.


Service Principals

A Service Principal represents an application identity in Microsoft Entra ID.

Instead of using a person’s account, the deployment pipeline authenticates using its own identity.

Example:

Pipeline
Service Principal
Microsoft Entra ID
Azure SQL Database

Benefits:

  • Non-interactive authentication
  • Fine-grained permissions
  • Centralized identity management
  • Easy auditing
  • Supports automation

Managed Identity

A Managed Identity is the preferred authentication method for Azure-hosted services.

Instead of storing credentials, Azure automatically manages authentication.

Example:

Azure DevOps Agent
Managed Identity
Microsoft Entra ID
Azure SQL Database

Advantages include:

  • No stored passwords
  • Automatic credential rotation
  • Improved security
  • Simplified administration
  • Reduced risk of credential leakage

Managed Identity is increasingly emphasized across Microsoft certifications, including DP-800.


System-Assigned vs User-Assigned Managed Identity

System-Assigned Managed Identity

Characteristics:

  • Tied to one Azure resource
  • Automatically created
  • Automatically deleted with the resource
  • Ideal for single-resource scenarios

Example:

App Service
System Managed Identity
Azure SQL

User-Assigned Managed Identity

Characteristics:

  • Independent Azure resource
  • Shared across multiple services
  • Longer lifecycle
  • Reusable

Example:

Managed Identity
Web App
Azure Function
Azure SQL Database

Useful when multiple applications require the same identity.


Least Privilege Principle

Deployment identities should have only the permissions necessary to perform deployments.

Avoid granting:

  • sysadmin
  • db_owner (unless required)
  • Subscription Owner
  • Global Administrator

Instead, assign only the permissions needed.

Example:

Deployment pipeline requires:

  • ALTER TABLE
  • CREATE PROCEDURE
  • CREATE VIEW

It does not require:

  • DROP DATABASE
  • Server Administration
  • Security Administration

Following the principle of least privilege reduces the impact of compromised credentials.


Secrets Management

Pipelines often require sensitive information, such as:

  • Connection strings
  • API keys
  • Certificates
  • Tokens
  • Database credentials

Hardcoding these values in source control is a major security risk.


Azure Key Vault

Azure Key Vault is the recommended solution for storing secrets.

Instead of embedding credentials:

Pipeline
Azure Key Vault
Retrieve Secret
Deploy Database

Benefits include:

  • Centralized secret storage
  • Encryption at rest
  • Access auditing
  • Role-based access control
  • Automatic secret rotation
  • Integration with Azure DevOps and GitHub Actions

Secure Pipeline Variables

CI/CD platforms support secure variables that:

  • Encrypt values
  • Hide secrets in logs
  • Restrict access
  • Limit modification permissions

Examples include:

  • SQL connection strings
  • Azure subscription IDs
  • API tokens
  • Storage account keys

Sensitive values should never be committed to a Git repository.


Environment-Specific Configuration

Different deployment environments often require different configuration values.

Example:

EnvironmentDatabase
DevelopmentDevDB
TestingTestDB
StagingStageDB
ProductionProdDB

Pipelines should dynamically retrieve the correct configuration for each environment rather than hardcoding values.


Deployment Strategies

Different deployment strategies reduce downtime and deployment risk.

Common strategies include:

Incremental Deployment

Deploy only changed objects.

Advantages:

  • Faster deployments
  • Lower risk
  • Reduced downtime

Rolling Deployment

Deploy changes gradually across multiple instances.

Useful for:

  • High availability
  • Large distributed systems

Blue-Green Deployment

Maintain two production environments.

Blue Environment
(Current)
Switch
Green Environment
(New Version)

Advantages:

  • Minimal downtime
  • Fast rollback
  • Lower deployment risk

Canary Deployment

Deploy to a small subset of users first.

If successful:

5%
25%
50%
100%

This strategy helps identify issues before a full rollout.


Best Practices for Secure Deployment Pipelines

Microsoft recommends the following practices:

  • Automate builds whenever possible.
  • Require approvals for production deployments.
  • Use Microsoft Entra ID authentication.
  • Prefer Managed Identity over stored credentials.
  • Store secrets in Azure Key Vault.
  • Apply least privilege permissions.
  • Protect production environments with approval gates.
  • Separate development, test, staging, and production environments.
  • Monitor deployment history and audit logs.
  • Validate deployments before promotion to production.

DP-800 Exam Tips

For the exam, be prepared to identify when to use:

  • Pull request triggers versus commit triggers.
  • Manual approvals for production deployments.
  • Managed Identity instead of passwords or embedded credentials.
  • Service Principals for automated, non-interactive deployments.
  • Azure Key Vault for secure secrets management.
  • Environment protection rules to safeguard production resources.
  • Least privilege permissions for deployment identities.
  • Appropriate deployment strategies such as blue-green, rolling, or incremental deployments based on business requirements.

Part 2 Summary

In this section, you learned how organizations secure and automate SQL deployment pipelines through:

  • Pipeline triggers and CI/CD automation
  • Manual and conditional deployment approvals
  • Environment protection and deployment gates
  • Authentication using Microsoft Entra ID
  • Service Principals and Managed Identity
  • Least privilege access
  • Secrets management with Azure Key Vault
  • Secure pipeline variables
  • Environment-specific configuration
  • Common deployment strategies
  • Microsoft-recommended security and governance practices

Go to the DP-800 Exam Prep Hub main page

Design and implement controls for deployment pipelines, including branching policies, triggers in approvals, authentication tables, and code owners – Part 1 (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
      --> Design and implement controls for deployment pipelines, including branching policies, triggers in approvals, authentication tables, and code owners


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

Microsoft expects SQL AI Developers to understand not only how to develop database solutions but also how to deploy them safely, consistently, and securely using modern DevOps practices.

Organizations rarely allow developers to deploy SQL changes directly into production. Instead, database changes pass through controlled deployment pipelines that validate the code, enforce security policies, require approvals, and ensure only authorized changes reach production.

Modern SQL development emphasizes:

  • Source-controlled database projects
  • Automated builds
  • Automated testing
  • Controlled deployments
  • Secure authentication
  • Governance through branching policies and approvals
  • Auditable deployment history

Understanding these concepts is essential for both the DP-800 exam and real-world enterprise database development.


What Are Deployment Pipeline Controls?

Deployment pipeline controls are rules and processes that ensure database changes move safely from development to production.

Instead of allowing developers to make direct changes to production databases, organizations require every change to follow a controlled workflow.

A typical workflow looks like this:

Developer
Feature Branch
Pull Request
Code Review
Automated Build
Unit Tests
Integration Tests
Approval
Deployment Pipeline
Development
Test
Staging
Production

Each stage reduces the risk of introducing errors into production.


Why Deployment Controls Matter

Without deployment controls, organizations often experience:

  • Accidental schema changes
  • Lost database objects
  • Unauthorized modifications
  • Production outages
  • Failed deployments
  • Data corruption
  • Compliance violations
  • Security risks

Deployment controls provide:

  • Consistency
  • Repeatability
  • Security
  • Governance
  • Auditability
  • Faster recovery
  • Higher software quality

For enterprise environments, these controls are considered mandatory.


SQL Database Projects and Deployment Pipelines

SQL Database Projects represent an entire database schema as source-controlled code.

Instead of modifying objects directly inside SQL Server Management Studio (SSMS), developers modify project files.

Example:

Tables
Customers.sql
Orders.sql
Products.sql
Views
SalesView.sql
Stored Procedures
usp_CreateOrder.sql
Functions
fn_TotalSales.sql

The deployment pipeline compares the project against the target database and generates the necessary deployment script automatically.

Benefits include:

  • Version history
  • Repeatable deployments
  • Easier collaboration
  • Automated validation
  • Reduced deployment risk

CI/CD Overview

CI/CD stands for:

Continuous Integration (CI)

Developers frequently merge changes into a shared repository.

Every commit automatically triggers:

  • Build validation
  • SQL compilation
  • Static code analysis
  • Unit testing
  • Artifact creation

Example:

Developer Commit
Git Repository
Automatic Build
Database Project Build
Validation
Package Generated

Continuous Delivery (CD)

Continuous Delivery automates deployments through multiple environments.

Example:

Development
QA
Staging
Production

Each deployment can require approvals before continuing.

Benefits include:

  • Faster releases
  • Fewer deployment errors
  • Repeatable deployments
  • Reliable rollback strategies

Understanding Branching Strategies

Branching is one of the most important deployment controls.

A branch is an independent line of development inside source control.

Instead of every developer modifying the main branch directly, developers work in isolated branches.

Example:

Main
├── Feature A
├── Feature B
├── Bug Fix
└── Feature C

Each branch is reviewed before merging.


Why Branching Is Important

Branching allows developers to:

  • Work independently
  • Prevent conflicts
  • Test safely
  • Review code
  • Protect production code
  • Isolate unfinished features

Without branching:

  • Developers overwrite one another’s work.
  • Unfinished code reaches production.
  • Rollbacks become difficult.

Common Branching Strategies

Several branching strategies are commonly used.


Feature Branch Workflow

The most common approach.

Each new feature receives its own branch.

Example:

Main
├── feature/AddOrders
├── feature/AddInvoices
├── feature/SearchCustomers

Advantages:

  • Easy code review
  • Simple testing
  • Low risk
  • Small pull requests

This is one of the most common approaches for SQL Database Projects.


GitFlow

GitFlow introduces several branch types.

Main
Develop
Feature Branches
Release Branches
Hotfix Branches

Typical workflow:

Main
Develop
Feature Branch
Develop
Release
Main

Advantages:

  • Strong release management
  • Good for large teams
  • Stable production releases

Disadvantages:

  • More complex
  • Additional branch management

Trunk-Based Development

Developers merge frequently into a single shared branch.

Main
Developer 1
Developer 2
Developer 3
Developer 4

Developers create very short-lived branches.

Advantages:

  • Small changes
  • Faster integration
  • Less merge complexity

Disadvantages:

  • Requires excellent automated testing
  • Requires disciplined developers

Branch Protection Policies

Branch protection prevents unsafe changes.

The main branch is typically protected.

Developers cannot:

  • Force push
  • Delete the branch
  • Merge without approval
  • Merge failed builds
  • Bypass policies

Example policy:

Main Branch
✓ Build must succeed
✓ Two reviewers required
✓ No direct commits
✓ Status checks pass
✓ Linked work item required
✓ Up-to-date before merge

These policies dramatically reduce deployment mistakes.


Common Branch Protection Rules

Organizations often require:

Required Pull Requests

Direct commits are blocked.

Developers must create a pull request.


Required Reviewers

Example:

Minimum Reviewers = 2

Multiple reviewers reduce errors.


Successful Build Required

If automated validation fails, merging is blocked.

Example:

Build Failed
Merge Blocked

Required Status Checks

Policies verify that:

  • Unit tests passed
  • Integration tests passed
  • Security scans completed
  • SQL build succeeded
  • Code quality passed

Only then is the merge allowed.


Prevent Force Push

Force pushes rewrite Git history.

Most organizations disable them for protected branches.


Prevent Branch Deletion

Important branches should never be accidentally removed.

Branch protection prevents deletion.


Pull Requests (PRs)

A pull request requests permission to merge one branch into another.

Example:

Feature Branch
Pull Request
Review
Approval
Merge

A pull request usually includes:

  • Description
  • Changed files
  • SQL object modifications
  • Reviewer comments
  • Build status
  • Test results

Benefits of Pull Requests

Pull requests improve quality by encouraging:

  • Peer review
  • Knowledge sharing
  • Early defect detection
  • Security review
  • Coding standard enforcement

For SQL projects, reviewers often examine:

  • Table changes
  • Index changes
  • Stored procedures
  • Permissions
  • Migration scripts
  • Performance impacts

Code Reviews

Code reviews help identify issues before deployment.

Reviewers commonly check:

Correctness

Does the SQL produce the expected results?

Performance

Are indexes appropriate?

Will queries scale?

Security

Are permissions appropriate?

Is SQL injection prevented?

Maintainability

Is the code readable?

Are naming standards followed?

Backward Compatibility

Will existing applications continue working?


Code Owners

One important governance feature is Code Owners.

A Code Owners file automatically assigns reviewers based on the files that change.

Example:

Tables/*
→ Database Team
StoredProcedures/*
→ Backend Team
Security/*
→ Security Team

When a developer modifies a protected object, the correct experts are automatically requested to review the change.

Benefits of Code Owners

Code Owners provide several advantages:

  • Automatic reviewer assignment
  • Faster review workflows
  • Consistent governance
  • Improved accountability
  • Better code quality
  • Subject matter expert validation
  • Compliance with organizational policies

For example:

  • Changes to security-related scripts can require approval from the security team.
  • Changes to database schema objects can require approval from database administrators.
  • Changes to deployment scripts can require DevOps team approval.

This ensures that critical database components are always reviewed by the appropriate personnel before deployment.


Best Practices for Branching and Pull Requests

Microsoft recommends following modern DevOps practices when managing SQL Database Projects.

Some recommended best practices include:

  • Create small, focused feature branches.
  • Keep branches short-lived.
  • Merge changes frequently.
  • Require pull requests for protected branches.
  • Require successful builds before merging.
  • Require automated tests before deployment.
  • Require peer reviews.
  • Protect the main branch from direct commits.
  • Use Code Owners for sensitive database objects.
  • Document pull requests with clear descriptions.
  • Resolve merge conflicts promptly.
  • Use descriptive branch names such as:
    • feature/AddCustomerSearch
    • bugfix/FixDeadlockIssue
    • hotfix/CorrectCustomerIndex

Following these practices improves collaboration, reduces deployment risk, and helps maintain a reliable, auditable database development process.


Part 1 Summary

In this first part, you learned the foundational deployment pipeline controls that are central to modern SQL DevOps and the DP-800 exam:

  • The purpose of deployment pipeline controls
  • The role of SQL Database Projects in CI/CD
  • Continuous Integration (CI) and Continuous Delivery (CD)
  • Common branching strategies (Feature Branch, GitFlow, and Trunk-Based Development)
  • Branch protection policies and why they matter
  • Pull requests and peer code reviews
  • Code Owners and automated reviewer assignment
  • Best practices for secure and reliable database development

Go to the DP-800 Exam Prep Hub main page

Update a SQL database project and deploy changes (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
      --> Update a SQL database project and deploy changes


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

For the DP-800 exam, you should understand how to modify a SQL Database Project, validate the changes, build the project into a DACPAC, compare the project to a target database, generate deployment scripts, publish changes safely, and integrate the entire deployment process into a CI/CD pipeline.


What Is a SQL Database Project?

A SQL Database Project is a source-controlled representation of a database schema. Rather than directly modifying a production database, developers modify the project files, commit those changes to source control, and deploy them through an automated pipeline.

A SQL Database Project typically contains:

  • Tables
  • Views
  • Stored procedures
  • Functions
  • Triggers
  • Security objects
  • Roles
  • Users
  • Schemas
  • Permissions
  • Reference data (optional)
  • Project configuration

The project serves as the single source of truth for the database schema.


Why Update the Database Project?

Every database change should begin in the project—not in the production database.

Typical changes include:

  • Adding new tables
  • Modifying columns
  • Creating indexes
  • Updating stored procedures
  • Adding functions
  • Changing permissions
  • Creating new schemas
  • Modifying constraints

Example:

Original table:

CREATE TABLE Sales.Customer
(
CustomerID INT PRIMARY KEY,
CustomerName NVARCHAR(100)
);

Business requirement:

Store customer email addresses.

Updated project:

CREATE TABLE Sales.Customer
(
CustomerID INT PRIMARY KEY,
CustomerName NVARCHAR(100),
EmailAddress NVARCHAR(255)
);

After the project is updated, the deployment process determines the necessary ALTER TABLE statement.


Typical Deployment Workflow

The recommended workflow is:

Developer
Modify SQL Database Project
Validate
Build DACPAC
Commit to Git
Pull Request
Code Review
Merge
CI/CD Pipeline
Deploy Development
Deploy Test
Deploy Production

This workflow provides consistency, repeatability, and auditability.


Updating Database Objects

Developers modify individual object files.

For example:

Tables
Customer.sql
Views
ActiveCustomers.sql
Procedures
usp_CreateOrder.sql
Functions
fn_TotalSales.sql

Each object exists as its own SQL file.

Benefits include:

  • Easier source control
  • Better merge handling
  • Clear code reviews
  • Object-level change history

Schema Validation

Before deployment, the project should validate successfully.

Validation checks include:

  • Syntax errors
  • Missing object references
  • Invalid dependencies
  • Duplicate object names
  • Constraint issues
  • Circular references

Early validation prevents deployment failures.


Building the Project

Once validated, the project is built into a DACPAC.

A DACPAC contains:

  • Database schema
  • Metadata
  • Deployment model

It does not include:

  • User data
  • Transaction logs
  • Database backups

The DACPAC becomes the deployment artifact used throughout the pipeline.


What Happens During Deployment?

Deployment compares:

Desired State (DACPAC)
Target Database
Difference Analysis
Deployment Script
Database Update

The deployment engine generates only the necessary changes.

Example:

Project:

EmailAddress column exists

Target database:

EmailAddress missing

Generated deployment:

ALTER TABLE Sales.Customer
ADD EmailAddress NVARCHAR(255);

Declarative Deployment Model

SQL Database Projects use a declarative deployment model.

Developers describe the desired database schema rather than writing migration scripts manually.

Instead of:

Run these SQL commands.

You define:

The database should look like this.

The deployment engine determines the required SQL statements.


Incremental Deployments

Deployments are incremental.

Only differences are deployed.

If no differences exist:

No deployment changes

If one object changes:

Only that object is updated.

This minimizes deployment time and risk.


Deployment Reports

Before publishing, SQL Database Projects can generate a deployment report.

The report identifies:

  • New objects
  • Modified objects
  • Removed objects
  • Security changes
  • Dependency changes

Reviewing the report before production deployment is a best practice.


Deployment Scripts

Instead of deploying immediately, teams often generate a deployment script.

Benefits include:

  • DBA review
  • Change approval
  • Compliance auditing
  • Troubleshooting
  • Rollback planning

Example workflow:

Build
Generate Script
Review
Approve
Deploy

Publish Profiles

A publish profile stores deployment settings.

Typical settings include:

  • Target server
  • Database name
  • Authentication
  • Deployment options
  • Object exclusions
  • Ignore settings

Rather than entering these settings each time, teams reuse publish profiles.


Deployment Options

Deployment options control deployment behavior.

Common examples include:

  • Block deployment on data loss
  • Drop objects not in source
  • Ignore permissions
  • Ignore users
  • Ignore role memberships
  • Ignore whitespace differences
  • Ignore filegroups

Proper configuration reduces deployment risk.


Handling Schema Drift

Before deployment, the deployment engine compares:

Project

Production

If unexpected differences exist:

  • deployment report identifies them
  • deployment script reflects them
  • pipeline may fail
  • manual approval may be required

This helps prevent accidental overwriting of production changes.


Deploying Through CI/CD

Modern SQL deployments are automated.

Typical Azure DevOps or GitHub Actions workflow:

Developer Commit
Build
Validate
Create DACPAC
Run Tests
Schema Comparison
Generate Deployment Script
Approval
Deploy

Automation reduces manual errors.


Safe Deployment Practices

Good deployment practices include:

  • Always build before deployment.
  • Validate object dependencies.
  • Review deployment reports.
  • Use pull requests.
  • Test deployments in lower environments.
  • Generate deployment scripts.
  • Back up production before deployment.
  • Avoid direct production edits.

Environment-Specific Deployments

The same DACPAC can deploy to:

  • Development
  • Test
  • QA
  • Staging
  • Production

Environment-specific settings come from publish profiles or pipeline variables.


Rollback Considerations

Unlike application deployments, database rollbacks can be difficult because:

  • Data may have changed.
  • Schema changes may be irreversible.
  • Dropped columns may lose data.
  • Constraint changes may affect applications.

Best practices include:

  • Backup databases
  • Generate deployment scripts
  • Test deployments
  • Use staged rollouts
  • Block deployments that could cause data loss

Common Deployment Problems

Missing Dependencies

Example:

Procedure references a table that does not exist.

Validation catches this before deployment.


Schema Drift

Someone manually modified production.

Deployment identifies unexpected differences.


Data Loss Warnings

Example:

ALTER TABLE Employee
DROP COLUMN Salary;

The deployment engine warns that existing data will be lost.


Permission Errors

The deployment account lacks sufficient permissions.

Required permissions often include:

  • ALTER
  • CREATE
  • DROP
  • EXECUTE
  • CONTROL (depending on deployment scope)

Using SqlPackage

Microsoft’s SqlPackage utility is commonly used for automated deployments.

Common actions include:

Build DACPAC
Generate Deploy Report
Generate Script
Publish Database

Examples:

Generate deployment report:

SqlPackage /Action:DeployReport

Generate deployment script:

SqlPackage /Action:Script

Publish:

SqlPackage /Action:Publish

Azure DevOps Integration

Azure DevOps pipelines commonly perform the following:

  • Restore dependencies
  • Build SQL project
  • Produce DACPAC
  • Validate project
  • Run tests
  • Publish artifacts
  • Deploy to development
  • Require approval
  • Deploy to production

Approvals and gates help prevent accidental production deployments.


GitHub Actions Integration

GitHub Actions follows a similar workflow:

Push
Build SQL Project
Generate DACPAC
Validate
Deploy

Secrets such as connection strings are stored using GitHub Secrets rather than in project files.


Best Practices

  • Treat the SQL Database Project as the authoritative database definition.
  • Make schema changes only within the project.
  • Keep all database objects in source control.
  • Build the project after every change.
  • Validate dependencies before deployment.
  • Review deployment reports and generated scripts.
  • Deploy through automated CI/CD pipelines.
  • Test deployments in non-production environments.
  • Protect production deployments with approvals.
  • Keep publish profiles and pipeline configurations under version control where appropriate, excluding sensitive information.

DP-800 Exam Tips

Remember these important exam points:

  • SQL Database Projects use a declarative deployment model.
  • Building the project creates a DACPAC.
  • Deployments compare the desired schema with the target database.
  • Deployment reports identify planned changes before publishing.
  • Publish Profiles simplify repeatable deployments.
  • CI/CD pipelines automate building, validating, and deploying database changes.
  • Schema drift should be detected before deployment.
  • Production changes should originate from the SQL Database Project rather than direct database modifications.

Practice Exam Questions

Question 1

A developer adds a new stored procedure to a SQL Database Project. What should be the next step before deployment?

A. Restart the SQL Server service.

B. Build and validate the SQL Database Project.

C. Export the production database.

D. Rebuild all indexes.

Answer: B

Explanation: Building validates the project, checks dependencies, and produces the DACPAC used for deployment.


Question 2

What artifact is produced when a SQL Database Project is successfully built?

A. BACPAC

B. MDF file

C. DACPAC

D. Transaction log

Answer: C

Explanation: Building a SQL Database Project produces a DACPAC that contains the database schema and metadata.


Question 3

What is the primary purpose of a deployment report?

A. To store backup data

B. To monitor CPU usage

C. To list planned schema changes before deployment

D. To compress the database

Answer: C

Explanation: Deployment reports allow administrators to review proposed schema changes before they are applied.


Question 4

Which deployment model is used by SQL Database Projects?

A. Declarative deployment

B. Manual migration

C. Script-first deployment

D. Procedural deployment

Answer: A

Explanation: SQL Database Projects describe the desired end state, allowing the deployment engine to determine the required SQL statements.


Question 5

Why are Publish Profiles useful?

A. They encrypt databases.

B. They permanently store passwords inside source code.

C. They save deployment settings for reuse.

D. They improve query execution plans.

Answer: C

Explanation: Publish Profiles store deployment configuration such as server names, database names, and deployment options.


Question 6

What should a deployment pipeline typically do before publishing database changes?

A. Delete all indexes.

B. Generate and review a deployment script.

C. Disable all constraints.

D. Shrink the database.

Answer: B

Explanation: Reviewing generated deployment scripts helps identify unintended schema changes before deployment.


Question 7

Why is schema validation performed during the build process?

A. To increase transaction log size.

B. To encrypt the database.

C. To identify syntax errors and dependency issues before deployment.

D. To compress database files.

Answer: C

Explanation: Validation ensures that the project is internally consistent and can be successfully deployed.


Question 8

Which statement best describes incremental deployment?

A. Every database object is recreated during each deployment.

B. Only security objects are deployed.

C. Data is copied without changing the schema.

D. Only differences between the project and target database are deployed.

Answer: D

Explanation: SQL Database Projects compare the desired schema with the existing database and deploy only the necessary changes.


Question 9

Which practice best supports reliable database deployments?

A. Making schema changes directly in production.

B. Keeping the SQL Database Project as the authoritative source.

C. Editing production objects with SSMS only.

D. Avoiding source control.

Answer: B

Explanation: Using the SQL Database Project as the single source of truth supports consistent, repeatable, and auditable deployments.


Question 10

A team wants to automate database deployments across Development, Test, and Production environments. What is the recommended approach?

A. Manually execute SQL scripts on every server.

B. Use separate copies of the project for each environment.

C. Build one DACPAC and deploy it through a CI/CD pipeline using environment-specific settings.

D. Create a new SQL Database Project for every deployment.

Answer: C

Explanation: A single validated DACPAC can be deployed to multiple environments while Publish Profiles or pipeline variables provide environment-specific configuration.


Go to the DP-800 Exam Prep Hub main page

Detect schema drift by using 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
      --> Detect schema drift by using 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

Understanding schema drift is essential for modern DevOps and database lifecycle management (DLM). The DP-800 exam expects candidates to understand how SQL Database Projects establish the desired database state, how schema drift occurs, how to detect it before deployment, and how to prevent accidental overwrites of production databases.


What is Schema Drift?

Schema drift occurs when the actual database schema no longer matches the schema stored in source control or the SQL Database Project.

In other words:

  • Source control contains the expected design
  • Database contains the actual implementation

If someone changes the production database directly, the database “drifts” away from the project.

Example:

Project contains:

CREATE TABLE Sales.Customer
(
CustomerID INT PRIMARY KEY,
Name NVARCHAR(100)
);

A DBA later runs:

ALTER TABLE Sales.Customer
ADD LoyaltyPoints INT;

The SQL Database Project still contains only:

CustomerID
Name

The live database now contains:

CustomerID
Name
LoyaltyPoints

This difference is schema drift.


Why Schema Drift Is Dangerous

Schema drift creates several problems:

  • unexpected deployment failures
  • overwritten production changes
  • missing documentation
  • inconsistent environments
  • broken CI/CD pipelines
  • difficult troubleshooting
  • unreliable rollback

Organizations using DevOps aim to eliminate manual production changes because every manual change introduces drift.


Common Causes of Schema Drift

Manual Changes

A DBA executes:

ALTER TABLE Products
ADD InternalNotes NVARCHAR(200);

The project is never updated.


Emergency Production Fixes

A production outage occurs.

An engineer fixes the database immediately.

The fix is never committed back into Git.


Hotfix Deployments

A hotfix bypasses the normal deployment pipeline.

The database project remains outdated.


Third-Party Applications

Vendor software automatically creates:

  • indexes
  • tables
  • triggers
  • stored procedures

These objects may not exist in source control.


Automatic Maintenance Scripts

Jobs create:

  • audit tables
  • archive tables
  • logging procedures

If unmanaged, these appear as schema drift.


Desired State vs Actual State

SQL Database Projects follow a declarative model.

Instead of saying:

Execute these SQL commands.

They say:

The database should look like this.

Deployment tools compare:

Desired State (Project)

Current Database

Generate Deployment Script

The comparison process naturally identifies drift.


SQL Database Projects as the Source of Truth

A SQL Database Project should become the organization’s single source of truth.

Everything should originate from:

  • Git
  • pull requests
  • code reviews
  • approved deployments

Not from:

  • SSMS manual edits
  • Azure Data Studio changes
  • production hotfixes
  • direct ALTER TABLE statements

How Schema Comparison Works

The deployment engine compares:

Project Object

Database Object

It evaluates:

  • tables
  • columns
  • indexes
  • views
  • procedures
  • functions
  • triggers
  • users
  • roles
  • constraints
  • sequences

Every difference is identified before deployment.


Schema Compare

Schema Compare compares:

Source

Target

Possible comparisons include:

Project → Database

Database → Project

Database → Database

Project → Project

The generated report identifies:

  • missing objects
  • additional objects
  • modified objects
  • renamed objects
  • changed permissions

Example Drift Detection

Project contains:

CREATE TABLE Employee
(
EmployeeID INT,
Name NVARCHAR(100)
);

Database contains:

CREATE TABLE Employee
(
EmployeeID INT,
Name NVARCHAR(100),
Department NVARCHAR(50)
);

Schema Compare reports:

Table: Employee
Column missing from project:
Department

Drift During Deployment

Suppose:

Project:

Customer
Orders
Invoices

Production:

Customer
Orders
Invoices
AuditLog

If the deployment option allows dropping extra objects:

Deployment may attempt:

DROP TABLE AuditLog;

This could remove an important production table.

Understanding deployment options is therefore critical.


Deployment Reports

Before publishing, SQL Database Projects can generate:

  • deployment report
  • deployment script

The deployment report shows:

  • objects added
  • objects removed
  • objects modified

Reviewing the report is a best practice.


Deployment Script Review

Instead of deploying immediately:

Generate Script

Review

Approve

Deploy

This catches accidental schema drift before changes reach production.


Ignore Options

Some differences are expected.

Deployment settings allow ignoring:

  • whitespace
  • object order
  • permissions
  • filegroups
  • partition schemes
  • users
  • role memberships
  • extended properties

Ignoring irrelevant differences reduces false positives.


Drift Detection in CI/CD Pipelines

Typical pipeline:

Developer commits

Build project

Run validation

Compare schema

Detect drift

Generate report

Approve

Deploy

If drift exists:

Pipeline can:

  • fail
  • warn
  • require manual approval

Preventing Schema Drift

Best practices include:

Use Source Control

Every schema change should originate in Git.


Require Pull Requests

No direct commits to the main branch.


Block Direct Production Changes

Restrict:

  • ALTER
  • CREATE
  • DROP

to deployment pipelines.


Automate Deployments

Avoid manual publishing whenever possible.


Review Deployment Reports

Always inspect changes before production deployment.


Synchronize Hotfixes

If an emergency fix is applied directly to production:

  1. Update the SQL Database Project.
  2. Commit the change to source control.
  3. Redeploy from the project.

Detecting Drift with SqlPackage

SqlPackage can compare a DACPAC with a target database.

Example:

SqlPackage /Action:DeployReport

or

SqlPackage /Action:Script

These operations generate reports showing differences before deployment.


Azure DevOps and GitHub Actions

CI/CD pipelines commonly:

  • build the SQL Database Project
  • produce a DACPAC
  • compare with the target database
  • generate deployment scripts
  • detect unexpected schema changes
  • require approval before deployment

This ensures every deployment is repeatable and auditable.


Handling Intentional Drift

Sometimes production intentionally differs.

Examples:

  • monitoring tables
  • audit tables
  • replication objects
  • vendor-managed objects

Possible approaches:

  • exclude those objects
  • maintain separate projects
  • use deployment filters
  • configure ignore settings

Schema Drift vs Data Drift

These terms are different.

Schema DriftData Drift
Structure changesData values change
TablesRows
ColumnsRecords
IndexesBusiness data
ConstraintsTransactions

Example:

Schema drift:

ADD COLUMN Salary

Data drift:

Salary changed from 50000 to 70000

Best Practices

  • Treat the SQL Database Project as the single source of truth.
  • Never make untracked production schema changes.
  • Use pull requests and code reviews for every schema modification.
  • Generate deployment reports before publishing.
  • Review deployment scripts for unintended object drops.
  • Integrate schema comparison into CI/CD pipelines.
  • Keep production synchronized with source control after emergency fixes.
  • Use deployment options carefully to avoid deleting valid production objects.
  • Automate validation whenever possible.
  • Document intentional schema differences.

DP-800 Exam Tips

Remember these key exam points:

  • Schema drift means the database no longer matches the project.
  • SQL Database Projects define the desired database state.
  • Schema Compare identifies differences before deployment.
  • Deployment reports should always be reviewed.
  • CI/CD pipelines should automatically detect drift.
  • Source control should remain the authoritative definition of the schema.
  • Direct production modifications increase deployment risk.
  • Emergency fixes should always be merged back into the SQL Database Project.

Practice Exam Questions

Question 1

A database administrator manually adds a column to a production table without updating the SQL Database Project. What has occurred?

A. Data corruption

B. Schema drift

C. Query regression

D. Database fragmentation

Answer: B

Explanation: Schema drift occurs whenever the deployed database differs from the schema stored in the SQL Database Project.


Question 2

What is considered the desired state during SQL Database Project deployments?

A. The production database

B. The deployment report

C. The SQL Database Project

D. The Query Store

Answer: C

Explanation: SQL Database Projects define the desired schema used to generate deployment changes.


Question 3

Which tool compares a SQL Database Project with an existing database?

A. SQL Profiler

B. Database Mail

C. Activity Monitor

D. Schema Compare

Answer: D

Explanation: Schema Compare analyzes differences between project schemas and deployed databases.


Question 4

Why should deployment reports be reviewed before publishing?

A. To improve indexing

B. To compress data

C. To identify unexpected schema changes

D. To rebuild statistics

Answer: C

Explanation: Deployment reports identify additions, deletions, and modifications before changes are applied.


Question 5

Which practice best minimizes schema drift?

A. Allow direct production changes

B. Disable source control

C. Store only stored procedures in Git

D. Require all schema changes through source control

Answer: D

Explanation: Requiring every schema modification to flow through source control prevents unmanaged changes.


Question 6

Which deployment option helps prevent accidental removal of valid production objects?

A. Review deployment scripts before publishing

B. Disable indexes

C. Shrink the database

D. Disable Query Store

Answer: A

Explanation: Reviewing generated scripts allows teams to identify unintended DROP statements before deployment.


Question 7

An emergency production fix was made directly on the database. What should happen next?

A. Ignore the change

B. Remove the production change immediately

C. Update the SQL Database Project and commit the change

D. Rebuild every index

Answer: C

Explanation: Production hotfixes should be reflected in the project and committed to source control to eliminate schema drift.


Question 8

Which pipeline stage commonly detects schema drift?

A. Backup compression

B. Schema comparison before deployment

C. Statistics updates

D. Data import

Answer: B

Explanation: CI/CD pipelines typically compare the desired schema with the target database before deployment.


Question 9

Which statement correctly describes schema drift?

A. It refers to changes in business data.

B. It indicates poor query performance.

C. It describes missing backups.

D. It occurs when the deployed schema differs from the SQL Database Project.

Answer: D

Explanation: Schema drift specifically concerns differences between database structure and the project’s intended schema.


Question 10

Why are ignore settings sometimes configured during schema comparison?

A. To disable security

B. To ignore expected differences that should not trigger deployments

C. To improve backup speed

D. To compress deployment packages

Answer: B

Explanation: Ignore settings reduce false positives by excluding acceptable differences such as permissions or extended properties from deployment comparisons.


Go to the DP-800 Exam Prep Hub main page

Implement secrets management (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
      --> Implement secrets management


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 applications rarely operate in isolation. They connect to databases, Azure services, AI models, storage accounts, APIs, messaging services, and monitoring tools. Each connection typically requires credentials such as passwords, connection strings, API keys, certificates, tokens, or managed identities.

One of the most common security mistakes is storing these secrets directly in application code, SQL scripts, configuration files, or source control repositories. Modern DevOps practices eliminate this risk by implementing centralized secrets management, ensuring that sensitive information is securely stored, rotated, audited, and accessed only by authorized applications and users.

For the DP-800: Developing AI-Enabled Database Solutions certification exam, candidates should understand how secrets management integrates with SQL Database Projects, Azure DevOps, GitHub, Azure Key Vault, Managed Identity, Microsoft Entra ID, CI/CD pipelines, and Azure SQL Database deployments.


What Are Secrets?

A secret is any sensitive information used to authenticate or authorize access to a resource.

Examples include:

  • Database passwords
  • SQL authentication credentials
  • Azure Storage account keys
  • Azure OpenAI API keys
  • Azure AI Search API keys
  • Connection strings
  • Service Principal secrets
  • OAuth client secrets
  • Certificates
  • Personal Access Tokens (PATs)
  • SAS tokens
  • Encryption keys

Secrets should always be protected because unauthorized disclosure can compromise systems and data.


Why Secrets Management Is Important

Poor secrets management can result in:

  • Unauthorized database access
  • Data breaches
  • Credential theft
  • Service impersonation
  • Compliance violations
  • Accidental exposure in public repositories
  • Unauthorized AI model usage
  • Financial loss

Proper secrets management helps organizations achieve:

  • Least privilege
  • Secure authentication
  • Regulatory compliance
  • Credential rotation
  • Centralized auditing
  • Simplified administration

Common Security Risks

Common mistakes include storing secrets in:

{
"ConnectionString":
"Server=myserver;
User ID=admin;
Password=P@ssword123!"
}

or

CREATE LOGIN appuser
WITH PASSWORD='MyPassword!';

or

AzureOpenAIKey=abc123xyz

These files often become part of Git repositories and remain permanently visible in version history, even if later deleted.


Principles of Secrets Management

Microsoft recommends the following principles:

  • Never hard-code secrets.
  • Never store secrets in source control.
  • Use centralized secret stores.
  • Use managed identities whenever possible.
  • Rotate secrets regularly.
  • Grant only required permissions.
  • Audit secret access.
  • Automate secret retrieval.
  • Encrypt secrets both at rest and in transit.

Azure Key Vault

Azure Key Vault is Microsoft’s centralized secrets management service.

It securely stores:

  • Passwords
  • Keys
  • Certificates
  • Tokens
  • Connection strings
  • API keys

Applications retrieve secrets at runtime rather than storing them locally.

Benefits include:

  • Centralized management
  • Encryption
  • Access policies
  • Role-Based Access Control (RBAC)
  • Secret versioning
  • Automatic rotation support
  • Auditing
  • High availability

Types of Objects in Azure Key Vault

Azure Key Vault stores three object types:

Secrets

Examples:

  • Passwords
  • API keys
  • Connection strings

Keys

Used for:

  • Encryption
  • Digital signatures
  • Key management

Certificates

Used for:

  • TLS authentication
  • Client authentication
  • Secure communications

Secret Lifecycle

Typical lifecycle:

Create Secret
Store in Key Vault
Grant Access
Retrieve During Execution
Rotate
Update Applications
Retire Old Version

Secret Versioning

Azure Key Vault automatically versions secrets.

Example:

DatabasePassword
Version 1
Version 2
Version 3

Applications can:

  • Use the latest version
  • Pin to a specific version
  • Rotate without downtime

Managed Identity

Whenever possible, Microsoft recommends using Managed Identity instead of secrets.

Managed Identity eliminates:

  • Passwords
  • Client secrets
  • Credential rotation

Instead:

Azure automatically authenticates the workload.

Supported services include:

  • Azure SQL Database
  • Azure App Service
  • Azure Functions
  • Azure Container Apps
  • Azure Kubernetes Service
  • Azure Virtual Machines
  • Azure Data Factory
  • Microsoft Fabric services (where supported)

Types of Managed Identity

System-Assigned Managed Identity

Characteristics:

  • One identity
  • Lifecycle tied to the Azure resource
  • Automatically deleted with the resource

User-Assigned Managed Identity

Characteristics:

  • Independent Azure resource
  • Shared across multiple services
  • Longer lifecycle
  • Easier identity reuse

Microsoft Entra ID Authentication

Microsoft recommends using Microsoft Entra ID authentication rather than SQL logins whenever possible.

Benefits include:

  • Centralized identity management
  • Multi-factor authentication
  • Conditional Access
  • Passwordless authentication
  • Single Sign-On
  • Managed Identity integration

Secrets in SQL Database Projects

SQL Database Projects should never contain:

  • Passwords
  • API keys
  • Tokens
  • Production connection strings

Instead they should contain:

  • Schema definitions
  • Stored procedures
  • Functions
  • Views
  • Security objects
  • Build configurations

Secrets should be injected during deployment.


Secrets in Azure DevOps

Azure DevOps supports secure secret storage through:

  • Variable Groups
  • Secret Variables
  • Azure Key Vault integration
  • Service Connections
  • Managed Identity (supported services)

Example pipeline:

Build
Retrieve Secret
Deploy DACPAC
Remove Secret From Memory

Secrets remain encrypted throughout execution.


Secrets in GitHub

GitHub provides encrypted GitHub Secrets.

Secrets can be defined at:

  • Repository level
  • Environment level
  • Organization level

Examples:

  • SQL_PASSWORD
  • AZURE_CLIENT_ID
  • OPENAI_API_KEY

GitHub Actions retrieves them securely during workflow execution.


GitHub Actions Example

env:
SQL_PASSWORD: ${{ secrets.SQL_PASSWORD }}

The actual password never appears in the workflow file.


Azure DevOps Example

variables:
- group: ProductionSecrets

The pipeline references the secure variable group rather than storing credentials.


Secret Rotation

Secrets should be rotated periodically.

Reasons include:

  • Compliance
  • Reduced exposure
  • Personnel changes
  • Compromised credentials
  • Security policies

Rotation process:

Create New Secret
Update Applications
Validate
Disable Old Secret
Delete Old Secret

Access Control

Access should follow the Principle of Least Privilege.

Applications receive:

  • Only required permissions
  • Only required secrets
  • Only for required duration

Avoid granting:

  • Vault Administrator
  • Owner
  • Full secret access

Unless absolutely necessary.


RBAC vs Access Policies

Azure Key Vault supports:

Azure RBAC

Uses Azure role assignments.

Examples:

  • Key Vault Secrets User
  • Key Vault Administrator
  • Key Vault Reader

Recommended for new deployments.


Access Policies

Older permission model.

Still supported but Microsoft recommends RBAC for most new implementations.


Secret Auditing

Organizations should monitor:

  • Secret retrieval
  • Failed access attempts
  • Secret updates
  • Secret deletion
  • Permission changes

Azure Monitor and Azure Activity Logs provide auditing capabilities.


CI/CD Pipeline Integration

Typical deployment:

Developer
GitHub
Pull Request
Build
Retrieve Secrets
Deploy DACPAC
Azure SQL Database

Secrets remain outside source control throughout the deployment.


Environment-Specific Secrets

Different environments use different secrets.

Example:

EnvironmentDatabase
DevelopmentDev SQL
TestTest SQL
ProductionProduction SQL

Each environment references its own Key Vault or secret store.


Secure Connection Strings

Instead of:

Server=myserver;
User=admin;
Password=P@ssword123

Use:

  • Managed Identity
  • Microsoft Entra authentication
  • Secret references
  • Azure Key Vault retrieval

Preventing Secret Leakage

Organizations should:

  • Enable secret scanning
  • Use repository scanning
  • Review pull requests
  • Block committed secrets
  • Rotate exposed credentials immediately
  • Monitor repositories continuously

GitHub Advanced Security and Microsoft Defender for DevOps can detect exposed credentials.


Common Mistakes

Avoid:

  • Hard-coded passwords
  • SQL logins embedded in code
  • API keys inside scripts
  • Secrets in Git repositories
  • Emailing passwords
  • Sharing credentials among developers
  • Using production secrets in development
  • Long-lived credentials
  • Ignoring secret rotation

Best Practices

Microsoft recommends:

  • Use Azure Key Vault.
  • Prefer Managed Identity over passwords.
  • Use Microsoft Entra authentication.
  • Never commit secrets to Git.
  • Rotate secrets regularly.
  • Enable auditing.
  • Apply least privilege.
  • Separate secrets by environment.
  • Automate secret retrieval.
  • Protect CI/CD pipelines.
  • Use RBAC for Key Vault authorization.
  • Monitor secret access continuously.

DP-800 Exam Tips

Remember these important points:

  • Azure Key Vault is Microsoft’s preferred centralized secrets management solution.
  • Managed Identity is preferred over passwords or client secrets whenever supported.
  • SQL Database Projects should never contain secrets.
  • GitHub Secrets and Azure DevOps Secret Variables securely provide credentials during pipeline execution.
  • Secrets should be retrieved at runtime rather than stored in source code.
  • Secret rotation reduces the risk of credential compromise.
  • Microsoft Entra ID provides modern authentication with support for passwordless and managed identities.
  • Apply least privilege to secret access.
  • Enable auditing and monitoring for secret usage.
  • Never commit connection strings containing passwords to source control.

Practice Exam Questions

Question 1

A development team wants to eliminate database passwords from its Azure-hosted application. Which authentication method should be used whenever possible?

A. SQL Authentication with a strong password

B. Windows Authentication over VPN

C. Managed Identity

D. Shared administrator account

Answer: C

Explanation: Managed Identity allows Azure resources to authenticate to supported services without storing passwords or client secrets, reducing administrative overhead and improving security.


Question 2

Which Azure service is specifically designed to centrally store passwords, certificates, keys, and connection strings?

A. Azure Key Vault

B. Azure Monitor

C. Azure Storage

D. Azure Policy

Answer: A

Explanation: Azure Key Vault provides secure storage, versioning, access control, auditing, and rotation capabilities for secrets, keys, and certificates.


Question 3

A SQL Database Project needs to connect to an Azure SQL Database during deployment. Where should the production connection string password be stored?

A. In Azure Key Vault or a secure pipeline secret store

B. In a README file

C. In the SQL project file

D. In the source code comments

Answer: A

Explanation: Production credentials should never be committed to source control. They should be stored securely in Azure Key Vault or pipeline secret stores such as GitHub Secrets or Azure DevOps Secret Variables.


Question 4

Which practice represents the greatest security risk?

A. Using Microsoft Entra ID authentication

B. Storing passwords in Azure Key Vault

C. Using Managed Identity

D. Hard-coding API keys in application source code

Answer: D

Explanation: Hard-coded secrets are easily exposed through source control, backups, or application binaries and are considered a major security vulnerability.


Question 5

Why should secrets be rotated on a regular basis?

A. To reduce the risk associated with compromised credentials

B. To improve SQL query performance

C. To reduce storage costs

D. To simplify branching strategies

Answer: A

Explanation: Regular rotation limits the usefulness of compromised credentials and helps organizations meet compliance and security requirements.


Question 6

Which GitHub feature securely provides sensitive values to GitHub Actions workflows?

A. Repository Wiki

B. GitHub Issues

C. GitHub Releases

D. GitHub Secrets

Answer: D

Explanation: GitHub Secrets securely stores encrypted values that workflows can access during execution without exposing them in source code.


Question 7

A company wants applications to authenticate to Azure SQL Database using centralized identity management, Multi-Factor Authentication, and Conditional Access policies. Which authentication method best supports these requirements?

A. SQL logins

B. Microsoft Entra ID authentication

C. Shared local accounts

D. Anonymous authentication

Answer: B

Explanation: Microsoft Entra ID provides centralized authentication with advanced security features including MFA, Conditional Access, Single Sign-On, and integration with Managed Identity.


Question 8

Which authorization principle should be applied when granting applications access to secrets?

A. Full administrative access

B. Read and write access for all developers

C. Principle of Least Privilege

D. Anonymous access

Answer: C

Explanation: Applications should receive only the permissions required to perform their tasks, reducing the potential impact of compromised identities.


Question 9

What is the primary benefit of storing secrets outside a SQL Database Project?

A. Faster database indexing

B. Reduced network latency

C. Automatic SQL optimization

D. Sensitive credentials remain protected and can be managed independently of application code

Answer: D

Explanation: Separating secrets from application code improves security, supports credential rotation, simplifies compliance, and prevents accidental exposure through source control.


Question 10

A CI/CD pipeline retrieves a database password from Azure Key Vault immediately before deploying a DACPAC. What is the primary advantage of this approach?

A. It permanently stores the password inside the DACPAC.

B. It eliminates the need for authentication.

C. It allows credentials to be securely retrieved at deployment time without storing them in source control.

D. It improves query execution plans.

Answer: C

Explanation: Retrieving secrets during deployment keeps credentials out of source control and build artifacts while allowing secure, centralized management and rotation of sensitive information.


Go to the DP-800 Exam Prep Hub main page