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%)
   --> Integrate Azure Managed Redis in AI solutions
      --> Implement vector indexing to enable similarity 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.

Overview

Vector similarity search is a foundational capability for modern AI applications. It allows an application to retrieve data based on semantic similarity rather than requiring an exact keyword match.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand how Azure Managed Redis can be used as a low-latency vector database, how vectors are stored and indexed, the difference between FLAT and HNSW indexing, how distance metrics affect similarity calculations, and how vector indexes are queried.

Azure Managed Redis provides vector search through the RediSearch module. Vector data can be stored in Redis hashes or JSON documents and indexed for similarity searches.

1. What Is Vector Similarity Search?

Traditional database searches generally look for exact or textual matches.

For example:

"How do I reset my password?"

A keyword-based search might look for documents containing:

• password
• reset
• credentials
• account

Vector search takes a different approach.

The text is converted into an embedding, which is a numerical representation of the semantic meaning of the text.

For example:

"How do I reset my password?"
        ↓
Embedding model
        ↓
[0.021, -0.134, 0.087, ..., 0.442]

A document such as:

“Steps for recovering your account credentials”

may have an embedding that is mathematically close to the query embedding even though the document does not contain the exact phrase “reset my password.”

This allows vector search to find semantically related information.

2. What Is an Embedding?

An embedding is a high-dimensional numerical representation of data.

Embeddings can represent:

• Text
• Documents
• Images
• Products
• Audio
• Other types of content

The embedding model transforms the original content into a vector.

For example:

Document
   ↓
Embedding model
   ↓
[0.12, -0.04, 0.81, 0.23, ...]

The number of dimensions depends on the embedding model.

Important exam concept

The vectors being indexed and the query vectors must be compatible.

In particular, the vector index configuration must match the characteristics of the embedding model, including:

• Vector dimensions
• Distance metric
• Vector representation/type

Using inconsistent embedding models can produce poor or invalid search results.

3. Azure Managed Redis as a Vector Database

Azure Managed Redis is primarily known for high-performance in-memory data operations, but it can also support vector workloads.

With the appropriate Redis functionality enabled, it can:

1. Store embeddings.
2. Create vector indexes.
3. Search vectors.
4. Return the nearest vectors.
5. Combine vector searches with metadata filtering.

This makes Azure Managed Redis useful for applications such as:

• Semantic search
• Retrieval-augmented generation (RAG)
• Recommendation systems
• Semantic caching
• Conversational memory
• Document retrieval
• Similarity matching

The major advantage is low-latency access, particularly when vector search is being performed alongside other Redis-based application data.

4. RediSearch and Vector Indexing

Azure Managed Redis uses the RediSearch functionality to provide vector search.

For Azure Managed Redis vector search, RediSearch must be enabled when the Redis instance is created. It cannot simply be added later to an existing instance.

Current Azure Managed Redis documentation identifies RediSearch support for:

• Memory Optimized
• Balanced
• Compute Optimized

The Flash Optimized tier does not support RediSearch. Azure Managed Redis vector workloads also require the Enterprise clustering policy.

Exam tip

If a scenario says:

“An existing Azure Managed Redis instance does not have RediSearch enabled. The application now needs vector similarity search.”

The important consideration is that the required module must be enabled during provisioning. You should not assume that the module can simply be installed onto an existing Azure Managed Redis instance.

5. Storing Vectors in Redis

Azure Managed Redis supports storing vector data in Redis data structures such as:

• Hashes
• JSON documents

Hashes

Hashes are useful when the application has relatively straightforward fields.

Conceptually:

document:123
    title       = "Azure AI"
    category    = "AI"
    embedding   = [ ... ]

JSON

JSON can be useful when the application has more complex or nested document structures.

Conceptually:

{
    "id": "document-123",
    "title": "Azure AI",
    "category": "AI",
    "embedding": [ ... ],
    "metadata": {
        "author": "Norm",
        "year": 2026
    }
}

The choice between hashes and JSON depends on the application’s data model and how the data will be accessed.

Microsoft’s current guidance specifically identifies both hashes and JSON as supported approaches for vector storage.

6. Why Metadata Matters

A vector should generally not exist by itself.

Applications often store metadata alongside the vector, such as:

• Document ID
• Document title
• Category
• Source URL
• Timestamp
• Tenant ID
• Author
• Security/access-control information

For example:

Document:
    id = 1001
    title = "Azure Container Apps"
    category = "Azure"
    tenant = "Contoso"
    embedding = [...]

Metadata enables filtered vector search.

For example:

Find the 5 documents most similar to this question, but only search documents belonging to the Azure category.

Or:

Find similar documents that the current user is authorized to access.

This becomes particularly important in multi-tenant and RAG applications.

7. Vector Indexing Strategies

The two important vector indexing strategies you should know for AI-200 are:

Understanding the trade-off between these approaches is important for the exam.

8. FLAT Index

A FLAT index performs an exhaustive comparison.

Conceptually:

Query vector
     |
     +---- Compare with Vector 1
     +---- Compare with Vector 2
     +---- Compare with Vector 3
     +---- Compare with Vector 4
     +---- ...
     +---- Compare with Vector N

Every candidate vector is evaluated.

Advantages

• Exact search
• High recall
• Straightforward behavior
• Useful for relatively small datasets

Disadvantages

• More computationally expensive as the dataset grows
• Latency can increase with the number of vectors

FLAT is therefore appropriate when exhaustive accuracy is more important than minimizing search computation.

9. HNSW Index

HNSW stands for Hierarchical Navigable Small World.

Instead of comparing the query against every vector, HNSW organizes vectors into a graph that allows the search to navigate toward likely nearest neighbors.

Conceptually:

                 Vector A
                /        \
           Vector B     Vector C
             /             \
        Vector D           Vector E
             \             /
                Vector F

The actual structure is considerably more sophisticated, but the important idea is that the index provides an efficient path toward nearby vectors.

Advantages

• Fast similarity searches
• Well suited to larger datasets
• Reduces the amount of computation required
• Supports approximate nearest-neighbor search

Disadvantages

• Search is approximate rather than exhaustive
• Indexing requires additional resources
• There is a trade-off between search speed, recall, and resource consumption

Microsoft identifies HNSW as a common choice for larger datasets where lower latency is more important than exhaustive precision.

10. FLAT vs. HNSW

A useful way to remember the difference is:

FLAT = accuracy through exhaustive search

HNSW = speed through approximate search

For example:

Scenario A

You have 10,000 vectors and require exact results.

FLAT may be appropriate.

Scenario B

You have millions of vectors and require very low search latency.

HNSW is generally a better candidate.

The correct choice depends on:

• Dataset size
• Required latency
• Accuracy/recall requirements
• Available resources
• Workload characteristics

11. Distance and Similarity Metrics

Once vectors are indexed, Redis needs a way to determine how close two vectors are.

Common metrics include:

Cosine

Cosine similarity measures the angle between vectors.

It is commonly used for text embeddings.

Conceptually:

Vector A
   ↘
    angle
   ↗
Vector B

The smaller the angular difference, the more semantically similar the vectors generally are.

Euclidean / L2

Euclidean distance measures the straight-line distance between vectors.

A ●----------------● B
       distance

A smaller distance indicates greater similarity.

Inner Product

Inner product, also called dot product in many contexts, can be used for similarity/ranking depending on how embeddings are generated and normalized.

Azure Managed Redis vector search supports metrics including:

• L2
• COSINE
• IP

The appropriate metric depends on the embedding model and how its vectors are represented.

12. KNN Search

A common vector-search operation is K-nearest neighbors (KNN).

Suppose the application asks:

“Which five documents are most similar to this question?”

The application sets:

K = 5

The vector search returns the five nearest vectors according to the selected similarity/distance metric.

Conceptually:

Query
  |
  +-- Result 1  ← most similar
  +-- Result 2
  +-- Result 3
  +-- Result 4
  +-- Result 5

KNN is especially useful in:

• Semantic search
• Recommendation systems
• RAG
• Similarity matching

Azure Managed Redis supports KNN and vector range queries.

13. Approximate Nearest Neighbor Search

ANN, or approximate nearest neighbor search, attempts to find vectors that are very close to the query without necessarily exhaustively comparing every vector.

This can dramatically reduce search latency and computational requirements.

The trade-off is:

You may sacrifice some recall for significantly better performance.

HNSW is an example of an indexing strategy commonly used to enable efficient approximate nearest-neighbor searches.

14. Vector Index Configuration

When creating a vector index, think about the following characteristics:

1. Data structure

Will the vectors be stored in:

• Hashes?
• JSON documents?

2. Vector field

Which property contains the embedding?

For example:

embedding

3. Vector dimensions

The index must accommodate the dimensionality of the embeddings.

4. Distance metric

Choose the appropriate metric, such as:

COSINE
L2
IP

5. Index algorithm

Choose between:

FLAT
HNSW

6. Metadata fields

Determine which fields need to support filtering.

15. Example Conceptual Data Model

Consider a RAG application containing technical documentation.

A Redis record might conceptually look like:

document:1001
title:
"Azure Container Apps"
category:
"Containers"
source:
"https://example.com/container-apps"
tenant:
"Contoso"
embedding:
[0.012, -0.081, 0.224, ...]

The application can then:

1. Receive a user’s question.
2. Generate an embedding for the question.
3. Submit the query vector to Redis.
4. Search the vector index.
5. Retrieve the closest documents.
6. Apply metadata/security filtering.
7. Send the retrieved content to the LLM.
8. Generate a grounded response.

16. Vector Search and RAG

Vector indexing is especially important for Retrieval-Augmented Generation (RAG).

A typical RAG pipeline looks like this:

                DOCUMENT INGESTION
                       |
                       v
                 Split documents
                       |
                       v
                 Generate embeddings
                       |
                       v
             Store vectors + metadata
                       |
                       v
                Create vector index
                       |
                       |
             USER QUERY
                  |
                  v
           Generate query embedding
                  |
                  v
          Vector similarity search
                  |
                  v
          Apply metadata/security filters
                  |
                  v
             Retrieve top K
                  |
                  v
          Add retrieved context
                  |
                  v
                   LLM
                  |
                  v
              Final response

The vector database does not generate the final natural-language response.

Its role is primarily retrieval.

17. Why Metadata Filtering Is Important in RAG

Suppose a company has documents belonging to multiple departments:

HR
Finance
Engineering
Legal

A user asks:

“What is our reimbursement policy?”

A pure vector search could potentially retrieve semantically relevant documents from multiple departments.

Instead, the application can use metadata:

department = "Finance"

or, more importantly:

tenant_id = current_user.tenant_id

and possibly:

access_level <= current_user.access_level

This helps ensure that retrieval is both relevant and appropriately scoped.

For RAG, metadata can also provide information needed to identify the source of retrieved content.

18. Hybrid Search

Vector search does not necessarily need to operate alone.

Azure Managed Redis can combine vector search with other search/filter capabilities, including:

• Numeric filters
• Text filters
• Geospatial filters
• Prefix matching
• Fuzzy matching
• Boolean conditions

This enables hybrid retrieval.

For example:

Find products semantically similar to this product, but only return products where category = 'laptop' and price < 1500.

The vector component handles semantic similarity while the metadata/filter component constrains the candidate results.

19. Choosing FLAT or HNSW

For the exam, think about the decision this way:

Choose FLAT when:

• The dataset is relatively small.
• Exact similarity results are important.
• Exhaustive comparison is acceptable.
• Search latency is less critical.

Choose HNSW when:

• The dataset is large.
• Low latency is important.
• Approximate results are acceptable.
• High-throughput vector search is required.

Do not assume that HNSW is always better. It is a trade-off.

20. Important Exam Considerations

When answering AI-200 questions involving Azure Managed Redis vector indexing, pay attention to these details.

RediSearch must be available

Vector search depends on the RediSearch functionality.

Vector indexing is different from ordinary Redis keys

A Redis key/value operation retrieves a known key. Vector indexing enables similarity-based retrieval.

HNSW is approximate

It is designed to improve search performance and reduce computation compared with exhaustive search.

FLAT is exhaustive

It compares the query against the indexed vectors rather than navigating an approximate graph.

Metadata is valuable

Metadata enables filtering and allows applications to associate retrieved vectors with meaningful application information.

Embedding compatibility matters

The query embedding and indexed embeddings need to be compatible with the index configuration.

Vector search is not generation

Redis retrieves relevant information. An LLM can subsequently use that information to generate a response in a RAG architecture.

21. Common Exam Traps

Trap 1: “HNSW always provides exact results”

Incorrect.

HNSW is an approximate nearest-neighbor approach.

Trap 2: “FLAT is always the best option”

Incorrect.

FLAT can become computationally expensive as the number of vectors increases.

Trap 3: “Vector search replaces metadata filtering”

Incorrect.

Vector similarity determines semantic closeness. Metadata filters can constrain the search to the appropriate subset.

Trap 4: “The vector database generates the answer”

Incorrect.

The vector database retrieves relevant information. An LLM can use that retrieved information to generate the final response.

Trap 5: “Any embedding can be searched against any vector index”

Incorrect.

The embedding dimensions, representation, and similarity configuration need to be compatible.

Trap 6: “RediSearch can always be enabled later”

Incorrect for Azure Managed Redis provisioning.

Current Azure Managed Redis guidance states that required modules such as RediSearch need to be enabled when the instance is created.

22. AI-200 Exam Takeaways

Remember these concepts:

Practice Exam Questions

Question 1

An AI application uses Azure Managed Redis to store 2 million document embeddings. The application requires very low-latency similarity searches and can tolerate a small reduction in recall in exchange for improved performance.

Which vector indexing strategy is most appropriate?

A. FLAT

B. HNSW

C. Hash-only retrieval

D. Key-based lookup

Answer: B

Explanation

HNSW is designed for approximate nearest-neighbor searches and is generally appropriate for larger datasets where low latency is important. It avoids exhaustive comparison with every vector and therefore can substantially reduce search work.

FLAT performs exhaustive searches and can become increasingly expensive as the number of vectors grows. A hash-only retrieval or normal key lookup cannot perform semantic vector similarity search.

Question 2

A development team has 5,000 product embeddings and requires exhaustive similarity comparisons because search accuracy is more important than minimizing computational cost.

Which indexing strategy should the team consider?

A. HNSW

B. FLAT

C. Boolean indexing

D. Prefix indexing

Answer: B

Explanation

FLAT performs an exhaustive comparison of the query vector against the indexed vectors. It is appropriate when the dataset is relatively small or when exhaustive accuracy is preferred.

HNSW is designed for approximate nearest-neighbor searches and trades some recall for performance.

Question 3

An application generates an embedding for a user’s question and wants to retrieve the five most semantically similar documents from Azure Managed Redis.

Which concept describes this operation?

A. Cache invalidation

B. Key-based lookup

C. K-nearest neighbors

D. Transaction processing

Answer: C

Explanation

K-nearest neighbors (KNN) retrieves the top K vectors that are closest to the query vector according to the configured similarity/distance metric.

With K = 5, the application requests the five nearest vectors.

Question 4

An organization stores document embeddings in Azure Managed Redis. Each document also contains a tenantId field. A RAG application must ensure that users retrieve documents only from their own tenant.

What is the primary purpose of the tenantId metadata?

A. Increasing the dimensionality of embeddings

B. Changing the embedding model

C. Replacing the vector index

D. Restricting vector retrieval to the appropriate tenant

Answer: D

Explanation

Metadata such as tenantId can be used to filter vector-search results so that retrieval is restricted to the appropriate tenant.

This is particularly important in multitenant AI and RAG applications where semantic similarity alone does not provide an authorization boundary.

Question 5

A team creates an Azure Managed Redis instance and later decides that it needs vector search. The instance was created without the required RediSearch functionality.

What should the team understand?

A. RediSearch must be enabled during instance provisioning

B. Vector search automatically becomes available when the first vector is stored

C. FLAT indexing eliminates the need for RediSearch

D. KNN automatically installs the required module

Answer: A

Explanation

Azure Managed Redis vector search requires RediSearch, and current Azure Managed Redis guidance states that the module must be enabled when the instance is created. Modules cannot simply be added to an existing instance afterward.

Question 6

An application uses text embeddings generated by an embedding model. Which consideration is most important when configuring the vector index?

A. The Redis key must contain the user’s password

B. The vector index must be compatible with the embedding dimensions and similarity configuration

C. Every embedding must be stored as plain text

D. The application must use FLAT regardless of dataset size

Answer: B

Explanation

The vector index needs to be configured consistently with the embeddings being generated. In particular, vector dimensions and the selected similarity metric need to be compatible with the embedding model and its vector representation.

Using an incompatible vector configuration can cause errors or poor search results.

Question 7

A RAG application retrieves documents from Azure Managed Redis using vector similarity search. What should happen after relevant documents are retrieved?

A. Redis automatically writes the final natural-language answer

B. The vector index generates a new embedding for every retrieved document

C. The retrieved content can be supplied to an LLM as grounding/context

D. The vectors are converted into relational database tables

Answer: C

Explanation

In a RAG architecture, vector search is the retrieval stage.

The application retrieves relevant content and supplies it as context to an LLM. The LLM then uses that context to generate the response.

The vector database does not itself generate the final natural-language answer.

Question 8

A team wants to find products semantically similar to a user’s query but only within the Laptops category.

Which approach best satisfies this requirement?

A. Perform only an exact key lookup

B. Delete all vectors outside the Laptops category

C. Use only the product title as the vector

D. Combine vector similarity search with a metadata filter

Answer: D

Explanation

Vector similarity identifies semantically similar products, while the metadata filter restricts results to the required category.

This is an example of combining vector retrieval with structured filtering.

Question 9

Which statement best describes the primary difference between FLAT and HNSW vector indexes?

A. FLAT performs exhaustive comparison, while HNSW uses an approximate graph-based approach

B. FLAT stores JSON while HNSW stores hashes

C. FLAT supports text only while HNSW supports vectors only

D. FLAT is used for metadata and HNSW is used for authentication

Answer: A

Explanation

The fundamental distinction is the search strategy.

FLAT performs exhaustive comparisons, while HNSW uses a graph-based approximate nearest-neighbor approach designed to improve search performance at scale.

The distinction is not based on whether the data is stored as hashes or JSON.

Question 10

An application uses Azure Managed Redis for vector similarity search. Which combination represents a valid vector-search design?

A. Store only Redis keys and perform exact string comparisons

B. Store embeddings, create a vector index, and query using a compatible similarity metric

C. Store embeddings only in application memory and use Redis for authentication

D. Store embeddings as passwords and use expiration to determine similarity

Answer: B

Explanation

A vector-search implementation requires embeddings to be stored, a compatible vector index to be created, and queries to use an appropriate similarity/distance configuration.

The other choices describe unrelated Redis capabilities and do not implement vector similarity search.

Final Exam Review

For “Implement vector indexing to enable similarity search”, the most important mental model is:

                 CONTENT
                    |
                    v
             Embedding model
                    |
                    v
              Vector embedding
                    |
                    v
       +-------------------------+
       |     Azure Managed       |
       |         Redis           |
       |                         |
       | Vector + metadata       |
       |         ↓               |
       |    Vector index         |
       |    /         \          |
       | FLAT          HNSW      |
       +-------------------------+
                    ^
                    |
             Query embedding
                    |
                    v
             Similarity search
                    |
                    v
              Top-K results
                    |
                    v
             RAG / Application

If you remember only a handful of things for the exam, remember these:

1. RediSearch provides vector-search capabilities in Azure Managed Redis.
2. FLAT = exhaustive/exact search.
3. HNSW = approximate nearest-neighbor search optimized for performance.
4. KNN returns the top K similar vectors.
5. Cosine, L2, and inner product are important similarity/distance metrics.
6. Vectors should be compatible with the embedding model and index configuration.
7. Store metadata alongside vectors when applications need filtering or source information.
8. Vector search retrieves information; an LLM can use that information for RAG generation.
9. Vector search requires appropriate Redis provisioning, including RediSearch and supported configuration.
10. The right index is determined by dataset size, latency requirements, accuracy/recall requirements, and resource considerations.

Go to the AI-200 Exam Prep Hub main page