DP-800: Connecting SQL Data, APIs, and Change Events

A software team has a working customer database and now needs three new behaviors. A mobile application should read a controlled subset of account data through an API. A reporting service should learn when orders change rather than reloading every record each hour. An AI search index should refresh when a product description is updated. These needs all touch data movement, but they do not call for one generic pipeline. Microsoft’s DP-800 exam covers SQL application integration through Data API builder, REST and GraphQL, change data capture, change tracking, change event streaming, Azure Functions, Azure Logic Apps, and secure service connections.

Data ingestion and pipelines cover a wide range of engineering activities, but a database-backed AI application has more specific requirements: expose only authorized operations and react to changes without compromising the source system. A nightly warehouse load has different latency and transaction guarantees from an authenticated customer checking an order through an API. An embedding refresh workflow adds another concern: reliably identifying updated or deleted source content so stale information does not survive in a retrieval index.

Start with the consumer and the allowed data contract

Before choosing an integration product, specify what the consumer needs. A customer portal might read orders belonging to the signed-in account and create a return request. A reporting process might need only aggregated totals. A text-embedding process might receive product descriptions but not payment or identity fields. These requirements should become data contracts: permitted entities, fields, filters, updates, freshness expectations, error handling, and service identity. Exposing an entire table merely because it exists is not a contract; it delegates too much authority to every downstream client.

A relational database can enforce constraints and permissions, but an API must preserve those rules at its boundary. A request that supplies an order number must still be scoped to the authorized customer. A pagination feature needs stable ordering if a client is expected to consume many records. A search parameter cannot be allowed to become arbitrary SQL execution. Test requests that ask for someone else’s identifier, select unsupported fields, supply unusually large result limits, or contain malformed values. The correct response is a predictable refusal or validated result, not accidental disclosure or an unbounded query against production tables.

Use Data API builder deliberately

Microsoft Data API builder (DAB) can expose configured database objects through REST and GraphQL interfaces. A configuration describes entities and the API behavior available to consumers. The key design step is deciding which table, view, or procedure should appear as an entity and what operations should be permitted. A customer-facing service might expose a constrained view instead of the underlying order table. Authentication, authorization, entity configuration, query behavior, and deployment settings must be reviewed together. Putting a database behind a URL does not by itself make that data safe for public consumption.

REST is often convenient for straightforward resource operations, while GraphQL can support clients needing a structured schema and selected relationships. The choice should reflect client requirements and the features supported by the specific database and DAB version. An API with powerful filtering and selection capabilities can accidentally generate expensive database work if limits and indexes are ignored. An administrative integration may benefit from a service principal or managed identity rather than a shared connection password. Consider the integration from the standpoint of the database: the API should be an intentionally constrained representation of business operations, not a workaround for missing access design.

Choose REST, GraphQL, and direct database access with care

Client applications have different trust and operational contexts. A mobile phone should not generally receive unrestricted SQL credentials or be expected to manage connection pooling and transaction behavior directly. A controlled API can mediate identity, validation, throttling, and application rules. A trusted backend workload may have different integration options, but should still operate under a narrowly defined database identity. GraphQL offers flexibility in selected fields and relationships, yet that flexibility requires thought about query complexity and authorization at field or entity boundaries where supported.

For example, an equipment-service portal might display an order, its tasks, and the technician’s published visit window. A GraphQL relationship could make the screen convenient to build, but internal technician notes should not become visible merely because they share the order identifier. Define the permitted projection and test it using the least privileged consumer identity. The broader application-integration responsibilities of AZ-204 development intersect with these APIs, but DP-800 requires deeper scrutiny of SQL objects, execution paths, and the database security boundary underneath them.

Compare change tracking with change data capture

Change tracking and change data capture (CDC) both help applications discover database changes, but they answer different questions. Change tracking is designed to efficiently identify that rows changed so a consumer can obtain current data. CDC can provide richer information about data modifications under supported configurations, including recorded change detail suitable for appropriate integration and auditing patterns. Neither should be casually described as an infinite, maintenance-free event log. Retention, cleanup, configuration, platform support, and consumer lag affect whether a synchronization process can recover after downtime.

Suppose a mobile service synchronizes a user’s current list of open orders. It may need the identifiers of changed rows and the latest values; retaining a detailed history of every intermediate update could be unnecessary. By contrast, a downstream process that must interpret individual change operations may need richer change records. Make the requirement explicit, including delete handling. A consumer that only reads the current table cannot discover a deleted row unless the change mechanism supplies an appropriate signal. Build test cases for a row inserted, updated twice, deleted, and then changed while the consumer is offline.

Decide when application events need orchestration

Azure Functions with supported SQL trigger bindings, Azure Logic Apps, and change event streaming can connect a source database with downstream activities. A service might generate an email confirmation after an order transition or recalculate embeddings when a knowledge article changes. These tools offer orchestration choices, not guarantees of exactly-once business execution in every arrangement. Design for retries, duplicate notifications, temporary outages, rate limits, ordering requirements, and dead-letter or reconciliation processes as appropriate. An event may be delivered more than once; a correctly designed consumer should not create two refunds merely because it sees the same order update twice.

A robust integration usually includes an event identifier or a version of the changed entity, idempotent processing, observable failures, and a way to resume after missed work. Decide whether the source application should block a transaction while an external service responds. It often should not. Committing the authoritative order change and initiating downstream work through a controlled asynchronous path may reduce latency and failure coupling. However, when a business action genuinely requires atomic consistency, splitting it into several uncoordinated services creates different risks. Study the transaction boundary before recommending a trigger or workflow.

Keep AI search indexes synchronized without exposing secrets

Embedding maintenance introduces a particular integration problem. The source database may contain a product description and an authorization scope, while the search index holds derived vectors that must be regenerated when content changes. A change mechanism might signal that an affected row should be reprocessed. The embedding generator may call an external model endpoint and store a new vector, perhaps after splitting a long document into chunks. It must also remove or invalidate vectors from deleted or reclassified records. A refresh strategy that only adds new content will eventually return material that the organization intended to retire.

Design an update record that identifies the source object, source version, permitted data set, current processing status, and last successful embedding version. Avoid transmitting secrets or unrelated customer information to the model as a convenience. If embedding production fails, preserve a visible retry state rather than silently serving stale results forever. If the source record changes while an older embedding job is running, prevent the older result from overwriting a newer state. These details make the AI component a maintainable data consumer rather than an opaque batch job. The model’s explanation is only as reliable as the records that the integration chooses to expose.

Monitor the contract, not just the pipeline status

A green orchestration run may still deliver incomplete or unauthorized data. Monitor freshness against the business objective, response latency, record counts, error classes, synchronization lag, and the number of changes awaiting downstream work. Test a client identity with insufficient permissions and verify it cannot circumvent restrictions through a different API operation or a more permissive entity. Review audit logs for elevated connections, repeated authorization failures, and unusually expensive queries. An API that succeeds on a handful of sample requests may behave poorly when a new version of the mobile application requests far more data.

The strongest DP-800 integration exercise starts with a small SQL database and two consumers: a restricted customer-facing endpoint and an internal change-driven service. Add new records, edit them, delete one, interrupt the consumer, and resume. Observe whether the API enforces the correct access boundary and whether the downstream representation returns to a current, consistent state. This is different from the larger data-platform orchestration focus of DP-700. Here the primary question is how to make the application database’s controlled facts usable by other systems without surrendering integrity or security.