Build, Store, Version, and Manage Container Images by Using Azure Container Registry (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Build, store, version, and manage container images by using Azure Container Registry


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.

Overview

Azure Container Registry (ACR) is a managed, private registry service in Azure for storing and managing container images and other OCI-compatible artifacts. It provides a central location from which containerized applications can obtain the images they need to run on services such as Azure App Service, Azure Container Apps, Azure Kubernetes Service (AKS), and Azure Container Instances.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand more than simply how to push an image into ACR. You should be comfortable with the hierarchy of registries, repositories, images, tags, manifests, and layers; image versioning strategies; building images using ACR Tasks; managing and deleting images; and selecting appropriate authentication and registry capabilities.

The current Microsoft Learn study guide specifically identifies this objective as part of Implement container application hosting. It also separately identifies ACR Tasks as an exam objective, so understanding how ACR stores images and how ACR Tasks builds them is particularly important.


1. What Is Azure Container Registry?

Azure Container Registry is a private container registry service hosted in Azure.

A container registry solves a fundamental problem in containerized application development:

Where do applications securely obtain the container images they need to run?

Instead of relying exclusively on a public registry, an organization can maintain its own private registry in Azure.

A typical workflow looks like this:

Developer
|
| Build container image
v
Docker / ACR Tasks
|
| Push
v
Azure Container Registry
|
+------------------+
| |
v v
Azure App Service AKS
| |
v v
Container Apps Container workloads

ACR provides capabilities for:

  • Storing container images
  • Storing OCI artifacts
  • Organizing images into repositories
  • Tagging and versioning images
  • Pushing and pulling images
  • Building images using ACR Tasks
  • Managing image metadata
  • Controlling access
  • Replicating images across regions
  • Integrating with Azure container services

Microsoft describes ACR as a private, managed registry that supports building, storing, and managing images for container deployments.


2. Understand the ACR Hierarchy

One of the most important concepts for AI-200 is understanding how ACR organizes container content.

The hierarchy can be thought of as:

Azure Container Registry
|
+-- Repository
| |
| +-- Image : Tag
| +-- Image : Tag
| +-- Image : Tag
|
+-- Repository
|
+-- Image : Tag
+-- Image : Tag

The important concepts are:

  1. Registry
  2. Repository
  3. Artifact/Image
  4. Tag
  5. Manifest
  6. Layer
  7. Digest

Understanding the distinctions between these concepts is a common source of exam questions.


2.1 Registry

The registry is the overall ACR resource.

For example:

contosoregistry.azurecr.io

The registry provides the endpoint through which clients push and pull container images.

A registry can contain many repositories.


2.2 Repository

A repository is a collection of related container images or artifacts.

For example:

contosoregistry.azurecr.io/customer-api

The repository could contain:

customer-api:v1
customer-api:v2
customer-api:v3

Repositories can also use namespaces:

contosoregistry.azurecr.io/marketing/campaign-api:v2

Namespaces help organize repositories logically, although they aren’t independent Azure resources or hierarchical security boundaries simply because they contain / characters.

Microsoft notes that repository names can include namespaces and are managed independently by the registry.


3. Container Image Tags

A tag provides a human-readable identifier for a particular version or variant of an image.

For example:

customer-api:v1
customer-api:v2
customer-api:2026-08-07
customer-api:production

The complete image reference might be:

contosoregistry.azurecr.io/customer-api:v2

The structure is:

<registry>/<repository>:<tag>

For example:

contosoregistry.azurecr.io/customer-api:v2

where:

ComponentValue
Registrycontosoregistry.azurecr.io
Repositorycustomer-api
Tagv2

Microsoft recommends using appropriate tagging strategies for deployment scenarios and notes that latest is used by default when no tag is specified in Docker commands.


4. Tagging and Versioning Strategies

Image versioning is extremely important for reliable deployments.

Consider:

customer-api:latest

This tag is convenient, but it does not necessarily identify an immutable version.

Suppose today’s latest points to:

Image A

and tomorrow the same tag is updated:

latest → Image B

A deployment configured to use latest may therefore receive a different image without its configuration changing.

For production deployments, a better approach is generally to use unique version identifiers.

Examples:

customer-api:v1.0.0
customer-api:v1.1.0
customer-api:v1.2.0

or:

customer-api:20260807.1
customer-api:20260807.2

or a source-control commit identifier:

customer-api:a81f42c

A useful pattern is:

latest → convenient development/testing reference
v1.4.2 → human-readable release
a81f42c → unique build identifier

Exam Tip

If a question asks how to ensure that a deployment consistently uses a specific image version, be cautious about answers using:

:latest

A unique tag or, even more strongly, an image digest provides better version specificity.


5. Image Digests

Container images are also identified by a digest.

For example:

contosoregistry.azurecr.io/customer-api@sha256:abc123...

A digest identifies the content associated with a manifest.

Compare:

customer-api:v2

with:

customer-api@sha256:abc123...

A tag can be moved to point to another image.

A digest identifies a specific content-addressed version.

Microsoft specifically notes that pulling by digest guarantees the image version being retrieved even if an identically tagged image is subsequently pushed.

Exam Tip

Remember:

Tag = human-friendly version reference

Digest = content-addressed, precise image reference


6. Container Image Layers

Container images consist of one or more layers.

Dockerfiles commonly create multiple layers.

For example:

FROM python:3.12
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .

The resulting image is composed of layers.

One of the advantages of layers is reuse.

If two images share the same base layers, those layers don’t necessarily have to be independently stored and transferred each time.

This can reduce storage and transfer requirements.


7. Manifests

A container image is associated with a manifest.

The manifest contains information needed to identify the image and its layers.

Conceptually:

Image Manifest
|
+-- Configuration
|
+-- Layer 1
+-- Layer 2
+-- Layer 3

The manifest is also associated with the image’s digest.

This distinction matters when managing images in ACR.

For example, removing a tag doesn’t necessarily mean that all image data is immediately removed.

An untagged manifest and its associated layers may continue to consume storage until they are deleted and no longer referenced.

Microsoft specifically warns that repeatedly pushing modified artifacts with identical tags can create untagged artifacts that continue consuming registry storage.


8. Pushing an Image to ACR

A common workflow is:

Step 1: Build the image

docker build -t customer-api:v1 .

Step 2: Tag the image with the ACR login server

docker tag customer-api:v1 \
contosoregistry.azurecr.io/customer-api:v1

Step 3: Authenticate to ACR

az acr login --name contosoregistry

Step 4: Push the image

docker push \
contosoregistry.azurecr.io/customer-api:v1

The image is now stored in:

contosoregistry.azurecr.io/customer-api

with the tag:

v1

9. Pulling an Image

A client can pull the image by tag:

docker pull \
contosoregistry.azurecr.io/customer-api:v1

Or by digest:

docker pull \
contosoregistry.azurecr.io/customer-api@sha256:<digest>

The second approach provides stronger guarantees regarding exactly which image content is retrieved.


10. Azure Container Registry Tasks

One of the most important ACR features for AI-200 is ACR Tasks.

ACR Tasks allows container images to be built in Azure rather than requiring the developer to perform the build locally.

Microsoft describes ACR Tasks as a suite of capabilities for building, testing, and managing container images.

For example:

az acr build \
--registry contosoregistry \
--image customer-api:v1 \
--file Dockerfile .

The command:

  1. Sends the build context to Azure.
  2. Uses the Dockerfile.
  3. Builds the image in Azure.
  4. Tags the resulting image.
  5. Pushes the resulting image into the registry.

This is particularly useful when a developer doesn’t have Docker installed locally.

Microsoft’s current quickstart explicitly demonstrates building, pushing, and running an image using ACR Tasks without requiring a local Docker installation.


11. ACR Tasks Quick Tasks

A quick task is useful for an on-demand image build.

For example:

az acr build \
--registry contosoregistry \
--image customer-api:v1 \
.

This is useful during the development inner loop.

Instead of:

Developer machine
|
+-- docker build
+-- docker tag
+-- docker push

you can use:

Developer
|
| az acr build
v
Azure
|
+-- Build
+-- Tag
+-- Push
v
ACR

12. Automated ACR Tasks

ACR Tasks can also be configured to automatically execute when certain events occur.

For example:

Git commit
|
v
ACR Task
|
+-- Build image
+-- Test image
+-- Push image

ACR Tasks can also respond to base image updates.

For example, suppose an application uses:

FROM python:3.12

A base-image update can trigger an ACR Task to rebuild the application image.

This is useful for keeping application images current when their base images change.

Microsoft documents ACR Tasks triggers for Git commits and base-image updates.


13. Multi-Step ACR Tasks

ACR Tasks can execute more sophisticated workflows.

For example:

Build application image
|
v
Run application
|
v
Run test container
|
v
Push image

Multi-step tasks are defined using YAML.

A simplified example is:

version: v1.1.0
steps:
- build: -t $Registry/customer-api:$ID .
- push:
- $Registry/customer-api:$ID
- cmd: $Registry/customer-api:$ID

ACR Tasks supports three major step types:

StepPurpose
buildBuild a container image
pushPush an image to a registry
cmdRun a container as a command

Exam Tip

If a question describes a workflow that needs to build, test, and push multiple containers, think:

ACR Tasks multi-step task


14. ACR Tasks and External Registries

ACR Tasks can also interact with other registries.

For example, a task may need to:

ACR
|
+-- Pull base image from another registry
|
+-- Build application
|
+-- Push application image to ACR

Credentials can be configured for tasks when access to another registry is required.

For more secure scenarios, ACR Tasks can use managed identities to access protected Azure resources without embedding credentials directly in task definitions.


15. Authentication to Azure Container Registry

ACR is generally private, so clients need appropriate authentication and authorization to access it.

Common authentication approaches include:

  • Microsoft Entra identities
  • Managed identities
  • Service principals
  • Administrator credentials
  • Repository-scoped access mechanisms
  • Anonymous pull, where explicitly configured and supported

Microsoft’s documentation emphasizes that ACR operations such as push and pull require authentication unless anonymous pull is enabled.


16. Managed Identity and ACR

Managed identities are particularly important in Azure-native applications.

Suppose an AKS cluster needs to pull an image:

AKS
|
| Managed Identity
v
Azure Container Registry
|
v
customer-api:v1

Rather than storing a registry password in application configuration, the Azure resource can use a managed identity and appropriate permissions.

For a non-ABAC-enabled registry, a common pull-only role is:

AcrPull

For push and pull:

AcrPush

For ABAC-enabled registries, Microsoft documents repository-scoped roles such as:

Container Registry Repository Reader
Container Registry Repository Writer

The exact role depends on the registry’s authorization model.

Exam Tip

When the question says:

“An Azure service needs to pull images from ACR without storing credentials.”

Think:

Managed identity + appropriate ACR permissions


17. ACR Pricing Tiers

Azure Container Registry currently provides three pricing tiers:

  • Basic
  • Standard
  • Premium

The tiers provide increasing capacity and capabilities.

CapabilityBasicStandardPremium
Intended useLower-volume scenariosProduction scenariosHigh-volume/advanced scenarios
Included storage10 GiB100 GiB500 GiB
Geo-replicationNoNoYes
Private endpointsNoNoYes
Content trustNoNoYes
Customer-managed keysNoNoYes
Dedicated Tasks agent poolsNoNoYes
Higher throughput/concurrencyLowerMediumHigher

All three tiers provide core registry capabilities, while Premium adds advanced capabilities and higher limits.

Important Exam Distinction

If the requirement is:

“Replicate a registry across multiple Azure regions.”

Think:

Premium ACR

Geo-replication is a Premium feature.


18. Geo-Replication

Geo-replication allows an ACR to replicate its content across multiple Azure regions.

For example:

                 Azure Container Registry
                          |
             +------------+------------+
             |                         |
             v                         v
         East US                  West Europe
        Geo-replica               Geo-replica
             |                         |
             v                         v
          AKS US                  AKS Europe

When an image is pushed to the geo-replicated registry, its content is synchronized to the configured replicas.

The advantage is that applications can access images from regions closer to where they run.

Microsoft describes geo-replication as providing a single registry management experience while synchronizing content across selected regions.

Don’t confuse:

Availability zones and geo-replication.

Availability zones provide resilience across zones within a region.

Geo-replication distributes registry content across different Azure regions.

Current Microsoft documentation states that zone redundancy is enabled by default for ACR registries in supported regions across Basic, Standard, and Premium tiers.


19. Managing Images and Repositories

You can manage repositories and images through:

  • Azure portal
  • Azure CLI
  • REST APIs
  • SDKs
  • Docker/OCI tooling

For example, you can list repositories:

az acr repository list \
--name contosoregistry \
--output table

List tags:

az acr repository show-tags \
--name contosoregistry \
--repository customer-api \
--output table

You can also inspect manifests and image metadata.

The Azure portal exposes repositories and their image tags through the registry’s Repositories interface.


20. Deleting Images

Suppose a repository contains:

customer-api:v1
customer-api:v2
customer-api:v3

You can remove an image tag using Azure CLI.

For example:

az acr repository untag \
--name contosoregistry \
--image customer-api:v1

However, remember an important distinction:

Untagging an image does not necessarily immediately remove the underlying image data.

The manifest may become untagged while its layers continue consuming storage.

Microsoft specifically warns about the accumulation of untagged artifacts when images are repeatedly pushed using the same tags.


21. Retention of Untagged Manifests

ACR supports a retention policy for untagged manifests.

The purpose is to automatically remove untagged manifests after a configured period.

For example:

Image:v1
Image:v2
Image:v3

If v2 is removed:

Image:v2 → untagged manifest

A retention policy can eventually remove the untagged manifest.

The current Microsoft documentation identifies the untagged-manifest retention policy as a Premium feature and currently documents it as a preview feature. The policy can be configured for a retention period from 0 through 365 days.

Important Warning

If an application relies on pulling an image by its digest, automatically deleting untagged manifests can make that image unavailable.

This is an important operational consideration and a potential exam scenario.


22. Image Tagging Best Practices

A strong production tagging strategy should make image identification predictable.

A useful approach is to use multiple tags for different purposes.

For example:

customer-api:v2.4.1
customer-api:build-1847
customer-api:a81f42c

You might also maintain:

customer-api:production

as a deployment-oriented alias.

However, don’t rely on a mutable tag such as production or latest when you require immutable deployment behavior.

A good pattern is:

Human-readable release
+
Unique build identifier
+
Optional environment alias

For example:

customer-api:v2.4.1
customer-api:build-1847
customer-api:production

The production deployment can ultimately be pinned to a specific immutable image reference/digest.


23. Common ACR Mistakes

Mistake 1: Using latest for production deployments

latest can change.

Better: use unique version tags and/or digests.


Mistake 2: Assuming deleting a tag deletes the image immediately

An untagged manifest may continue consuming storage.

Better: understand manifests, layers, untagging, deletion, and retention.


Mistake 3: Giving every workload push permissions

An application that only needs to run an image generally doesn’t need permission to push images.

Better: follow least privilege.

For example:

Application → AcrPull
Build pipeline → AcrPush

Mistake 4: Storing registry passwords in application code

This creates unnecessary credential-management risks.

Better: use managed identities or another appropriate identity mechanism.


Mistake 5: Choosing Premium solely because it sounds better

Premium should be selected because its capabilities are required.

Examples include:

  • Geo-replication
  • Private endpoints
  • Content trust
  • Higher throughput
  • Advanced networking
  • Dedicated Tasks agent pools

Mistake 6: Confusing ACR with ACR Tasks

They are related but different concepts.

ACR:

Stores and manages container images.

ACR Tasks:

Builds, tests, and automates container image workflows.

A single ACR resource can therefore be used to store images while ACR Tasks provides the automation to build those images.


24. Important AI-200 Concepts to Know

For this exam objective, make sure you can explain the following without referring to documentation:

ConceptWhat you should know
Azure Container RegistryManaged private container registry
RegistryTop-level ACR resource
RepositoryCollection of related images/artifacts
TagHuman-readable image/version reference
DigestContent-addressed image reference
ManifestDescribes image/artifact and its layers
LayerComponent of a container image
az acr loginAuthenticates a client to ACR
docker pushUploads an image to ACR
docker pullDownloads an image from ACR
az acr buildBuilds an image using ACR Tasks
ACR TasksCloud-based image build/test automation
Multi-step taskBuild/test/push workflows using YAML
AcrPullPull permission for applicable non-ABAC registry scenarios
AcrPushPush/pull permission for applicable non-ABAC registry scenarios
Managed identityCredential-free Azure resource authentication
BasicEntry-level ACR tier
StandardHigher capacity production-oriented tier
PremiumAdvanced capabilities such as geo-replication/private endpoints
Geo-replicationReplicate registry content across regions
Retention policyAutomatically remove eligible untagged manifests

25. AI-200 Scenario Patterns to Recognize

The exam is likely to test your ability to choose the appropriate Azure capability based on a scenario.

Scenario: Build without Docker locally

Requirement: Developers don’t have Docker installed.

Answer: ACR Tasks / az acr build.


Scenario: Automatically rebuild after a Git commit

Requirement: Every source-code commit should trigger an image build.

Answer: ACR Task with a source-code trigger.


Scenario: Rebuild after base image updates

Requirement: Automatically rebuild application images when their base image changes.

Answer: ACR Tasks base-image trigger.


Scenario: Run the same image in several Azure regions

Requirement: Applications in multiple regions should access registry content efficiently.

Answer: ACR Premium with geo-replication.


Scenario: Application only needs to pull images

Requirement: A workload should retrieve images but shouldn’t be able to modify them.

Answer: Grant an appropriate pull-only role, such as AcrPull where applicable, or the appropriate repository reader role for an ABAC-enabled registry.


Scenario: Avoid credentials in application configuration

Requirement: An Azure-hosted application needs to access ACR without storing passwords.

Answer: Managed identity + appropriate registry permissions.


Scenario: Guarantee a specific image

Requirement: A deployment must always retrieve exactly the same image content.

Answer: Use an image digest rather than relying solely on a mutable tag.


26. Quick Review

The following mental model is useful for the exam:

                    AZURE CONTAINER REGISTRY
                             |
             +---------------+---------------+
             |                               |
        Repositories                    ACR Tasks
             |                               |
      +------+------+                  Build/Test/Push
      |             |
   Image          Image
      |             |
    Tags          Tags
      |             |
   Manifest      Manifest
      |
    Layers

And remember the major distinction:

ACR
Store/manage images
ACR Tasks
Build/test/automate images

For production deployments:

Avoid:
:latest
Prefer:
:v2.4.1
:build-1847
@sha256:<digest>

For authentication:

Azure workload
|
| Managed Identity
v
ACR
|
| Appropriate least-privilege role
v
Pull image

For global deployments:

ACR Premium
|
+---- Region 1
|
+---- Region 2
|
+---- Region 3

Practice Exam Questions

Question 1

A development team has a Dockerfile and wants to build a container image directly in Azure. Developers should not need Docker installed on their local computers. The resulting image should be pushed to Azure Container Registry.

Which Azure capability should you use?

A. Azure Container Registry Tasks

B. Azure App Service deployment slots

C. Azure Container Apps revisions

D. Azure Kubernetes Service Jobs

Answer: A

Explanation: Azure Container Registry Tasks can build container images in Azure using a Dockerfile. The az acr build command provides an on-demand build capability and can push the resulting image to ACR. A local Docker installation isn’t required for this workflow.


Question 2

An application image is stored as:

contosoregistry.azurecr.io/orders:v4

What does v4 represent?

A. The registry name

B. The image tag

C. The image digest

D. The repository namespace

Answer: B

Explanation: In an image reference such as:

registry/repository:tag

the portion after the colon is the tag. Therefore, v4 is the image tag. Tags are commonly used to identify image versions.


Question 3

A production application must always retrieve exactly the same container image content. Developers are concerned that a tag could later be reassigned to a different image.

Which image reference should the application use?

A. :latest

B. :production

C. :stable

D. @sha256:<digest>

Answer: D

Explanation: Tags can be moved to different image versions. A digest is a content-addressed identifier and can be used to pull a specific image version. Microsoft specifically identifies digest-based pulls as a way to guarantee the image version being retrieved.


Question 4

An organization deploys applications to Azure regions in North America and Europe. The organization wants container images to be replicated to both regions while maintaining a single ACR management experience.

Which ACR capability should be used?

A. Repository namespaces

B. Availability zones

C. Geo-replication

D. Image tags

Answer: C

Explanation: ACR geo-replication synchronizes registry content across selected Azure regions while allowing the organization to manage the registry as a single logical registry. Geo-replication is a Premium ACR capability.


Question 5

An AKS workload needs to pull private container images from ACR. The organization does not want to store registry passwords in Kubernetes configuration.

Which approach is most appropriate?

A. Use a managed identity with appropriate ACR permissions

B. Store the ACR administrator password in the container image

C. Make the repository publicly accessible

D. Embed an ACR password in the application source code

Answer: A

Explanation: Azure resources can use managed identities to authenticate to ACR without storing credentials in application code or configuration. The identity must be granted the appropriate pull permissions.


Question 6

A development team wants an automated container workflow that performs the following:

  1. Builds an application image.
  2. Runs a test container.
  3. Builds another image.
  4. Pushes the resulting images.

Which ACR capability should the team use?

A. ACR repository namespaces

B. ACR multi-step Tasks

C. ACR geo-replication

D. ACR anonymous pull

Answer: B

Explanation: ACR Tasks supports multi-step workflows using YAML. The workflow can build, run/test, and push one or more images. The available step types include build, push, and cmd.


Question 7

An organization repeatedly pushes new builds using the same image tag. After several months, the registry contains significant amounts of storage that cannot be explained by the currently tagged images.

What is the most likely explanation?

A. ACR automatically creates a new repository for every push

B. Geo-replication is duplicating every image within the same region

C. Previous manifests became untagged while their image data remained in the registry

D. ACR stores every Dockerfile indefinitely

Answer: C

Explanation: Repeatedly pushing modified images using the same tag can result in previous manifests becoming untagged. Their layers can continue consuming registry storage until the underlying content is deleted.


Question 8

A company needs to automatically rebuild its application container whenever a new version of the application’s base container image becomes available.

Which capability should be configured?

A. Azure App Service deployment slots

B. ACR geo-replication

C. ACR repository tagging

D. An ACR Task with a base-image update trigger

Answer: D

Explanation: ACR Tasks can automatically trigger builds when a base image is updated. This is useful for rebuilding application images when their underlying base images change.


Question 9

An organization requires private connectivity to its Azure Container Registry through Azure Private Link. Which ACR pricing tier supports this capability?

A. Premium

B. Basic

C. Standard

D. All three tiers

Answer: A

Explanation: Azure Container Registry Premium supports private endpoints through Private Link. Basic and Standard do not provide this capability according to the current ACR SKU documentation.


Question 10

An administrator removes the v1 tag from an image in an ACR repository. The administrator assumes that the underlying image data has immediately been removed from the registry.

Which statement is correct?

A. Removing a tag always immediately deletes every associated layer

B. Removing a tag converts the image automatically into a public image

C. Removing a tag deletes the entire repository

D. The manifest can become untagged while its data continues consuming storage

Answer: D

Explanation: Removing a tag can leave the manifest untagged while its associated data remains in the registry. Untagged artifacts can continue consuming storage until they are deleted. ACR provides mechanisms such as retention policies for eligible untagged manifests.


Final AI-200 Takeaways

For this particular AI-200 objective, concentrate on these distinctions:

Azure Container Registry

Store and manage container images and artifacts.

ACR repository

Organizes related images.

Tag

Human-readable version/reference that can be reassigned.

Digest

Content-addressed identifier for a specific image version.

Manifest

Describes the image/artifact and its layers.

ACR Tasks

Build, test, and automate container image workflows.

az acr build

Perform an on-demand cloud-based container build.

Multi-step ACR Task

Build/test/push multiple images or perform multi-stage workflows.

Managed identity

Authenticate Azure workloads to ACR without managing passwords.

AcrPull

Pull permission for applicable non-ABAC registry scenarios.

AcrPush

Push/pull permission for applicable non-ABAC registry scenarios.

Premium

Required for capabilities such as geo-replication and private endpoints.

Geo-replication

Replicate registry content across Azure regions.

Retention

Help clean up eligible untagged manifests.

The most important exam mindset is to distinguish where the image is stored, how it is identified, how it is built, and how the workload is authorized to retrieve it. Those four dimensions—registry/repository, tag/digest, ACR Tasks, and authentication/RBAC—cover a large portion of the practical knowledge behind this objective.


Go to the AI-200 Exam Prep Hub main page

Implement a change feed processor to detect and handle new or updated items (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Cosmos DB for NoSQL
      --> Implement a change feed processor to detect and handle new or updated items


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.

Overview

Azure Cosmos DB for NoSQL provides a change feed that records changes made to items in a container. Applications can consume this feed to react to data changes without repeatedly querying the entire container.

For the AI-200 exam, an important implementation pattern is the change feed processor. It provides a push-based mechanism for detecting changes and delivering them to application code for processing.

A change feed processor is particularly useful when an application needs to perform an action whenever items are created or updated, such as:

  • Processing newly submitted documents
  • Generating embeddings for newly created content
  • Updating a search index
  • Synchronizing data with another system
  • Running AI processing when new data arrives
  • Performing analytics or enrichment
  • Triggering downstream business workflows
  • Maintaining materialized or derived data

The change feed processor also handles important operational concerns such as checkpointing, load balancing, lease management, and recovery.


1. What Is the Azure Cosmos DB Change Feed?

The change feed is a persistent record of changes to items in an Azure Cosmos DB container.

Conceptually, it looks like this:

Application
|
| Creates/updates items
v
Azure Cosmos DB Container
|
| Change feed
v
Change Feed Processor
|
+--> Process new item
+--> Generate embedding
+--> Update search index
+--> Call downstream service
+--> Store derived data

Instead of repeatedly asking:

“Which items have changed since the last time I checked?”

the application can consume the change feed and process changes incrementally.

This makes the change feed especially useful for event-driven and near-real-time architectures.


2. Latest Version Change Feed Mode

For the AI-200 scenario involving detection of new or updated items, the default latest version change feed mode is particularly important.

In latest version mode:

  • Creates appear in the change feed.
  • Updates appear in the change feed.
  • Deletes do not appear.
  • If an item is changed multiple times before it is read, the feed provides the latest version rather than every intermediate version.

For example:

Item created
|
v
Status = "Pending"
|
v
Status = "Processing"
|
v
Status = "Completed"

If these changes occur before the consumer reads the feed, latest-version mode may expose the current version rather than every intermediate state.

Therefore, latest-version mode is appropriate when the application cares about the current state of changed items, rather than every individual mutation.

Important exam distinction

If an application must detect deletes or process every intermediate version, latest-version mode isn’t sufficient.

Azure Cosmos DB also supports all versions and deletes mode, which captures creates, updates, and deletes. That mode has additional requirements, including continuous backup, and is available for Azure Cosmos DB for NoSQL.


3. What Is a Change Feed Processor?

The change feed processor is a higher-level mechanism for consuming the Azure Cosmos DB change feed.

It uses a push model.

Rather than requiring your application to repeatedly pull batches and manage continuation state itself, the processor:

  1. Reads changes from the monitored container.
  2. Determines which changes need to be processed.
  3. Delivers batches of changes to your application code.
  4. Maintains processing state using a lease container.
  5. Distributes work among multiple processor instances.
  6. Recovers work when an instance fails.

The change feed processor is currently provided through the Azure Cosmos DB .NET V3 and Java V4 SDKs. Python and Node.js applications can consume the change feed using the pull model rather than the change feed processor library.


4. The Four Components of a Change Feed Processor

A key AI-200 concept is understanding the four major components.

4.1 Monitored Container

The monitored container is the Azure Cosmos DB container whose changes you want to process.

For example:

Database: AIApplication
Container: Documents
Partition key: /customerId

The processor monitors Documents.

When items are created or updated, those changes become available through the change feed.


4.2 Lease Container

The lease container stores the state used by the change feed processor to coordinate processing.

This is extremely important.

The lease container allows multiple processor instances to share the workload without processing the same lease simultaneously.

Conceptually:

                 Lease Container
                /       |       \
               /        |        \
              v         v         v
          Lease 1    Lease 2    Lease 3
             |          |          |
             v          v          v
          Worker A   Worker B   Worker C

The leases represent ownership and progress for portions of the change feed.

The lease container can be in the same Cosmos DB account as the monitored container or in a separate account.

Exam tip

If a question asks:

What component maintains the state of change feed processing?

The answer is generally:

The lease container.


5. Compute Instances

A compute instance hosts the change feed processor.

Examples include:

  • Azure Kubernetes Service pods
  • Azure App Service instances
  • Azure Virtual Machines
  • Long-running application processes
  • Hosted background services

For example:

AKS Cluster
Pod 1 --> Change Feed Processor
Pod 2 --> Change Feed Processor
Pod 3 --> Change Feed Processor

Each processor instance must have a unique instance name.

The processor distributes leases among the available instances.


6. The Delegate

The delegate is your application code that processes the changes.

For example, suppose an AI application stores documents in Cosmos DB.

When a document changes, the delegate might:

  1. Extract the text.
  2. Generate an embedding.
  3. Store the embedding.
  4. Update a vector index.
  5. Record processing status.

Conceptually:

Cosmos DB Change
|
v
Change Feed Processor
|
v
Delegate
|
+--> Extract text
|
+--> Generate embedding
|
+--> Store embedding
|
+--> Update AI search data

The delegate is therefore where the application’s business logic lives.


7. How the Processing Lifecycle Works

The basic lifecycle is:

Read change feed
|
v
Are there changes?
/ \
No Yes
| |
v v
Wait Send batch
| |
+------<-------+
|
v
Delegate succeeds?
/ \
No Yes
| |
v v
Retry from Update
checkpoint lease

More precisely, the processor:

  1. Reads the change feed.
  2. Waits if no changes are available.
  3. Sends a batch of changes to the delegate.
  4. Waits for successful processing.
  5. Updates the lease with the latest successfully processed position.
  6. Continues processing.

The checkpoint is therefore advanced after successful processing.


8. Why the Change Feed Processor Uses At-Least-Once Processing

One of the most important concepts for the exam is that the change feed processor provides an at-least-once delivery guarantee.

Suppose the processor reads:

Change A
Change B
Change C

and passes them to your delegate.

If the delegate fails before the checkpoint is successfully updated, the processor can process those changes again.

Therefore:

Change A
Change B
Change C
|
v
Process
|
X Failure
|
v
Retry
|
v
Change A
Change B
Change C

This means your application should generally be idempotent.


9. Why Idempotency Matters

An idempotent operation can safely be executed more than once without producing an incorrect final result.

For example, suppose the change feed processor receives:

{
"id": "document-123",
"status": "completed"
}

Your processing logic might update a downstream record:

document-123 -> completed

If the same change is processed twice, the final state remains:

document-123 -> completed

That is preferable to an operation such as:

balance = balance + 100

where processing the same event twice could incorrectly add the amount twice.

Exam rule

Design change feed handlers assuming a change may be delivered more than once.


10. Lease-Based Load Distribution

The change feed processor can distribute processing across multiple instances.

For example:

Change Feed
------------------------------------------------
Partition Range 1
Partition Range 2
Partition Range 3
Partition Range 4
------------------------------------------------
| | | |
v v v v
Worker 1 Worker 2 Worker 3 Worker 4

The lease container coordinates ownership of these workloads.

If one worker fails, its leases can eventually be acquired by another worker.

This provides fault tolerance without requiring the developer to manually coordinate workers.


11. Scaling the Change Feed Processor

Suppose you initially have:

Worker 1

and later add:

Worker 2
Worker 3

The change feed processor can redistribute leases among the workers.

Conceptually:

Before:
Worker 1
├── Lease 1
├── Lease 2
├── Lease 3
└── Lease 4
After scaling:
Worker 1
├── Lease 1
└── Lease 2
Worker 2
└── Lease 3
Worker 3
└── Lease 4

This allows processing to be parallelized.

However, simply adding instances does not mean that processing becomes infinitely parallel.

The available workload is constrained by the number of leases/partition ranges.

The number of processor instances should not exceed the number of available leases for meaningful distribution.


12. Partitioning and Change Feed Processing

Azure Cosmos DB containers are partitioned using a partition key.

For example:

Container: Documents
Partition key: /customerId

The change feed processor works with the underlying partition ranges.

Each range can be processed independently, allowing parallel processing.

This is one reason that selecting an appropriate partition key remains important even when using the change feed.

A poor partition key can create an uneven workload.


13. Starting Position

An important implementation detail is the processor’s starting position.

When a change feed processor is initialized for the first time, its starting point determines which changes it processes.

In latest-version mode, you can configure the processor to start from a specified time or from the beginning of the container’s lifetime.

For example:

Container history
|
|---- Change A
|---- Change B
|---- Change C
|---- Change D
|---- Change E
|
^
|
Start processor

If configured to begin at Change A, the processor can process the historical changes.

If configured to start from the current point, older changes aren’t processed.

Important

The starting-position configuration is used when initializing the processor. Once the lease container has established the processor’s state, changing the starting configuration doesn’t reset the existing checkpoint.


14. Change Feed Processor vs. Pull Model

There are two major approaches to consuming the change feed.

FeatureChange Feed ProcessorPull Model
Processing stylePushPull
Checkpoint managementLease containerApplication-managed continuation
Load balancingBuilt inApplication responsibility
Error/retry infrastructureBuilt inApplication responsibility
.NET supportYesYes
Java supportYesYes
PythonNot through processor libraryYes
Node.jsNot through processor libraryYes

The change feed processor is generally easier when you want Azure Cosmos DB to manage the mechanics of distributing work and maintaining processing state.


15. Change Feed Processor vs. Azure Functions Trigger

Another important distinction is between the change feed processor and the Azure Functions trigger for Cosmos DB.

Both can be used to build event-driven applications.

For example:

Cosmos DB
|
+----> Change Feed Processor
|
+----> Azure Functions Trigger

The change feed processor is useful when you need more direct control over a long-running processing application.

The Azure Functions trigger is useful when you want a serverless implementation.

The Azure Functions trigger also uses a lease container to maintain processing state.


16. Handling Processing Failures

Suppose your delegate encounters an exception:

Batch
|
v
Delegate
|
X Exception

The processor doesn’t simply assume the batch succeeded.

Because the checkpoint hasn’t advanced successfully, the processor can retry the batch.

This behavior produces the at-least-once guarantee.

Important design consideration

If a particular item consistently causes processing to fail, the processor can repeatedly encounter the same problem.

A robust application should therefore have an error-handling strategy.

For example:

Change
|
v
Process
|
X Failure
|
+--> Retry
|
+--> Persistent failure
|
v
Error/DLQ storage

An application might persist information about the failed change to another Cosmos DB container or another durable store so that the processing pipeline doesn’t remain permanently blocked by one problematic change.


17. Monitoring Change Feed Lag

A change feed processor can fall behind the incoming changes.

For example:

New changes:
1000 events/sec
Processing:
700 events/sec
Result:
Change feed lag increases

The change feed estimator can be used to monitor processor progress and estimate lag.

This can help identify:

  • Insufficient processing capacity
  • Slow downstream services
  • Throttling
  • Application errors
  • Lease problems
  • Processing bottlenecks

18. Request Units and the Change Feed

Change feed processing isn’t free from a Cosmos DB throughput perspective.

Reading the change feed from the monitored container consumes request units (RUs).

Operations involving the lease container also consume RUs.

For example:

Monitored Container
|
+--> Change feed reads --> RU consumption
Lease Container
|
+--> Lease reads
+--> Lease updates
+--> Lease coordination
|
v
RU consumption

If the monitored or lease container experiences throttling, change processing can be delayed.

This is especially important when deploying multiple processor instances or multiple processing workloads that share a lease container.


19. Lease Container Permissions

When Microsoft Entra ID authentication is used, the processor’s identity needs appropriate permissions.

The monitored container requires permissions related to:

  • Reading account metadata
  • Reading the change feed

The lease container requires permissions for operations such as:

  • Reading items
  • Creating items
  • Replacing items
  • Deleting items
  • Executing queries

This is an important distinction:

The application doesn’t just need permission to read the monitored data; it also needs permission to maintain the processor’s lease state.


20. Using a Global Endpoint

For a change feed processor workload, Microsoft recommends using the global Cosmos DB endpoint rather than a region-specific endpoint.

For example:

Preferred:
https://contoso.documents.azure.com

rather than:

https://contoso-westus.documents.azure.com

Regional preferences should be configured through the appropriate SDK region settings.

This is important because lease documents are scoped to the configured endpoint. Changing endpoints can result in separate lease state.


21. A Typical AI Application Architecture

Consider an AI document-processing application.

A user uploads a document, and the application stores metadata in Cosmos DB.

The desired workflow is:

User
|
v
Application
|
v
Cosmos DB
|
| New/updated document
v
Change Feed
|
v
Change Feed Processor
|
v
Processing Delegate
|
+--> Extract document text
|
+--> Generate embedding
|
+--> Store vector
|
+--> Update search metadata
|
+--> Notify downstream application

This architecture avoids repeatedly scanning the entire container looking for new work.

It also allows the processing workload to scale independently from the application that writes the data.


22. Example .NET Concept

A simplified .NET implementation conceptually looks like this:

var processor = monitoredContainer
.GetChangeFeedProcessorBuilder<MyDocument>(
"documentProcessor",
HandleChangesAsync)
.WithInstanceName("worker-01")
.WithLeaseContainer(leaseContainer)
.Build();
await processor.StartAsync();

The important concepts are:

  • monitoredContainer — where changes originate.
  • leaseContainer — where processing state is maintained.
  • HandleChangesAsync — your business logic.
  • WithInstanceName — uniquely identifies the processor instance.
  • Processor startup — begins monitoring the change feed.

The exact SDK APIs can vary by SDK version, so the exam focus should be on understanding the architecture and responsibilities rather than memorizing every method signature. The current change feed processor documentation identifies .NET V3 and Java V4 as the SDKs that provide the processor library.


23. Important Exam Concepts to Remember

For AI-200, make sure you can distinguish the following:

Monitored container

Contains the data whose changes are being detected.

Lease container

Maintains processor state and coordinates work across instances.

Delegate

Contains the application’s processing logic.

Compute instance

Hosts the change feed processor.

Latest-version mode

Captures the latest versions of creates and updates; deletes aren’t included.

All versions and deletes mode

Captures creates, updates, and deletes, including intermediate changes.

Checkpoint

Records the latest successfully processed position.

At-least-once delivery

A change can be processed more than once, so handlers should be idempotent.

Pull model

The application manages reading, continuation state, and processing coordination.

Change feed processor

Provides a higher-level push-based processing model with lease-based coordination.


Practice Exam Questions

Question 1

An AI application stores documents in an Azure Cosmos DB for NoSQL container. Whenever a document is created or updated, the application must perform additional processing. The development team wants Azure Cosmos DB to manage checkpointing and distribute processing across multiple application instances.

Which solution should the team implement?

A. A timer-triggered Azure Function that scans the container

B. Periodic SQL queries

C. Azure Cosmos DB analytical store queries

D. Change feed processor

Answer: D

Explanation

The change feed processor is designed to process changes incrementally and provides built-in lease-based coordination and checkpoint management. It can distribute change feed processing across multiple instances.

The other approaches require the application to identify changes itself and are less appropriate for event-driven incremental processing.


Question 2

A change feed processor processes a batch of changes successfully but fails before the processing state is checkpointed. What should the application expect?

A. The changes are permanently discarded

B. The batch can be delivered again

C. The entire Cosmos DB container is automatically restored

D. The change feed is permanently disabled

Answer: B

Explanation

The change feed processor provides at-least-once delivery. If processing succeeds but the checkpoint isn’t successfully advanced, the processor can process the same changes again.

Application processing logic should therefore be designed to be idempotent.


Question 3

Which component is primarily responsible for maintaining the state and coordinating ownership of change feed processing across multiple processor instances?

A. Monitored container

B. Compute instance

C. Lease container

D. Application Gateway

Answer: C

Explanation

The lease container stores the state used by the change feed processor to coordinate processing across instances.

The monitored container provides the source data, while compute instances host the processing application.


Question 4

An application uses the default latest-version change feed mode. An item is created and then updated three times before the processor reads the changes. What behavior should the application expect?

A. Only the delete operation is returned

B. All four versions are guaranteed to be returned

C. No changes are returned because the item changed multiple times

D. The latest version of the item is available rather than every intermediate version

Answer: D

Explanation

Latest-version mode provides the latest version of an item in the feed rather than preserving every intermediate change between reads.

If the application needs every create, update, and delete operation, it should consider all versions and deletes mode instead.


Question 5

A developer is building a change feed processor application that will run on three AKS pods. What is the primary purpose of assigning each processor instance a unique instance name?

A. To identify each compute instance participating in lease distribution

B. To specify the Cosmos DB partition key

C. To determine the consistency level

D. To select the Cosmos DB database

Answer: A

Explanation

Each change feed processor instance should have a unique instance name. The processor uses the instances and leases to distribute processing work across the deployment.

The instance name is unrelated to partition-key selection, database selection, or consistency configuration.


Question 6

An AI application must react when documents are deleted from an Azure Cosmos DB for NoSQL container. Which change feed capability is most appropriate?

A. Latest-version change feed mode

B. All versions and deletes change feed mode

C. Increasing the consistency level

D. Increasing the container’s RU/s

Answer: B

Explanation

All versions and deletes mode captures creates, updates, and deletes.

Latest-version mode does not capture deletes.

All versions and deletes mode has additional requirements, including continuous backup, and is specifically available for Azure Cosmos DB for NoSQL.


Question 7

A change feed processor application experiences increasingly large processing delays. Investigation shows that the application is processing changes correctly but cannot keep up with incoming changes.

Which metric or capability is most useful for determining whether the processor is falling behind?

A. Azure DNS query count

B. Azure Storage blob count

C. Change feed estimator

D. Azure Resource Manager activity log

Answer: C

Explanation

The change feed estimator can be used to estimate the lag between the changes available in the monitored container and the progress of the change feed processor.

This can help identify processing bottlenecks and determine whether additional processing capacity may be necessary.


Question 8

A change feed processor’s delegate updates an external database. The same change may occasionally be delivered more than once. What should the developer do?

A. Disable checkpointing

B. Use an idempotent processing design

C. Increase the Cosmos DB consistency level to strong

D. Disable leases

Answer: B

Explanation

The change feed processor provides at-least-once delivery, meaning a change can be processed more than once.

The delegate should therefore be designed to handle duplicate processing safely. Idempotent operations are one of the most important techniques for doing this.


Question 9

A company runs several change feed processor instances and notices that the lease container is experiencing RU throttling. What is a likely consequence?

A. Change feed processing can be delayed

B. All documents in the monitored container are deleted

C. The Cosmos DB account automatically switches to strong consistency

D. The application automatically receives unlimited RU/s

Answer: A

Explanation

The lease container performs operations that consume request units. If the lease container is throttled, lease coordination and renewal can be delayed, which can delay change feed processing.

The monitored container’s change feed reads also consume RUs. Both the monitored and lease containers should therefore be appropriately provisioned.


Question 10

A development team wants to consume an Azure Cosmos DB change feed from a Python application. They want to use the built-in change feed processor library that automatically handles lease-based processing.

What should the team do?

A. Use the .NET change feed processor library from Python

B. Use the Java change feed processor library from Python

C. Use the change feed pull model from Python

D. Use Azure SQL Database instead

Answer: C

Explanation

The Azure Cosmos DB change feed processor library is available for .NET and Java. Python applications can consume the change feed using the pull model, where the application manages continuation state and processing.


Key Takeaways

For the AI-200 exam, the most important ideas are:

  1. The change feed records changes to Azure Cosmos DB items.
  2. The change feed processor provides a push-based processing model.
  3. The monitored container is the source of changes.
  4. The lease container stores processing state and coordinates workers.
  5. The delegate contains the application’s change-processing logic.
  6. Multiple processor instances can share the workload through leases.
  7. Change feed processing provides at-least-once delivery.
  8. Handlers should therefore be idempotent.
  9. Latest-version mode captures creates and updates but not deletes.
  10. All versions and deletes mode captures creates, updates, and deletes.
  11. The change feed processor library is available for .NET and Java; Python and Node.js use the pull model.
  12. Change feed processing consumes RUs.
  13. Throttling of the monitored or lease container can delay processing.
  14. The change feed estimator can help identify processing lag.
  15. The lease container is fundamental to distributed, fault-tolerant change feed processing.

The exam’s scenario questions are likely to test whether you can select the right change feed mode, processing model, lease architecture, error-handling strategy, and scaling approach, rather than simply recognizing the term “change feed.”


Go to the AI-200 Exam Prep Hub main page

The Fundamentals of Star Schemas

Introduction

If there is one data modeling concept that every data analyst, data engineer, and Power BI developer should understand, it is the star schema.

Although modern analytics platforms provide powerful capabilities for importing, transforming, and analyzing data, the quality of your reports ultimately depends on the quality of your data model. A well-designed star schema makes reports easier to build, improves query performance, reduces complexity, and helps ensure accurate calculations.

Whether you’re creating a Power BI semantic model, designing a Microsoft Fabric Warehouse, building an Azure SQL data warehouse, or developing a traditional enterprise data warehouse, the star schema remains the industry standard for organizing analytical data.


What Is a Star Schema?

A star schema is a data modeling technique that organizes data into two primary types of tables:

  • Fact tables
  • Dimension tables

The fact table sits in the center of the model, while the dimension tables surround it, creating a shape that resembles a star.

             Product
                |
Customer --- Sales Fact --- Date
                |
            Salesperson
                |
             Geography

This simple design makes it easy for reporting tools to aggregate data while allowing users to filter information by various business attributes. Star Schema models are sometimes called Dimensional Models.


Fact Tables

A fact table stores measurable business events.

Each row typically represents a single business transaction or event.

Examples include:

  • Sales transactions
  • Orders
  • Shipments
  • Inventory movements
  • Website visits
  • Financial journal entries

Fact tables usually contain:

  • Numeric values (sales amount, quantity, cost)
  • Foreign keys pointing to dimensions
  • Sometimes transaction identifiers

Example:

DateKeyProductKeyCustomerKeyQuantitySalesAmount
202607011258453$149.97
202607014502101$89.99

Notice that the fact table stores very little descriptive information. Instead, it references other tables.


Dimension Tables

Dimension tables describe the facts.

Rather than storing numbers, they store descriptive attributes used for filtering, grouping, and reporting.

Examples include:

  • Customer
  • Product
  • Date
  • Employee
  • Store
  • Vendor
  • Geography

A Product dimension might contain:

ProductKeyProductNameCategoryBrandColor
125Wireless MouseAccessoriesContosoBlack

A Customer dimension may include:

  • Customer Name
  • City
  • State
  • Country
  • Customer Segment
  • Industry

These tables provide the business context needed to interpret the facts.


Why Is It Called a Star Schema?

When diagrammed visually, the fact table appears in the middle while dimension tables radiate outward.

           Product

Customer  Sales  Date

         Geography

        Salesperson

Unlike more complicated database designs, each dimension typically connects directly to the fact table.

This simplicity is one of the reasons star schemas are so effective.


Relationships

In a star schema:

  • One dimension row relates to many fact rows.
  • Fact tables contain foreign keys.
  • Dimension tables contain primary keys.

For example:

Product
---------
ProductKey (Primary Key)
|
|
Sales Fact
----------
ProductKey (Foreign Key)

This creates a one-to-many relationship, which is ideal for analytical workloads.


What Is Granularity?

Granularity refers to the level of detail stored in the fact table.

Examples:

Daily Sales: One row per day.

Transaction Sales: One row per individual purchase.

Order Line Sales: One row for every item sold on an order.

The more detailed the granularity, the more flexible the reporting becomes.

Choosing the correct grain is one of the most important design decisions in a star schema.


Common Dimension Tables

Nearly every warehouse includes some common dimensions.

Date Dimension

Perhaps the most important dimension.

Contains attributes like:

  • Date
  • Year
  • Quarter
  • Month
  • Month Name
  • Week
  • Fiscal Year
  • Holiday Indicator

Instead of calculating these repeatedly, reports simply reference the Date dimension.


Product Dimension

Contains:

  • Product Name
  • Category
  • Subcategory
  • Brand
  • Color
  • Size
  • SKU

Customer Dimension

Contains:

  • Customer Name
  • Region
  • Industry
  • Segment
  • Customer Type

Geography Dimension

Contains:

  • Country
  • State
  • Province
  • City
  • Postal Code
  • Sales Territory

Measures vs Attributes

Understanding the difference between measures (stored in Fact tables) and attributes (stored in Dimension tables) is essential.

Measures (Fact Table)

  • Sales Amount
  • Cost
  • Quantity
  • Profit
  • Hours Worked

Attributes (Dimension Tables)

  • Product Name
  • Customer Name
  • State
  • Department
  • Month
  • Category

A simple way to think about it:

Numbers that are aggregated belong in fact tables. Descriptive information belongs in dimension tables.


Benefits of Star Schemas

1. Better Performance

Reporting engines such as Power BI are optimized for star schemas.

Fewer joins result in:

  • Faster queries
  • Better compression
  • Reduced memory usage

2. Simpler Reports

Users can easily understand:

  • Sales by Month
  • Sales by Customer
  • Sales by Product
  • Sales by Region

Instead of navigating dozens of interconnected tables, report authors work with a clean, intuitive model.


3. Easier Maintenance

Changes to one dimension rarely affect other dimensions.

Adding a new Product Category only requires updating the Product dimension.

The fact table usually remains unchanged.


4. Improved Data Quality

Because descriptive information is stored once, duplication is minimized.

For example, “Florida” exists once in a Geography dimension instead of appearing in millions of sales rows.


5. Scalability

Star schemas scale exceptionally well.

Many enterprise warehouses contain:

  • Billions of fact rows
  • Millions of customers
  • Hundreds of thousands of products

The design continues to perform efficiently.


Star Schema vs Flat Tables

Some beginners attempt to place every column into one enormous table.

While this may seem easier initially, it creates several problems:

  • Duplicate data
  • Larger storage requirements
  • Slower refreshes
  • Poor compression
  • Difficult maintenance

A star schema separates repeated descriptive information from transactional data, making the model both smaller and faster.


Star Schema vs Snowflake Schema

A related design is the snowflake schema.

Instead of storing all descriptive information in a single dimension, dimensions are normalized into multiple tables.

Example:

Product
|
Category
|
Department

Advantages:

  • Less duplicated data
  • Smaller dimension tables

Disadvantages:

  • More joins
  • More complicated reports
  • Slower query performance
  • Harder for business users to understand

For Power BI and most analytics solutions, a star schema is generally preferred.


Best Practices

When designing a star schema:

  • Determine the grain of each fact table before loading data.
  • Use surrogate keys for dimension relationships when appropriate.
  • Keep dimensions descriptive and facts numeric.
  • Avoid storing repeated descriptive data in fact tables.
  • Use conformed dimensions (such as Date or Customer) across multiple fact tables.
  • Create one-to-many relationships from dimensions to facts.
  • Keep the model as simple as possible.
  • Hide technical key columns from report consumers.
  • Use meaningful table and column names.
  • Document the purpose of each fact and dimension.

Common Mistakes to Avoid

New developers often make these mistakes:

  • Building one giant table containing everything.
  • Creating many-to-many relationships unnecessarily.
  • Using bidirectional filtering without a clear need.
  • Mixing transaction-level and summary-level data in the same fact table.
  • Including calculated totals in fact tables instead of calculating them in reports.
  • Storing descriptive text in fact tables.
  • Ignoring the importance of a proper Date dimension.

Avoiding these pitfalls leads to cleaner, more maintainable models.


Star Schemas in Power BI

Power BI is designed to work exceptionally well with star schemas.

Benefits include:

  • Faster report performance
  • Better DAX calculation behavior
  • Simpler filter propagation
  • Easier report development
  • Improved semantic model organization

Microsoft recommends using star schemas whenever possible when designing Power BI semantic models.


Real-World Example

Imagine a retail company tracking sales.

Sales Fact

  • Sales Amount
  • Quantity
  • Discount
  • Cost

Connected to:

  • Date
  • Customer (contains Customer Segment)
  • Product
  • Store (contains Region)
  • Employee
  • Promotion

Business users can easily answer questions such as:

  • Which products sold the most this month?
  • Which region generated the highest profit?
  • What is the average order value by customer segment?
  • Which promotions increased sales?
  • How did sales compare year over year?

This flexibility is one of the major reasons star schemas have become the standard for business intelligence.


Frequently Asked Questions

Can a star schema have multiple fact tables?

Yes. Many enterprise data warehouses include multiple fact tables, such as Sales, Inventory, Budget, and Returns, all sharing common dimensions like Date, Product, and Customer.

Why shouldn’t descriptive columns be stored in fact tables?

Doing so increases duplication, wastes storage, and makes updates more difficult. Dimension tables provide a single source of truth for descriptive information.

Are star schemas only used in Power BI?

No. Star schemas are widely used in Microsoft Fabric, Azure Synapse Analytics, SQL Server, Oracle, Snowflake, Amazon Redshift, Google BigQuery, and many other analytics platforms.

Is a star schema required?

Not always, but it is considered the best practice for most analytical reporting and business intelligence solutions because it balances simplicity, performance, and scalability.


Conclusion

The star schema is one of the most important concepts in modern analytics and data warehousing. By separating measurable business events into fact tables and descriptive business information into dimension tables, it creates a model that is easy to understand, efficient to query, and scalable for organizations of any size.

Whether you’re building dashboards in Power BI, designing a Microsoft Fabric Warehouse, or developing an enterprise data warehouse, mastering star schema fundamentals will help you create faster reports, more reliable analytics, and data models that are easier to maintain over time. A solid star schema is not just a design choice—it is the foundation of effective business intelligence.

Thanks for reading!

“Clear all slicers” in Power BI

The “Clear all slicers” feature/button in Power BI allows report users to quickly reset every slicer on the current report page back to its default state. Rather than clearing each slicer individually, users can restore the page’s original filter selections with a single click.

This feature is particularly valuable for interactive reports that contain many slicers, helping users start a new analysis without manually removing multiple filters one-by-one.


Why Use the “Clear all slicers” Button?

As reports become more interactive, it’s common to have numerous slicers controlling different aspects of the data. After applying several filters, users may want to return to the report’s default view.

The Clear all slicers button provides several benefits:

  • Saves time by resetting all slicers simultaneously.
  • Improves the user experience on reports with many filters.
  • Allows users to quickly begin a new analysis.
  • Reduces confusion caused by forgotten slicer selections.
  • Creates a more intuitive and professional report interface.

For example, a sales dashboard might include slicers for:

  • Year
  • Quarter
  • Region
  • Salesperson
  • Product Category
  • Customer Segment

Instead of clearing six slicers individually, users simply click Clear all slicers to restore the default selections.


When Should You Use It?

The Clear all slicers feature is most useful when:

  • A report contains several slicers.
  • Users frequently change filter combinations.
  • Reports are used for exploratory data analysis.
  • Business users need an easy way to reset the report.
  • You want to provide a cleaner and more user-friendly experience.

For simple reports with only one or two slicers, the feature may not provide much additional value.


How the Feature Works

When a user selects Clear all slicers, Power BI resets every slicer on the current page to its default state. Depending on how the report was designed, this may mean:

  • Returning to “All” values.
  • Returning to predefined default selections.
  • Removing user-applied filter selections.

Only slicers on the current report page are affected.


How to Implement the “Clear all slicers” Button

Implementation is straightforward.

Step 1: Configure the Default Slicer Selections

Before adding the button:

  1. Place all required slicers on the report page.
  2. Configure each slicer to the desired default value.
  3. Save the report with these default selections.

These become the state that users return to when clearing slicers.

Step 2: Insert the Button

  1. Select Insert from the ribbon.
  2. Choose Buttons.
  3. Select Clear all slicers.

Power BI automatically inserts a button configured for this purpose.

Step 3: Position and Format the Button

Customize the button by:

  • Changing the text
  • Adding an icon
  • Applying theme colors
  • Adjusting borders and shadows
  • Positioning it near the slicers for easy access

Many report designers place it above or beside the slicer panel so users can easily find it.

Step 4: Test the Report

After publishing or previewing the report:

  1. Change several slicer selections.
  2. Click Clear all slicers.
  3. Verify that every slicer returns to its default state.

Best Practices

To maximize usability:

  • Place the button close to the slicers.
  • Label it clearly (for example, Clear Filters or Reset Filters).
  • Use consistent styling throughout the report.
  • Establish meaningful default slicer values before publishing.
  • Test the feature after adding or modifying slicers.

Common Mistakes to Avoid

Some common implementation issues include:

  • Forgetting to set the desired default slicer selections before publishing.
  • Hiding the button where users cannot easily find it.
  • Assuming the button affects slicers on other report pages.
  • Expecting it to reset filters that are not implemented as slicers (such as page-level, report-level, or visual-level filters).

Best Used Alongside the Apply All Slicers Feature

The Clear all slicers button works especially well when paired with the Apply all slicers feature. Together they provide users with complete control over filtering:

  • Apply all slicers lets users make multiple filter changes before refreshing the report.
  • Clear all slicers lets users instantly return to the default filter state.

This combination creates a smoother, more efficient experience for reports with numerous filters, especially when working with large datasets or DirectQuery models where reducing unnecessary visual refreshes can improve performance.


Summary

The Clear all slicers feature is a simple but valuable enhancement for Power BI reports. By allowing users to reset all slicers with a single click, it improves usability, encourages exploration, and helps users quickly return to a known starting point. When combined with thoughtful default slicer settings and the Apply all slicers feature, it contributes to a cleaner, faster, and more user-friendly reporting experience.

Thanks for reading!

Using the “Apply all slicers” button in Power BI

If you are wondering …

How can I delay the refresh of the reports on a dashboard page until after I have made all my slicer changes?
-or-
How can I apply all my slicer changes at once instead of each change being applied automatically and refreshing the visualizations on the dashboard page?

… then this post is for you.


Understanding default slicer behavior

One of the most useful interactive features in Power BI is the ability for slicers to filter report visuals. By default, whenever a user changes the value of a slicer, every visual affected by that slicer immediately refreshes. This behavior provides instant feedback and works well for reports with small datasets.

However, immediate refresh isn’t always the best experience. Reports that contain large datasets, complex DAX calculations, DirectQuery connections, or numerous visuals may require several seconds to refresh. If users need to change multiple slicers, the report may refresh after every individual selection, resulting in unnecessary queries and a slower user experience.

To address this issue, Power BI provides the “Apply all slicers” feature/button.


What does the “Apply all slicers” feature/button do?

The “Apply all slicers” feature allows for users to modify multiple slicers without triggering repeated refreshes. Once all desired selections have been made, users simply click the “Apply all slicers” button to refresh the report a single time. This approach can improve responsiveness, reduce query volume, and provide a smoother experience for reports, especially those built on large datasets or DirectQuery connections.


When should I use the “Apply all slicers” feature/button?

In general, use this feature when you do not want your reports/visualizations to refresh automatically after each slicer selection, but you instead want to apply all your selections at once refreshing the reports/visualizations just once. This feature is especially useful when:

  • Reports use DirectQuery.
  • Models contain millions of rows.
  • Complex DAX calculations require significant processing.
  • Numerous visuals exist on a single report page.
  • Multiple slicers are commonly changed together.
  • Minimizing database queries is important.

Why would I want to change the default slicer behavior?

Immediate refresh is convenient, but it can:

  • Execute multiple unnecessary queries.
  • Increase report loading time.
  • Generate additional load on the data source.
  • Create a poor user experience when users need to modify several slicers before analyzing the results.

Using “Apply all slicers” allows users to make all of their filter selections first and then refresh the report only once. Instead of refreshing visuals after every slicer change, Power BI waits until the user finishes selecting filter values. This often results in fewer queries sent to the data source, reduced processing, faster overall user experience, and lower resource consumption.


How to enable the “Apply all slicers” button

Implementing this feature only takes a few steps.

Step 1: Open the Report in Power BI Desktop

Open the report that contains the slicers you want to optimize.

Step 2: Enable the Button

From the ribbon:

InsertButtonsApply all slicers

Power BI inserts a button onto the report page.

Step 3: Position the Button

Move the button to an intuitive location, such as:

  • Above the slicers
  • Beside the filter panel
  • At the top of the report page

Many developers also format the button with a distinctive color and descriptive text such as Apply Filters or Apply Selections or Update Report.

Step 5: Test the Report

After publishing or previewing the report:

  1. Change one slicer.
  2. Change another slicer.
  3. Notice that visuals do not refresh.
  4. Select / Click “Apply all slicers“.
  5. All visuals refresh simultaneously using the combined filter selections.

Best Practices

Consider the following recommendations when using this “Apply all slicers” feature:

  • Use it for reports with many slicers or expensive queries.
  • Clearly label the button so users understand that filters are not applied automatically.
  • Place the button near the slicers for better usability.
  • Test both Import and DirectQuery models to determine whether the feature provides measurable performance improvements.
  • Educate report consumers about the changed behavior, particularly if they are accustomed to automatic updates.

Summary

By default, Power BI refreshes report visuals every time a slicer selection changes. While this provides immediate feedback, it can also result in unnecessary processing and slower performance for large or complex reports.

The “Apply all slicers” feature allows users to modify multiple slicers without triggering repeated refreshes. Once all desired selections have been made, users simply select the “Apply all slicers” button to refresh the report a single time. This approach can improve responsiveness, reduce query volume, and provide a smoother experience for reports built on large datasets or DirectQuery connections.

When designing enterprise-scale Power BI solutions, understanding when to use “Apply all slicers” is another valuable technique for balancing interactivity with performance.

If interested, you may already read a post about the “Clear all slicers” feature here.

Thanks for reading!

Understanding the Power BI Semantic Model

Introduction

One of the most important concepts in Microsoft Power BI is the Semantic Model. While reports and dashboards are what users see, the semantic model is the intelligence that sits behind them. It organizes data, defines business logic, and ensures that reports produce consistent, accurate results.

A well-designed semantic model makes report development faster, simplifies maintenance, improves performance, and creates a single version of the truth for an organization.


What Is a Power BI Semantic Model?

A Power BI Semantic Model is a structured collection of data, relationships, calculations, and business rules that provides a business-friendly view of your data.

Think of it as the translation layer between your organization’s raw data and the reports your users consume.

Instead of report developers needing to understand dozens of database tables and SQL queries, they simply connect to a semantic model that already contains:

  • Imported or connected data
  • Relationships between tables
  • Measures
  • Calculated columns
  • Hierarchies
  • Data formatting
  • Security rules
  • Business definitions

The semantic model allows users to analyze data without needing to understand where the data originally came from.


Why Is the Semantic Model Important?

The semantic model serves as the foundation for nearly every Power BI report.

Some of its biggest benefits include:

  • Creates a single source of truth
  • Eliminates duplicated business logic
  • Improves report consistency
  • Simplifies report development
  • Improves report performance
  • Makes security easier to manage
  • Enables report reuse across teams

Without a semantic model, every report developer would need to create their own calculations for example, resulting in inconsistent numbers across reports.


What Makes Up a Semantic Model?

A semantic model typically contains several key components.

Tables

The business data that users analyze.

Examples include:

  • Sales
  • Customers
  • Products
  • Employees
  • Dates

Relationships

Relationships connect tables together so Power BI understands how information relates.

For example:

Sales → Customer

Sales → Product

Sales → Date

Proper relationships eliminate the need for complicated report calculations.


Measures

Measures perform calculations at query time.

Examples:

  • Total Sales
  • Average Order Value
  • Profit Margin
  • Year-to-Date Sales

Measures are generally preferred over calculated columns for aggregations because they are more flexible and consume less storage.


Calculated Columns

Calculated columns create new values that become part of the data model.

Examples include:

  • Full Name
  • Profit Category
  • Fiscal Quarter

Hierarchies

Hierarchies make navigation easier.

Example:

Year → Quarter → Month → Day


Data Formatting

Semantic models define:

  • Currency formats
  • Percentages
  • Decimal places
  • Date formats

This ensures reports display information consistently.


Row-Level Security (RLS)

Security rules determine which data each user is allowed to see.

For example:

  • Regional managers only see their own region.
  • Sales representatives only see their own customers.

How Is a Semantic Model Created?

The typical process looks like this:

  1. Connect to one or more data sources.
  2. Clean and transform data using Power Query.
  3. Load the data into Power BI.
  4. Create relationships.
  5. Create measures using DAX.
  6. Configure formatting.
  7. Build hierarchies.
  8. Configure security.
  9. Publish the semantic model to the Power BI Service.

Once published, reports can connect directly to the semantic model rather than importing data again.


How Is a Semantic Model Maintained?

Like any business asset, semantic models require ongoing maintenance.

Common maintenance activities include:

  • Refreshing data
  • Adding new tables
  • Creating or updating relationships
  • Updating business calculations
  • Optimizing model performance
  • Reviewing and updating security
  • Creating new columns or removing unused columns
  • Documenting business definitions
  • Monitoring refresh failures
  • and more

A well-maintained semantic model becomes increasingly valuable over time.


Shared Semantic Models

One of the greatest strengths of Power BI is the ability to share a semantic model across many reports.

Instead of creating ten separate datasets containing the same sales data:

  • Build one high-quality semantic model.
  • Allow many reports to connect to it.

Benefits include:

  • Consistent calculations
  • Less duplicated work
  • Smaller storage footprint
  • Easier maintenance
  • Better governance
  • Faster report development

This approach is sometimes called the “build once, report many” strategy.


Best Practices

When designing semantic models, consider the following recommendations.

Use a Star Schema

Organize data into:

  • Fact tables
  • Dimension tables

This improves both performance and usability.


Hide Technical Columns

Hide columns that report authors should not use.

Examples:

  • Primary keys
  • Foreign keys
  • Internal IDs

This creates a cleaner report authoring experience.


Create Measures Instead of Repeating Calculations

Store business calculations centrally.

Instead of recreating “Total Sales” in every report, define it once inside the semantic model.


Use Meaningful Names

Instead of:

SalesAmt

Use:

Total Sales

Business-friendly names improve usability.


Remove Unnecessary Data

Only import:

  • Needed tables
  • Needed columns
  • Needed rows

Smaller models perform better.


Document Business Logic

Describe:

  • Measures
  • KPIs
  • Calculations
  • Business rules

Future developers will appreciate the documentation.


Optimize Relationships

Avoid unnecessary many-to-many relationships when possible.

Keep relationships simple and easy to understand.


Securing a Semantic Model

Security should be considered from the beginning rather than added later.

Important security practices include:

  • Use Row-Level Security (RLS) when different users should see different data.
  • Apply workspace permissions using the principle of least privilege.
  • Secure the underlying data source.
  • Protect sensitive information using sensitivity labels when appropriate.
  • Limit who can modify the semantic model.
  • Review permissions regularly.

Good security protects both the data and the business.


Common Mistakes to Avoid

Many new Power BI developers make similar mistakes.

Building a Separate Model for Every Report

Instead, reuse a shared semantic model whenever possible.


Importing Every Column

Extra columns increase model size and reduce performance.


Creating Duplicate Measures

One calculation should exist only once.


Poor Naming

Names like:

Measure1

Calc2

Table3

make models difficult to maintain.


Ignoring Relationships

Incorrect relationships often produce incorrect totals.

Always validate relationship directions and cardinality.


Excessive Calculated Columns

Use measures whenever practical for aggregations.


Skipping Documentation

Undocumented models become difficult to maintain as teams grow.


How to Make Your Semantic Model More Valuable

Organizations receive the greatest value when they treat the semantic model as a shared enterprise asset.

Some ways to maximize its value include:

  • Develop reusable measures.
  • Standardize business definitions.
  • Encourage report developers to connect to existing semantic models.
  • Validate and certify trusted semantic models for organization-wide use.
  • Monitor usage to identify opportunities for improvement.
  • Regularly review performance and security.
  • Keep the model simple, clean, and well documented.

As adoption grows, the semantic model becomes the central foundation for business reporting.


Frequently Asked Questions

Can multiple reports use the same semantic model?

Yes. In fact, this is one of the primary design goals of Power BI. A single semantic model can support dozens—or even hundreds—of reports while ensuring consistent calculations and business definitions.


What is the difference between a semantic model and a report?

The semantic model contains the data, relationships, measures, and business logic. A report is the visual presentation that connects to and displays information from the semantic model.


Can a semantic model connect to multiple data sources?

Yes. A semantic model can combine information from databases, spreadsheets, cloud services, data warehouses, data lakes, and many other supported data sources.


Who should create semantic models?

Ideally, semantic models are created and maintained by BI developers, data engineers, analytics engineers, or Power BI developers who understand both the organization’s data and its business rules.


When should a new semantic model be created?

A new semantic model should generally be created only when the data serves a different business domain or has substantially different security, refresh, or performance requirements. Otherwise, extending an existing shared semantic model is often the better choice.


Can security be applied inside the semantic model?

Yes. Row-Level Security (RLS) can restrict which rows users see, and Object-Level Security (OLS) can hide specific tables or columns from certain users when supported. These features help enforce data access policies consistently across all reports that use the model.


Summary

The Power BI semantic model is the foundation of effective business intelligence. It transforms raw data into a reusable, business-friendly resource by defining relationships, calculations, security, and business logic in one central location.

Organizations that invest in well-designed, shared semantic models benefit from more consistent reporting, faster report development, improved performance, stronger governance, and easier maintenance. By following best practices—such as using a star schema, creating reusable measures, documenting business logic, securing data appropriately, and encouraging report reuse—you can build semantic models that deliver lasting value across the organization.

Thanks for reading!

Choose from full-text, semantic vector, and hybrid search (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:
Implement AI capabilities in database solutions (25–30%)
   --> Design and implement intelligent search
      --> Choose from full-text, semantic vector, and hybrid search


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

One of the most important skills measured on the DP-800 exam is knowing which search technology is appropriate for different AI-enabled database scenarios. Modern applications no longer rely solely on keyword matching. Instead, they increasingly combine traditional SQL capabilities with semantic understanding powered by embeddings and vector databases.

Microsoft SQL Server 2025, Azure SQL Database, Azure SQL Managed Instance, Azure AI Search, and Microsoft Fabric all support architectures that combine relational data with AI-powered retrieval.

The DP-800 exam expects candidates to understand:

  • Traditional Full-Text Search
  • Semantic Vector Search
  • Hybrid Search
  • When each technique should be selected
  • Advantages and disadvantages of each approach
  • How embeddings enable semantic retrieval
  • How intelligent search supports Retrieval-Augmented Generation (RAG)

Understanding the strengths and weaknesses of each search strategy is critical because choosing the wrong approach can significantly reduce application quality, increase cost, or degrade performance.


Why Intelligent Search Matters

Traditional databases are excellent at retrieving structured information.

For example:

Find all customers named Smith.

or

Find invoices created after January 1.

However, AI applications often ask questions like:

  • Which support ticket is similar to this one?
  • Find documents about password recovery.
  • Find articles discussing authentication failures.
  • Recommend products similar to this description.

These questions require understanding meaning, not merely matching characters.

This is why semantic search has become an essential component of modern database applications.


Three Primary Search Approaches

Microsoft generally categorizes intelligent search into three approaches:

  1. Full-Text Search
  2. Semantic Vector Search
  3. Hybrid Search

Each solves a different problem.


Full-Text Search

Full-text search is Microsoft’s traditional text search technology.

Instead of scanning every row with LIKE comparisons, SQL Server builds specialized indexes that understand words and language.

Example:

Find all documents containing:
database
security
Azure

Rather than performing:

WHERE Description LIKE '%Azure%'

Full-text indexes tokenize words and search efficiently.


Full-Text Search Features

Supports:

  • Word searches
  • Phrase searches
  • Prefix searches
  • Inflectional forms
  • Language-specific stemming
  • Stop words
  • Ranking

Example:

Searching for

run

may also find

  • running
  • runs
  • ran

depending on language settings.


Full-Text Index Architecture

A full-text index stores:

  • Tokens
  • Word locations
  • Linguistic metadata

instead of raw text.

This allows much faster retrieval than LIKE queries.


Common Full-Text Functions

Examples include:

CONTAINS()
FREETEXT()
CONTAINSTABLE()
FREETEXTTABLE()

Example:

SELECT *
FROM Articles
WHERE CONTAINS(Content,'Azure');

Advantages of Full-Text Search

Advantages include:

  • Mature technology
  • Extremely fast keyword searches
  • Built directly into SQL Server
  • Efficient indexing
  • Supports ranking
  • Low storage overhead
  • Easy implementation

Limitations of Full-Text Search

It still relies primarily on matching words.

It does not understand meaning.

For example:

Search:

vehicle repair

A document containing

automobile maintenance

might not be returned.

Although synonyms can sometimes help, semantic understanding remains limited.


When Full-Text Search Is Best

Choose Full-Text Search when:

  • Exact words matter
  • Legal document searches
  • Product catalogs
  • Article searches
  • Documentation portals
  • Knowledge bases
  • Compliance systems

It excels when users know the terminology they are searching for.


Semantic Vector Search

Vector search is fundamentally different.

Instead of searching words, it searches meaning.

The process is:

Text

Embedding model

Vector

Similarity search

Every document becomes a numerical representation.

Example:

"Reset your password"

becomes

[0.183,
-0.912,
0.447,
...]

The numbers themselves are not important.

Their relative position in vector space is.


Embeddings Power Semantic Search

Embedding models place similar concepts near each other.

For example:

Dog

and

Puppy

produce vectors close together.

Likewise:

Laptop

and

Notebook computer

may generate highly similar vectors.

The model learns semantic relationships.


Similarity Search

Rather than asking:

“Does this document contain this word?”

Vector search asks:

“Which vectors are closest?”

Similarity is commonly measured using:

  • Cosine similarity
  • Euclidean distance
  • Dot product

Cosine similarity is the most common metric.


Example

User asks:

“How do I recover my account?”

Stored article:

“Reset your password”

Even though no identical words exist, vector search recognizes the concepts are related.

This is impossible using ordinary keyword matching.


Advantages of Semantic Vector Search

Benefits include:

  • Understands meaning
  • Finds similar content
  • Supports natural language
  • Excellent for AI assistants
  • Ideal for RAG
  • Handles synonyms automatically
  • Better user experience

Limitations of Vector Search

Tradeoffs include:

  • Requires embedding models
  • Consumes more storage
  • Embedding generation costs compute
  • Requires vector indexes
  • More complex infrastructure
  • Results can occasionally be less predictable than exact keyword searches

Typical Use Cases

Vector search is ideal for:

  • AI chatbots
  • Enterprise search
  • Recommendation engines
  • Similar document retrieval
  • Customer support assistants
  • Semantic knowledge bases
  • Question answering systems
  • RAG architectures

Understanding Hybrid Search

Neither full-text nor vector search is perfect for every workload.

Hybrid search combines both approaches.

Instead of choosing one search method, the application performs:

  • Full-text search
  • Vector search

simultaneously.

Results are then merged and ranked.

This provides higher-quality search than either technique alone.


Why Hybrid Search Works

Imagine a user searches:

“Azure SQL backup”

Keyword search finds:

  • Azure SQL backup documentation

Vector search finds:

  • Disaster recovery guidance
  • Database restore procedures
  • Business continuity articles

Combining both returns a richer, more relevant result set.


Benefits of Hybrid Search

Hybrid search offers:

  • Higher recall
  • Better ranking
  • Exact keyword matches
  • Semantic understanding
  • More complete search results
  • Improved user satisfaction
  • Better grounding for AI responses

Hybrid Search in RAG

Retrieval-Augmented Generation depends heavily on retrieving the most relevant context.

Hybrid search often performs best because it retrieves:

  • Exact terminology
  • Related concepts
  • Similar documents

The LLM then generates an answer using higher-quality evidence.

This significantly reduces hallucinations.


Choosing the Right Search Method

RequirementBest Choice
Exact keywordsFull-Text Search
SQL documentation searchFull-Text Search
Product SKU lookupFull-Text Search
Semantic similarityVector Search
AI chatbotVector Search
Recommendation engineVector Search
RAG systemHybrid Search
Enterprise searchHybrid Search
Large knowledge baseHybrid Search
Customer support assistantHybrid Search

Comparison Table

FeatureFull-TextVectorHybrid
Keyword matchingExcellentPoorExcellent
Semantic understandingNoYesYes
Finds synonymsLimitedExcellentExcellent
Natural language queriesLimitedExcellentExcellent
Requires embeddingsNoYesYes
Requires vector indexNoYesYes
Best for RAGFairGoodExcellent
AI chatbot supportLimitedExcellentExcellent
Traditional SQL workloadsExcellentModerateGood
ComplexityLowMediumHigher

DP-800 Exam Tips

Remember these key distinctions:

  • Full-text search is optimized for exact words and phrases.
  • Vector search retrieves semantically similar content using embeddings.
  • Hybrid search combines keyword precision with semantic relevance.
  • Embeddings are required only for vector and hybrid search.
  • Hybrid search is generally the preferred approach for enterprise AI assistants and RAG solutions because it balances precision and recall.
  • LIKE queries are not substitutes for full-text indexes in large-scale search applications.
  • Expect scenario-based questions asking you to recommend the most appropriate search technology based on application requirements, performance, and user experience.

Practice Exam Questions


Question 1

A development team is building an enterprise knowledge base for an AI chatbot. Users ask questions in natural language, and the chatbot retrieves relevant documents before generating a response.

Which search approach should you recommend?

A. Full-text search only

B. Semantic vector search

C. LIKE queries

D. Indexed views

Correct Answer: B

Explanation:
Semantic vector search uses embeddings to retrieve documents based on meaning rather than exact keywords. This makes it ideal for AI chatbots and Retrieval-Augmented Generation (RAG). LIKE queries and indexed views do not provide semantic understanding, while full-text search is limited to keyword matching.


Question 2

A legal department maintains millions of contracts. Attorneys usually know the exact legal terms they are searching for and require fast, precise keyword matching.

Which search technology is the best fit?

A. Hybrid search

B. Semantic vector search

C. Full-text search

D. Azure AI embeddings only

Correct Answer: C

Explanation:
Full-text search is optimized for exact words, phrases, stemming, ranking, and efficient indexing. Since attorneys typically search using precise terminology, full-text search provides the best balance of performance and accuracy.


Question 3

A company stores product manuals and wants search results to include documents discussing “automobile maintenance” when users search for “car repair.”

Which search capability provides this behavior?

A. SQL LIKE operator

B. Clustered indexes

C. Full-text search only

D. Semantic vector search

Correct Answer: D

Explanation:
Semantic vector search retrieves content based on meaning instead of exact words. Because embedding models understand semantic relationships, they recognize that “car repair” and “automobile maintenance” describe similar concepts.


Question 4

A RAG application must retrieve documents that contain both exact product names and semantically similar troubleshooting articles.

Which search strategy should you recommend?

A. Full-text search

B. LIKE queries

C. Hybrid search

D. Clustered columnstore indexes

Correct Answer: C

Explanation:
Hybrid search combines full-text search with semantic vector search. Exact product names are retrieved through keyword matching, while related troubleshooting content is found using semantic similarity.


Question 5

Which characteristic is unique to semantic vector search?

A. It stores documents in XML format.

B. It searches using vector similarity instead of exact text matching.

C. It requires clustered indexes.

D. It eliminates the need for embeddings.

Correct Answer: B

Explanation:
Semantic vector search converts content into embeddings and compares vectors using similarity metrics such as cosine similarity. It does not rely on exact text matching.


Question 6

Your application must support searches for:

  • “running”
  • “runs”
  • “ran”

using a single search term.

Which technology provides this capability without AI embeddings?

A. Full-text search

B. Azure OpenAI

C. Semantic vector search

D. Azure AI Search only

Correct Answer: A

Explanation:
Full-text search supports stemming and inflectional forms, allowing different grammatical variations of a word to match automatically without requiring embeddings.


Question 7

Which similarity metric is most commonly associated with vector search?

A. SHA-256

B. CRC32

C. Cosine similarity

D. Binary comparison

Correct Answer: C

Explanation:
Cosine similarity is the most widely used metric for measuring how similar two embedding vectors are by comparing the angle between them rather than their magnitude.


Question 8

An organization wants users to receive highly relevant search results even when they misspell keywords or use different terminology.

Which search method generally provides the highest quality results?

A. LIKE queries

B. Full-text search only

C. Hybrid search

D. Primary key lookups

Correct Answer: C

Explanation:
Hybrid search combines keyword matching with semantic understanding, improving recall and relevance by returning both exact matches and conceptually related documents.


Question 9

A database developer asks why embeddings are required for semantic search.

What is the primary purpose of embeddings?

A. Encrypt database rows.

B. Compress database backups.

C. Replace SQL indexes.

D. Represent content numerically so semantic similarity can be calculated.

Correct Answer: D

Explanation:
Embeddings transform text into high-dimensional numerical vectors that capture semantic meaning. Similar vectors represent similar concepts, enabling semantic search.


Question 10

Which scenario is the strongest candidate for using hybrid search instead of only full-text search?

A. Searching employee IDs

B. Retrieving rows by primary key

C. Supporting an AI assistant that answers questions using company documentation

D. Looking up invoice numbers

Correct Answer: C

Explanation:
AI assistants benefit from hybrid search because they require both exact keyword matching and semantic understanding. Hybrid search improves document retrieval quality, which directly improves the quality of RAG-generated responses.


DP-800 Exam Tips

  • Full-text search is best for exact keywords, phrases, and language-aware searches using stemming and ranking.
  • Semantic vector search retrieves information based on meaning by comparing embeddings with similarity metrics such as cosine similarity.
  • Hybrid search combines keyword precision with semantic relevance and is generally the preferred approach for enterprise AI search and RAG solutions.
  • Embeddings are required for vector and hybrid search but not for traditional full-text search.
  • Expect scenario-based exam questions where you must recommend the most appropriate search technology based on user requirements, data type, query style, and application architecture.
  • Remember that LIKE queries are suitable only for simple pattern matching and are not a replacement for full-text or semantic search in large-scale intelligent applications.

Go to the DP-800 Exam Prep Hub main page

Implement full-text search (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:
Implement AI capabilities in database solutions (25–30%)
   --> Design and implement intelligent search
      --> Implement full-text search


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

Full-text search is one of the foundational search technologies available in Microsoft SQL Server and Azure SQL Managed Instance. Unlike traditional SQL searches that rely on exact text matching through operators such as LIKE, full-text search provides a much more efficient and intelligent mechanism for searching large collections of textual data.

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

  • What full-text search is
  • When it should be used
  • How it works internally
  • Full-text indexes and catalogs
  • Supported query predicates and functions
  • Language-aware searching
  • Stoplists and thesaurus files
  • Ranking search results
  • Performance considerations
  • When to choose full-text search instead of vector or hybrid search

Although AI-powered semantic search is becoming increasingly popular, full-text search remains an important technology for applications that require fast keyword-based retrieval.


What Is Full-Text Search?

Full-text search is a SQL Server feature that enables efficient searching of large text columns.

Unlike:

WHERE Description LIKE '%backup%'

full-text search creates a specialized index that understands words rather than simple character sequences.

It supports searching within:

  • CHAR
  • VARCHAR
  • NCHAR
  • NVARCHAR
  • TEXT (legacy)
  • NTEXT (legacy)
  • XML
  • FILESTREAM documents through filters

Instead of scanning every row, SQL Server searches an optimized full-text index.


Why Traditional LIKE Queries Are Limited

Many developers initially use:

SELECT *
FROM Articles
WHERE Content LIKE '%security%'

Although this works, it has several disadvantages:

  • Table scans on large datasets
  • Poor performance
  • Cannot rank results
  • No language awareness
  • No stemming
  • No synonym support
  • Limited search capabilities

For enterprise search applications, LIKE queries do not scale effectively.


Benefits of Full-Text Search

Full-text search provides:

  • Fast keyword searches
  • Phrase searching
  • Prefix matching
  • Inflectional searches
  • Linguistic processing
  • Word breaking
  • Ranking of results
  • Stop word removal
  • Efficient indexing
  • Large-scale text retrieval

Full-Text Search Architecture

Several components work together.

Source Tables

Contain text data.

Example:

Articles
Products
KnowledgeBase
SupportTickets
Policies

Full-Text Index

Instead of indexing every character, SQL Server stores:

  • Tokens
  • Word positions
  • Language metadata

This dramatically speeds searches.


Full-Text Catalog

A full-text catalog is a logical container for one or more full-text indexes.

Modern SQL Server versions automatically manage catalogs, but understanding the concept remains important for the DP-800 exam.


Word Breakers

SQL Server separates text into words using language-specific rules.

Example:

SQL Server enables intelligent search.

becomes

SQL
Server
enables
intelligent
search

Different languages use different tokenization rules.


Stemmers

Stemmers recognize grammatical variations.

Searching:

run

may also find

  • running
  • runs
  • ran

depending on the configured language.


Enabling Full-Text Search

Before using full-text search:

  1. Install Full-Text Search feature.
  2. Create a unique key index.
  3. Create a full-text catalog (optional in newer versions).
  4. Create a full-text index.

Example:

CREATE FULLTEXT INDEX
ON Articles(Content)
KEY INDEX PK_Articles;

The index is then populated.


Full-Text Predicates

The DP-800 exam expects familiarity with common predicates.


CONTAINS()

Searches for precise words or phrases.

Example:

SELECT *
FROM Articles
WHERE CONTAINS(Content,'Azure');

Phrase Search

CONTAINS(Content,'"Azure SQL"')

Returns only rows containing the complete phrase.


Boolean Operators

Supports:

AND
OR
AND NOT

Example:

CONTAINS(Content,'"Azure" AND "Backup"')

Prefix Search

CONTAINS(Content,'"cloud*"')

Matches

  • cloud
  • clouds
  • cloud-based
  • clouding

Proximity Search

Finds words located near each other.

Example:

database NEAR backup

Useful when context matters.


FREETEXT()

Unlike CONTAINS(), FREETEXT searches for the meaning of words rather than exact expressions.

Example:

SELECT *
FROM Articles
WHERE FREETEXT(Content,'database recovery');

SQL Server automatically considers:

  • synonyms
  • stemming
  • inflectional forms

It is more natural-language oriented than CONTAINS().


Ranking Results

Often multiple documents match.

SQL Server can assign relevance rankings.

Functions include:

CONTAINSTABLE()
FREETEXTTABLE()

Example:

SELECT *
FROM CONTAINSTABLE
(
Articles,
Content,
'Azure'
)

Returns:

  • KEY
  • RANK

Applications can sort using the ranking score.


Stoplists

Certain words appear so frequently that indexing them offers little value.

Examples:

  • the
  • is
  • and
  • a
  • of

These are called stop words.

Stoplists improve:

  • Index size
  • Query performance
  • Search quality

Custom stoplists may also be created.


Thesaurus Files

SQL Server supports synonym expansion through thesaurus XML files.

Example:

Searching:

car

may automatically include

automobile
vehicle

This improves keyword searches without requiring embeddings.


Supported Languages

Full-text search supports dozens of languages.

Language-specific processing includes:

  • tokenization
  • stemming
  • stop words
  • word breakers

Examples include:

  • English
  • French
  • German
  • Spanish
  • Japanese
  • Chinese

Each language has its own linguistic rules.


Maintaining Full-Text Indexes

Indexes require updates when data changes.

Population modes include:

Full Population

Rebuilds the entire index.

Suitable for:

  • initial creation
  • major updates

Automatic Change Tracking

Automatically updates the index after data modifications.

Recommended for most OLTP workloads.


Manual Population

Administrators trigger updates manually.

Useful when:

  • large batch loads occur
  • maintenance windows exist

Performance Considerations

Full-text search is highly optimized but requires planning.

Consider:

  • index storage
  • population time
  • update frequency
  • large document sizes
  • language configuration
  • stoplists

For massive document repositories, automatic population should be monitored to avoid excessive resource usage.


When to Use Full-Text Search

Choose full-text search when users search by:

  • keywords
  • phrases
  • document titles
  • product names
  • legal terminology
  • technical documentation

Examples:

  • Knowledge bases
  • Product catalogs
  • Documentation portals
  • Legal document repositories
  • Medical reference systems

When NOT to Use Full-Text Search

Full-text search is not ideal when users expect semantic understanding.

Example:

User searches:

“recover my account”

Stored document:

“reset your password”

These phrases contain different words.

Full-text search may not match them effectively.

Semantic vector search would perform much better.


Full-Text Search vs LIKE

FeatureLIKEFull-Text Search
PerformancePoor on large tablesExcellent
Uses indexesLimitedSpecialized full-text indexes
Phrase searchLimitedYes
Word stemmingNoYes
Stop wordsNoYes
RankingNoYes
Prefix searchLimitedYes
Language awarenessNoYes

Full-Text Search vs Semantic Vector Search

FeatureFull-TextVector Search
Keyword matchingExcellentLimited
Semantic understandingNoExcellent
Embeddings requiredNoYes
Natural languageLimitedExcellent
Synonym understandingLimitedExcellent
AI chatbot supportModerateExcellent
RAG supportModerateExcellent
ComplexityLowMedium

Common DP-800 Scenarios

Scenario 1

A legal team searches contracts using exact legal terminology.

Best solution: Full-text search.


Scenario 2

A documentation portal searches millions of technical articles.

Best solution: Full-text search.


Scenario 3

An AI assistant answers questions using company documentation.

Best solution: Hybrid search (full-text + vector search).


Scenario 4

A recommendation engine finds similar documents.

Best solution: Vector search.


Best Practices

  • Use full-text indexes instead of LIKE for large text searches.
  • Configure the correct language for linguistic processing.
  • Enable automatic change tracking for frequently updated data.
  • Use stoplists to reduce index size and improve relevance.
  • Use CONTAINS() for precise searches and FREETEXT() for natural-language style queries.
  • Use CONTAINSTABLE() or FREETEXTTABLE() when relevance ranking is required.
  • Consider hybrid search when applications require both keyword precision and semantic understanding.
  • Monitor full-text index population and maintenance in production environments.

DP-800 Exam Tips

  • Know the differences between CONTAINS(), FREETEXT(), CONTAINSTABLE(), and FREETEXTTABLE().
  • Understand how full-text indexes differ from traditional SQL indexes.
  • Remember that full-text search is keyword-based, while vector search is meaning-based.
  • Understand the purpose of stoplists, word breakers, stemmers, and thesaurus files.
  • Expect scenario-based questions asking you to choose between LIKE queries, full-text search, vector search, and hybrid search based on application requirements.
  • Know when full-text search is sufficient and when semantic search or hybrid search provides a better user experience.

Practice Exam Questions


Question 1

A company stores millions of technical articles in an Azure SQL Database. Users frequently search for exact product names and technical terms. Developers currently use the following query:

SELECT *
FROM Articles
WHERE Content LIKE '%Azure SQL%'

The search is becoming increasingly slow as the table grows.

Which feature should you recommend?

A. Full-text search
B. Columnstore indexes
C. Semantic vector search
D. Table partitioning

Correct Answer: A

Explanation

Full-text search is specifically designed for efficient searching of large text columns. It creates specialized indexes that support keyword searches, phrase matching, ranking, and linguistic analysis. While table partitioning and columnstore indexes improve other workloads, they do not replace full-text search functionality.


Question 2

Which SQL Server function searches for exact words, phrases, Boolean expressions, and prefix terms?

A. FREETEXT()
B. CONTAINS()
C. PATINDEX()
D. CHARINDEX()

Correct Answer: B

Explanation

CONTAINS() supports advanced search expressions including:

  • Exact words
  • Exact phrases
  • Boolean operators (AND, OR, AND NOT)
  • Prefix searches
  • Proximity searches

FREETEXT() is intended for natural-language searching rather than precise keyword expressions.


Question 3

A developer wants search results to include different grammatical forms of the word run, such as:

  • running
  • runs
  • ran

Which SQL Server component provides this capability?

A. Stoplists

B. Full-text catalogs

C. Stemmers

D. Clustered indexes

Correct Answer: C

Explanation

Stemmers recognize different inflectional forms of words based on language-specific rules. This allows a search for “run” to also return documents containing “running,” “runs,” or “ran.”


Question 4

Which statement best describes a full-text catalog?

A. It stores database backups.

B. It replaces clustered indexes.

C. It is a logical container that organizes one or more full-text indexes.

D. It stores vector embeddings.

Correct Answer: C

Explanation

A full-text catalog is a logical container for full-text indexes. While SQL Server automatically manages catalogs in newer versions, understanding their role remains important for administration and exam scenarios.


Question 5

Which function is most appropriate when users enter natural-language search phrases rather than precise keywords?

A. CONTAINS()

B. LIKE

C. FREETEXT()

D. PATINDEX()

Correct Answer: C

Explanation

FREETEXT() performs natural-language searches by considering linguistic analysis, stemming, and synonyms. It is designed for less structured search input compared to CONTAINS().


Question 6

Which full-text search feature helps reduce index size by excluding commonly occurring words such as the, is, and and?

A. Word breakers

B. Stoplists

C. Stemmers

D. Ranking tables

Correct Answer: B

Explanation

Stoplists contain common words, known as stop words, that are ignored during indexing and searching. This improves both index efficiency and search relevance.


Question 7

Your application must display search results ordered from the most relevant document to the least relevant.

Which functions are specifically designed for this purpose?

A. CONTAINS() and FREETEXT()

B. LIKE and PATINDEX()

C. CONTAINSTABLE() and FREETEXTTABLE()

D. CHARINDEX() and STRING_SPLIT()

Correct Answer: C

Explanation

CONTAINSTABLE() and FREETEXTTABLE() return a RANK value that indicates the relevance of each result, allowing applications to sort documents by search quality.


Question 8

Which scenario is the best use case for traditional full-text search?

A. Finding semantically similar customer support tickets

B. Building a Retrieval-Augmented Generation (RAG) chatbot

C. Recommending similar research papers based on meaning

D. Searching legal documents using exact legal terminology

Correct Answer: D

Explanation

Full-text search excels when users search using precise words and phrases, making it well suited for legal, compliance, technical documentation, and product catalog scenarios. Semantic vector search is generally preferred for AI assistants and recommendation systems.


Question 9

Which component is responsible for separating text into searchable words based on language-specific rules?

A. Word breakers

B. Stoplists

C. Embedding models

D. Full-text catalogs

Correct Answer: A

Explanation

Word breakers tokenize text into individual searchable terms according to the linguistic rules of the configured language. Proper tokenization is essential for accurate indexing and querying.


Question 10

A company is building an AI-powered knowledge assistant. Users expect searches such as:

“recover my account”

to return documents titled:

“reset your password”

Which recommendation is most appropriate?

A. Continue using LIKE queries

B. Use only full-text search

C. Replace all searches with clustered indexes

D. Combine full-text search with semantic vector search using hybrid search

Correct Answer: D

Explanation

Full-text search primarily matches keywords and phrases, while semantic vector search retrieves documents based on meaning. Hybrid search combines both approaches, producing more accurate results for AI-powered applications such as RAG systems and enterprise knowledge assistants.


DP-800 Exam Tips

  • Use full-text search when exact keywords, phrases, and language-aware matching are required.
  • Understand the differences between CONTAINS(), FREETEXT(), CONTAINSTABLE(), and FREETEXTTABLE().
  • Remember that word breakers tokenize text, stemmers recognize grammatical variations, and stoplists remove common words to improve search efficiency.
  • Use ranking functions when applications need to order search results by relevance.
  • Recognize that LIKE queries are not appropriate for large-scale enterprise text search.
  • Know that full-text search is keyword-based, while vector search is meaning-based; hybrid search combines the strengths of both and is often the preferred approach for AI-enabled search solutions.

Go to the DP-800 Exam Prep Hub main page

Design for vector data, including vector data type, vector indexes, and size (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:
Implement AI capabilities in database solutions (25–30%)
   --> Design and implement intelligent search
      --> Design for vector data, including vector data type, vector indexes, and size


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 AI-enabled applications increasingly rely on vector data to represent the meaning of text, images, audio, and other unstructured information. Instead of matching exact words, vector-based search enables applications to find content based on semantic similarity.

Microsoft SQL Server 2025, Azure SQL Database, and Azure SQL Managed Instance introduce native support for vector data, allowing databases to store embeddings directly alongside relational data. Combined with AI models and vector indexes, SQL databases become powerful platforms for semantic search, Retrieval-Augmented Generation (RAG), recommendation engines, document similarity, and AI assistants.

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

  • Design schemas that store vector embeddings
  • Choose appropriate vector dimensions
  • Understand vector data types
  • Create and maintain vector indexes
  • Balance storage, performance, and accuracy
  • Select index types appropriate for AI workloads
  • Understand how vector size affects database performance

What Is Vector Data?

A vector is a numerical representation of data generated by an embedding model.

Instead of storing text directly, the model converts text into hundreds or thousands of floating-point numbers.

Example:

Original text:

“Azure SQL supports AI-powered search.”

Embedding:

[0.012,
-0.553,
0.441,
...
0.318]

This numerical representation captures semantic meaning.

Documents discussing:

  • AI databases
  • Azure SQL
  • semantic search

will produce vectors located close together within vector space.


Why Store Vectors in SQL?

Traditionally, embeddings were stored in external vector databases.

Modern SQL databases now support vectors directly, allowing organizations to:

  • Keep structured and unstructured data together
  • Simplify architecture
  • Reduce synchronization complexity
  • Improve transactional consistency
  • Query relational and vector data simultaneously

Example table:

ProductIDNameCategoryDescriptionDescriptionEmbedding
101LaptopElectronicsPortable computerVector

This allows applications to perform:

  • SQL filtering
  • joins
  • semantic search

within one query.


Understanding the Vector Data Type

The new VECTOR data type stores embeddings efficiently inside SQL tables.

Example:

VECTOR(1536)

The number specifies the vector dimensions.

Examples:

VECTOR(768)
VECTOR(1024)
VECTOR(1536)
VECTOR(3072)

The dimension must exactly match the embedding model.


What Are Vector Dimensions?

Each embedding model outputs a fixed number of values.

Examples:

ModelTypical Dimensions
Small embedding model768
text-embedding-3-small1536
text-embedding-3-large3072

If an embedding model generates 1536 values:

VECTOR(1536)

must be used.

Using the wrong size causes insert failures.


Choosing the Correct Vector Size

Higher dimensions provide richer semantic meaning.

However they also require:

  • more storage
  • larger indexes
  • slower searches
  • additional memory

Example comparison:

DimensionsCharacteristics
256Very small, fast, lower accuracy
768Good balance
1024Higher quality
1536Excellent semantic understanding
3072Highest quality but larger storage

Choosing unnecessarily large vectors wastes storage.


How Embedding Size Affects Storage

Each dimension stores a floating-point number.

Example:

1536 dimensions

≈1536 floating point values

Across one million rows:

1,000,000 vectors
×
1536 dimensions

This becomes a significant storage requirement.

Large AI applications should estimate storage before deployment.


Designing Tables for Vector Data

Common design:

Documents
------------
DocumentID
Title
Category
Content
Embedding

The embedding column stores semantic meaning.

Other columns remain relational.

This design enables hybrid queries.


Separating Embeddings from Business Data

Many organizations separate embeddings into another table.

Example:

Documents
DocumentID
Title
Content
DocumentEmbeddings
DocumentID
Embedding
ModelVersion
CreatedDate

Benefits:

  • easier regeneration
  • reduced locking
  • independent maintenance
  • multiple embedding versions

Versioning Embeddings

Embedding models evolve.

Example:

Version 1:

text-embedding-3-small

Later:

text-embedding-3-large

A model change usually requires regenerating all vectors.

Many databases store:

  • Model Name
  • Version
  • Generation Date

This allows safe migrations.


One Embedding or Multiple?

Some applications store several embeddings.

Example:

Products

  • Title embedding
  • Description embedding
  • Review embedding

Different searches can target different meanings.


Designing for Chunk-Level Embeddings

Large documents are usually divided into chunks.

Instead of:

Entire PDF
One vector

Applications store:

Document
Paragraphs
One vector per paragraph

Benefits include:

  • higher search precision
  • better RAG responses
  • smaller embeddings
  • improved relevance

Vector Search vs Traditional Search

Traditional search matches keywords.

Example:

Search:

vehicle

Document:

car

Keyword search may miss it.

Vector search recognizes semantic similarity.

It understands:

  • automobile
  • vehicle
  • car
  • SUV

are closely related.


Combining SQL Filters with Vector Search

One major benefit of SQL databases is combining structured filters with AI search.

Example:

Category = Electronics
AND
Vector similarity

Only electronics are searched semantically.

This improves both performance and relevance.


Exact Search vs Approximate Search

Vector searches generally use two approaches.

Exact Search

Compares every vector.

Advantages:

  • highest accuracy

Disadvantages:

  • slower
  • expensive for large datasets

Approximate Search

Uses specialized indexes.

Advantages:

  • much faster
  • scalable

Tradeoff:

  • slight reduction in accuracy

Most production AI systems use approximate search.


Understanding Vector Indexes

Without indexes:

Every vector must be compared.

1 million vectors
1 million comparisons

Vector indexes dramatically reduce work.

They organize vectors based on similarity.

This enables very fast nearest-neighbor searches.


Approximate Nearest Neighbor (ANN)

Modern vector databases commonly use ANN indexing.

Instead of checking every vector:

Search
Relevant region
Nearby vectors
Best matches

Response times become milliseconds instead of seconds.


Why Vector Indexes Matter

Benefits include:

  • faster semantic search
  • reduced CPU usage
  • scalable AI applications
  • improved RAG performance
  • lower query latency

Large AI systems depend heavily on vector indexing.


Choosing Whether to Create a Vector Index

Small datasets:

A vector index may not provide significant benefit.

Large datasets:

Vector indexes become essential.

Typical guidance:

RowsRecommendation
ThousandsOptional
Hundreds of thousandsRecommended
MillionsEssential

Best Practices

  • Use the embedding dimensions required by the selected model.
  • Store vectors in dedicated VECTOR columns.
  • Keep relational data alongside embeddings whenever practical.
  • Separate embeddings into dedicated tables when frequent regeneration is expected.
  • Track embedding model versions.
  • Chunk large documents before generating embeddings.
  • Choose the smallest embedding model that delivers acceptable quality.
  • Create vector indexes for large datasets.
  • Combine relational filtering with semantic search.
  • Monitor storage growth as embeddings increase.

Common Exam Tips

  • Know that VECTOR stores embedding data.
  • Understand that vector dimensions must match the embedding model.
  • Remember that larger vectors increase storage and memory requirements.
  • Recognize that vector indexes accelerate semantic similarity searches.
  • Understand the difference between exact and approximate nearest-neighbor searches.
  • Know that chunking improves retrieval quality for large documents.
  • Understand that multiple embeddings may exist for a single record.
  • Remember that embedding model upgrades usually require regenerating vectors.
  • Understand that relational filtering and vector search can be combined.
  • Expect scenario-based questions involving storage, indexing, scalability, and AI search architecture.

Practice Exam Questions


Question 1

A company is building a Retrieval-Augmented Generation (RAG) application using Azure SQL Database. They plan to store embeddings generated by the text-embedding-3-small model.

Which VECTOR data type should be used for the embedding column?

A. VECTOR(768)
B. VECTOR(1024)
C. VECTOR(1536)
D. VECTOR(3072)

Correct Answer: C

Explanation:
The text-embedding-3-small model generates 1,536-dimensional embeddings. The VECTOR column must match the number of dimensions produced by the embedding model. Using any other dimension would prevent embeddings from being stored correctly.


Question 2

A database contains 12 million product embeddings. Semantic searches are becoming increasingly slow because every query compares all vectors.

What should the database developer implement?

A. A clustered index on the VECTOR column
B. A vector index that supports Approximate Nearest Neighbor (ANN) searches
C. A nonclustered index on the product name
D. A filtered index on the category column

Correct Answer: B

Explanation:
Vector indexes using Approximate Nearest Neighbor algorithms dramatically reduce the number of comparisons required during similarity searches. Traditional SQL indexes cannot optimize vector similarity calculations.


Question 3

A developer must choose between a 768-dimensional embedding model and a 3,072-dimensional embedding model.

What is generally true about the larger embedding model?

A. It always performs searches faster.
B. It requires fewer storage resources.
C. It typically captures more semantic detail but requires additional storage and memory.
D. It cannot be indexed.

Correct Answer: C

Explanation:
Higher-dimensional embeddings generally preserve more semantic information, improving search quality. However, they increase storage requirements, memory consumption, and indexing costs.


Question 4

A database stores customer information together with vector embeddings representing customer support conversations.

Which design provides the greatest flexibility for regenerating embeddings after switching to a new embedding model?

A. Store embeddings in a separate table linked by the primary key.
B. Store embeddings inside a JSON document.
C. Store embeddings inside XML columns.
D. Store embeddings inside temporary tables.

Correct Answer: A

Explanation:
Separating embeddings into their own table simplifies regeneration, maintenance, versioning, and model migration while keeping business data unchanged.


Question 5

A development team wants to search only engineering documents while using semantic similarity.

Which approach best meets this requirement?

A. Perform only vector similarity searches across every document.
B. Filter documents by department using SQL, then perform vector similarity searches.
C. Disable relational filtering.
D. Store engineering documents in a separate SQL Server instance.

Correct Answer: B

Explanation:
One advantage of SQL databases is combining structured filtering with vector similarity search. Restricting the dataset before similarity comparisons improves both performance and relevance.


Question 6

A company stores embeddings for technical manuals that average 400 pages each.

What is the recommended design approach?

A. Generate one embedding for the entire manual.
B. Store only the title as an embedding.
C. Divide manuals into logical chunks and generate embeddings for each chunk.
D. Generate embeddings only for images.

Correct Answer: C

Explanation:
Chunking improves semantic retrieval accuracy by allowing searches to return only the most relevant portions of large documents rather than entire documents.


Question 7

A developer upgrades from one embedding model to another that produces vectors with a different number of dimensions.

What should the developer expect?

A. Existing vectors automatically resize.
B. Existing vectors remain compatible without changes.
C. SQL Server automatically converts vector dimensions.
D. Existing embeddings must be regenerated to match the new model dimensions.

Correct Answer: D

Explanation:
Embedding dimensions are fixed for each model. Changing models often changes vector size, requiring regeneration of all stored embeddings.


Question 8

An application contains approximately 3,000 embedded documents.

Which statement is most accurate regarding vector indexes?

A. Vector indexes are mandatory regardless of database size.
B. Vector indexes cannot be created until at least one million vectors exist.
C. A vector index may provide limited benefit for a very small dataset.
D. Vector indexes only work with GraphQL.

Correct Answer: C

Explanation:
Small datasets often perform adequately without vector indexes. The performance gains become much more significant as the number of vectors increases.


Question 9

A developer wants to support semantic search over product descriptions while maintaining product categories, prices, and inventory information in the same database.

Which database design best supports this objective?

A. Store embeddings in a VECTOR column while keeping relational attributes in standard SQL columns.
B. Store all relational data inside embedding vectors.
C. Replace relational tables with JSON files.
D. Store embeddings only in application memory.

Correct Answer: A

Explanation:
Keeping embeddings alongside relational data enables hybrid queries that combine SQL filtering with semantic similarity search, one of the major strengths of AI-enabled SQL databases.


Question 10

Which factor has the greatest impact on the storage requirements of vector data?

A. Database collation
B. Number of database users
C. Recovery model
D. Number of dimensions in each embedding

Correct Answer: D

Explanation:
Each embedding stores one numeric value per dimension. As the number of dimensions increases, the storage required for each vector grows proportionally, affecting table size, indexes, backups, and memory usage.


Final Exam Tips

  • Ensure the VECTOR column dimension exactly matches the embedding model.
  • Larger embeddings generally improve semantic quality but increase storage and computational costs.
  • Use vector indexes (ANN) for large datasets to improve search performance.
  • Combine relational SQL filtering with vector similarity searches for efficient hybrid queries.
  • Chunk large documents before generating embeddings to improve retrieval quality.
  • Store embedding model metadata and versions to simplify future migrations.
  • Separate embeddings from business data when frequent regeneration is expected.
  • Expect scenario-based questions comparing performance, storage, indexing strategies, and search architectures.

Go to the DP-800 Exam Prep Hub main page

Identify when to use vector-related types and functions for semantic searching, including VECTOR_NORMALIZE, VECTOR_DISTANCE, VECTORPROPERTY, and VECTOR_SEARCH (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:
Implement AI capabilities in database solutions (25–30%)
   --> Design and implement intelligent search
      --> Identify when to use vector-related types and functions for semantic searching, including VECTOR_NORMALIZE, VECTOR_DISTANCE, VECTORPROPERTY, and VECTOR_SEARCH


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 AI-powered database applications increasingly rely on semantic search, which retrieves information based on meaning rather than exact keyword matches. SQL Server 2025 (Preview), Azure SQL Database, and Azure SQL Managed Instance now include native vector capabilities, allowing developers to store embeddings and perform semantic searches directly inside the database.

Instead of exporting data to a separate vector database, developers can use built-in vector data types and functions to compare embeddings, calculate similarity, inspect vector metadata, normalize vectors, and perform efficient nearest-neighbor searches.

For the DP-800 certification exam, you should understand:

  • When semantic search is appropriate
  • The purpose of the VECTOR data type
  • How VECTOR_DISTANCE measures similarity
  • Why VECTOR_NORMALIZE is useful
  • How VECTORPROPERTY retrieves vector metadata
  • When to use VECTOR_SEARCH
  • Performance considerations
  • Common semantic search design patterns

Understanding Semantic Search

Traditional SQL searches compare exact values.

Example:

WHERE Description LIKE '%car%'

This search only returns rows containing the word car.

Semantic search instead compares meaning.

Searching for:

vehicle

may also return:

  • automobile
  • SUV
  • truck
  • sedan
  • crossover

because their embeddings are close together within vector space.


Native Vector Support in SQL

Microsoft SQL now supports vectors as first-class database objects.

Instead of storing embeddings externally, SQL databases can store:

  • relational columns
  • vector columns
  • AI metadata

inside one table.

Example:

ProductIDNameCategoryEmbedding
101LaptopElectronicsVECTOR(1536)

This enables SQL to perform both relational filtering and semantic similarity searches.


VECTOR Data Type

The VECTOR data type stores embedding values.

Example:

Embedding VECTOR(1536)

The dimension must exactly match the embedding model.

Examples:

  • VECTOR(768)
  • VECTOR(1024)
  • VECTOR(1536)
  • VECTOR(3072)

The VECTOR type is the foundation of all semantic search operations.


When to Use VECTOR_DISTANCE

VECTOR_DISTANCE measures how similar two vectors are.

Think of it as calculating the “distance” between meanings.

Smaller distance

More similar

Larger distance

Less similar

Example:

Customer query:

lightweight laptop

Document A

portable notebook computer

Very small distance

Document B

kitchen appliances

Very large distance


Common Uses of VECTOR_DISTANCE

Developers commonly use VECTOR_DISTANCE to:

  • Rank search results
  • Compare embeddings
  • Measure semantic similarity
  • Build recommendation engines
  • Find related documents
  • Identify duplicate content
  • Support AI assistants

Example Scenario

Suppose a user searches:

cloud database backup

SQL compares the query embedding against stored embeddings.

Each document receives a distance score.

Example:

DocumentDistance
Azure Backup Guide0.08
SQL Disaster Recovery0.13
Cloud Storage Overview0.19
Restaurant Menu0.92

The smallest distance represents the best semantic match.


Choosing a Distance Metric

Several similarity calculations exist.

Common metrics include:

  • Cosine similarity
  • Euclidean distance
  • Dot product

SQL vector functions abstract much of this complexity.

Developers simply request semantic similarity without implementing complex mathematics.


Why VECTOR_NORMALIZE Exists

Different vectors may have different magnitudes.

Normalization converts vectors into standardized lengths.

Instead of comparing:

Length + Direction

only

Direction

is compared.

This improves consistency.


When to Normalize Vectors

Normalization is commonly used when:

  • comparing embeddings from different sources
  • improving cosine similarity calculations
  • preprocessing vectors
  • preparing vectors before indexing

Many embedding models already generate normalized vectors.

Others do not.


Benefits of VECTOR_NORMALIZE

Normalization helps:

  • improve comparison consistency
  • reduce magnitude bias
  • improve semantic similarity scoring
  • produce more reliable nearest-neighbor searches

VECTORPROPERTY

VECTORPROPERTY retrieves metadata about vectors.

Rather than comparing vectors, it provides information about them.

Examples include:

  • dimension count
  • storage characteristics
  • metadata
  • vector properties

Developers often use VECTORPROPERTY for:

  • validation
  • diagnostics
  • troubleshooting
  • quality checks

Example Scenario

A developer receives embeddings from multiple AI models.

Some generate:

768 dimensions

Others generate:

1536 dimensions

Before inserting data, the developer verifies dimensions using VECTORPROPERTY.

This prevents invalid inserts.


VECTOR_SEARCH

VECTOR_SEARCH performs semantic nearest-neighbor searches.

Instead of writing complex similarity calculations manually, developers can search vectors directly.

Typical workflow:

User Question

Generate embedding

VECTOR_SEARCH

Most similar documents

Return results


When to Use VECTOR_SEARCH

VECTOR_SEARCH is ideal for:

  • Retrieval-Augmented Generation (RAG)
  • AI chatbots
  • document search
  • recommendation engines
  • semantic search portals
  • customer support systems
  • knowledge bases

VECTOR_SEARCH vs VECTOR_DISTANCE

Although related, they serve different purposes.

VECTOR_DISTANCE

  • compares two vectors

VECTOR_SEARCH

  • searches an entire collection

Think of it this way:

VECTOR_DISTANCE

Individual comparison

VECTOR_SEARCH

Database-wide search


Example Workflow

A user asks:

How do I configure Azure SQL backups?

Step 1

Generate query embedding.

Step 2

VECTOR_SEARCH finds similar documents.

Step 3

Top documents returned.

Step 4

LLM generates an answer.


Combining SQL Filtering with VECTOR_SEARCH

One advantage of SQL databases is hybrid querying.

Example:

Return only:

Category = Documentation

AND

perform semantic search.

This combines relational filtering with AI similarity.

Benefits include:

  • better accuracy
  • faster searches
  • improved relevance

Performance Considerations

Semantic search can become expensive.

Best practices include:

  • use vector indexes
  • normalize vectors when appropriate
  • filter relational data first
  • avoid unnecessarily large embeddings
  • use approximate nearest-neighbor indexes
  • limit returned results

Typical Semantic Search Architecture

Documents

Generate embeddings

Store vectors

Create vector index

User submits question

Generate query embedding

VECTOR_SEARCH

Nearest neighbors

LLM response


Choosing the Correct Function

FunctionPrimary Purpose
VECTORStores embeddings
VECTOR_DISTANCEMeasures similarity between two vectors
VECTOR_NORMALIZEStandardizes vectors before comparison
VECTORPROPERTYReturns vector metadata
VECTOR_SEARCHSearches collections for similar vectors

Best Practices

  • Store embeddings using the VECTOR data type.
  • Match VECTOR dimensions to the embedding model.
  • Use VECTOR_SEARCH for semantic retrieval.
  • Use VECTOR_DISTANCE for direct similarity comparisons.
  • Normalize vectors when required by the similarity metric.
  • Use VECTORPROPERTY to validate vector characteristics.
  • Combine relational filters with vector searches.
  • Create vector indexes for large datasets.
  • Store embedding model versions alongside vectors.
  • Monitor storage and indexing costs.

Common DP-800 Exam Tips

  • Understand when semantic search is preferable to keyword search.
  • Know the purpose of each vector function.
  • Understand that VECTOR_DISTANCE compares two vectors, while VECTOR_SEARCH searches an entire dataset.
  • Remember that VECTOR_NORMALIZE standardizes vectors before comparison.
  • Know that VECTORPROPERTY retrieves vector metadata rather than similarity scores.
  • Expect scenario-based questions requiring you to choose the correct vector function for a given task.
  • Understand how these functions support RAG, AI assistants, recommendation systems, and semantic search.

Practice Exam Questions


Question 1

A development team is building a Retrieval-Augmented Generation (RAG) application. They need to compare a user’s query embedding against thousands of stored document embeddings and return the most semantically similar documents.

Which SQL function is specifically designed for this purpose?

A. VECTOR_DISTANCE

B. VECTOR_SEARCH

C. VECTORPROPERTY

D. VECTOR_NORMALIZE

Correct Answer: B

Explanation:

VECTOR_SEARCH is designed to search an entire collection of stored vectors and return the nearest neighbors based on semantic similarity. VECTOR_DISTANCE compares only two vectors, VECTORPROPERTY returns metadata, and VECTOR_NORMALIZE standardizes vectors before comparison.


Question 2

An application receives embeddings from several AI models. Before storing them in SQL, developers want to verify that every embedding contains the expected number of dimensions.

Which function should they use?

A. VECTORPROPERTY

B. VECTOR_DISTANCE

C. VECTOR_SEARCH

D. VECTOR_NORMALIZE

Correct Answer: A

Explanation:

VECTORPROPERTY returns metadata about a vector, including characteristics such as its dimensions. This makes it ideal for validating vectors before they are stored.


Question 3

A developer needs to calculate how semantically similar two individual product descriptions are after generating embeddings for each.

Which function should be used?

A. VECTORPROPERTY

B. VECTOR_SEARCH

C. VECTOR_DISTANCE

D. VECTOR_NORMALIZE

Correct Answer: C

Explanation:

VECTOR_DISTANCE calculates the similarity or distance between two vectors. It is appropriate when directly comparing one embedding against another rather than searching an entire dataset.


Question 4

A machine learning engineer wants to eliminate differences caused by varying vector magnitudes before calculating cosine similarity.

Which function is most appropriate?

A. VECTORPROPERTY

B. VECTOR_SEARCH

C. VECTOR_DISTANCE

D. VECTOR_NORMALIZE

Correct Answer: D

Explanation:

VECTOR_NORMALIZE scales vectors to a consistent length while preserving their direction. This improves similarity calculations that rely on normalized vectors, particularly cosine similarity.


Question 5

A customer support chatbot first filters documentation to only include networking articles and then performs semantic retrieval over those documents.

What is the primary advantage of this approach?

A. It removes the need for embeddings.

B. It combines relational filtering with semantic search for improved relevance.

C. It converts keyword search into full-text search.

D. It prevents vector indexing.

Correct Answer: B

Explanation:

Filtering relational data before performing vector search reduces the search space and increases the relevance of returned results, improving both performance and accuracy.


Question 6

A SQL developer needs to rank five candidate documents according to how closely each one matches a user’s question.

Which function should be applied repeatedly against each candidate vector?

A. VECTOR_DISTANCE

B. VECTOR_SEARCH

C. VECTORPROPERTY

D. VECTOR_NORMALIZE

Correct Answer: A

Explanation:

VECTOR_DISTANCE computes similarity between two vectors. Developers can compare the query vector against multiple document vectors and rank the results by the smallest distance.


Question 7

Which scenario is the best use case for VECTOR_SEARCH?

A. Determining the number of dimensions stored within a vector

B. Standardizing vectors before storage

C. Finding the most similar documents across an entire knowledge base

D. Comparing only two vectors for similarity

Correct Answer: C

Explanation:

VECTOR_SEARCH is optimized for nearest-neighbor retrieval across an entire vector collection, making it ideal for semantic search applications such as RAG systems and AI assistants.


Question 8

An organization stores millions of embeddings inside Azure SQL Database.

Which action provides the greatest improvement in semantic search performance?

A. Increasing the embedding dimensions

B. Eliminating relational filtering

C. Replacing vectors with VARCHAR columns

D. Creating vector indexes

Correct Answer: D

Explanation:

Vector indexes significantly improve nearest-neighbor search performance over large datasets. Without indexing, vector searches become increasingly expensive as data volumes grow.


Question 9

A developer mistakenly uses VECTOR_SEARCH when they simply need to compare two embeddings generated during a unit test.

Which function would have been the more appropriate choice?

A. VECTORPROPERTY

B. VECTOR_DISTANCE

C. VECTOR_NORMALIZE

D. VECTOR_SEARCH

Correct Answer: B

Explanation:

VECTOR_DISTANCE compares two vectors directly. VECTOR_SEARCH is intended for searching an entire vector collection and would introduce unnecessary overhead for a simple comparison.


Question 10

Which statement best describes VECTORPROPERTY?

A. It calculates semantic similarity between vectors.

B. It searches vector indexes for nearest neighbors.

C. It retrieves metadata about stored vectors.

D. It converts text into embeddings.

Correct Answer: C

Explanation:

VECTORPROPERTY returns information about vectors, such as their dimensions or other characteristics. It does not calculate similarity, generate embeddings, or perform semantic searches.


DP-800 Exam Tips

  • Know the distinction between VECTOR_DISTANCE (two-vector comparison) and VECTOR_SEARCH (collection-wide nearest-neighbor search).
  • Use VECTORPROPERTY to inspect or validate vector metadata before processing.
  • Apply VECTOR_NORMALIZE when your similarity metric or embedding workflow benefits from normalized vectors.
  • Combine relational filtering with semantic search to improve performance and relevance.
  • Create vector indexes for large datasets to optimize semantic search operations.
  • Expect scenario-based exam questions that require selecting the appropriate vector function based on a real-world AI application, such as RAG, semantic search, recommendation systems, or AI chatbots.

Go to the DP-800 Exam Prep Hub main page