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/ProductsPOST /api/ProductsPUT /api/ProductsDELETE /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
CustomersOrders
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
The Data Community 