AI-200 Data Management Services And Vector Search Practice Test 8 — 15 Questions

Question 1

You are configuring an Azure AI Search vector index for a retrieval-augmented generation (RAG) application. You need to select an algorithm for vector similarity search that balances recall speed with accuracy while allowing approximate nearest neighbor (ANN) search. Which vector search algorithm configuration should you select?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Hierarchical Navigable Small World (hnsw). Hierarchical Navigable Small World (hnsw) is the correct algorithm because it provides approximate nearest neighbor search with a tunable balance between recall and latency, using a multi-layer graph that enables fast traversal. Azure AI Search supports hnsw as a vector search algorithm configuration, and it is the recommended choice for RAG workloads that need low-latency, high-recall retrieval over large vector indexes. It directly satisfies the requirement for ANN with balanced speed and accuracy.

Answer

Exhaustive K-Nearest Neighbor (exhaustiveKnn)

Answer

Locality-Sensitive Hashing (lsh)

Answer

Inverted File with Product Quantization (ivf-pq)

Question 2

You are optimizing an enterprise search architecture using Azure AI Search. Which THREE mechanisms help control latency and resource consumption during heavy vector query loads? (Choose three)

Accepted Answer

Tuning HNSW efSearch parameter to balance recall speed and latency. Option A is correct because the HNSW efSearch parameter controls the size of the dynamic candidate list during vector search; lowering efSearch reduces the number of distance computations, cutting latency at some cost to recall, which is exactly the recall/latency trade-off needed under heavy vector query loads. Option C is correct because scalar quantization compresses float32 vectors into smaller representations (e.g., int8), reducing memory footprint and memory bandwidth pressure so more vectors fit in RAM and queries execute faster. Option E is correct because adding search replicas horizontally distributes query traffic across multiple nodes, increasing concurrent query throughput and preventing any single node from becoming a latency bottleneck. Option B is incorrect because disabling caching removes a latency-reducing mechanism and pushing documents per partition beyond limits is unsupported and degrades performance. Option D is incorrect because exhaustive k-NN scans every vector for each query, which dramatically increases compute and latency and is unsuitable as a default under heavy load.

Answer

Disabling caching and increasing index document count per partition beyond limits

Answer

Running exhaustive k-NN searches for every query by default

Question 3

You are designing a multi-tenant enterprise RAG system using Azure AI Search. Each tenant requires isolated document retrieval. Which feature should you implement to enforce data security while leveraging vector search?

Accepted Answer

Security trimming using OData filter expressions with vector queries. Security trimming with OData filter expressions applied alongside vector queries enforces per-tenant isolation at query time, ensuring each tenant only retrieves documents matching their tenant ID or security group. Azure AI Search supports combining vector search with OData $filter so the vector similarity search is constrained to the authorized document subset.

Answer

Role-Based Access Control (RBAC) at the index level

Answer

Dedicated search services per tenant without filters

Answer

Semantic ranker query throttling

Question 4

When storing vector embeddings in Azure Cosmos DB for MongoDB (vCore), which distance metric is natively supported when creating a vector search index?

Accepted Answer

Cosine distance (cos). Azure Cosmos DB for MongoDB (vCore) natively supports cosine distance when creating a vector index, specified as 'cos' in the index definition. Cosine distance measures the angle between vectors and is the standard metric for text embeddings, which are typically normalized. This makes it the correct native metric for vector search indexes in that service.

Answer

Levenshtein distance

Answer

Jaccard distance

Answer

Hamming distance

Question 5

You are integrating Azure OpenAI Service's text-embedding-ada-002 model with Azure AI Search. You want to automate the generation of embeddings directly inside the search service during data ingestion. Which component of Azure AI Search should you configure?

Accepted Answer

Azure AI Search Indexer with integrated vectorization. Azure AI Search's indexer with integrated vectorization natively invokes an embedding model (such as Azure OpenAI's text-embedding-ada-002) during the enrichment pipeline, so vectors are generated and written to the index automatically at ingestion time. This removes the need for external code to pre-compute embeddings and push them into the index. Configuring the indexer's vectorizer and embedding skill is the supported, first-party mechanism for this automation.

Answer

Semantic ranker configuration profile

Answer

Azure Function scheduled trigger for batch updates

Answer

Custom Web API skill in Azure AI Services enrichment pipeline

Question 6

You are configuring vector search on an Azure AI Search index using a custom vectorizer that points to an external embedding endpoint. Which authentication method is recommended and natively supported for securely connecting Azure AI Search to the Azure OpenAI endpoint?

Accepted Answer

Managed Identity (system-assigned or user-assigned). Managed Identity is the recommended and natively supported authentication method for Azure AI Search to securely connect to Azure OpenAI when using a custom vectorizer. It leverages Microsoft Entra ID to provide an identity for the search service, eliminating the need to manage credentials. The identity is automatically managed by Azure and can be granted permissions to the Azure OpenAI resource, ensuring secure access without storing secrets.

Answer

OAuth2 client credentials grant with Azure AD tenant federation

Answer

Shared Access Signature (SAS) tokens

Answer

Basic authentication with API keys stored in index metadata

Question 7

You are designing an application that stores vector embeddings in Azure SQL Database. Which data type should you use to store vector data natively in modern Azure SQL?

Accepted Answer

VECTOR native data type. Modern Azure SQL Database and SQL Server 2025 introduce a native VECTOR data type that stores float32 arrays with declared dimensions, enabling native vector functions like VECTOR_DISTANCE and integration with vector indexes. This is the correct native type for storing embeddings in Azure SQL.

Answer

VARCHAR(MAX) JSON string

Answer

FLOAT array collection

Answer

VARBINARY(MAX) blob

Question 8

You are querying an Azure Cosmos DB for NoSQL container using vector search. You execute a query using the VectorDistance() system function. Which query structure is required to properly execute this vector search?

Accepted Answer

SELECT TOP 10 c.id, VectorDistance(c.vectorProp, [0.1, 0.2]) AS score FROM c ORDER BY VectorDistance(c.vectorProp, [0.1, 0.2]). Cosmos DB for NoSQL vector search requires the VectorDistance() function to be used in both the SELECT clause (to return the score) and the ORDER BY clause (to rank results). The query must also use TOP N to limit results, as vector search in Cosmos DB requires a top-k pattern. This structure allows the query engine to use the vector index for efficient nearest-neighbor search.

Answer

SELECT TOP 10 c.id FROM c WHERE VectorDistance(c.vectorProp, [0.1, 0.2]) > 0.9

Answer

JOIN vectorIndex ON c.id = vectorIndex.id

Answer

GROUP BY VectorDistance(c.vectorProp, [0.1, 0.2])

Question 9

You are designing a data architecture on Azure where embeddings are generated offline by an Azure Databricks pipeline and stored in Azure AI Search. You want to minimize ingestion latency and optimize throughput when uploading millions of pre-computed vectors. Which client library API pattern should you use?

Accepted Answer

Use SearchClient batch upload APIs with up to 1000 documents per batch. The Azure AI Search SDK's SearchClient supports batch indexing via IndexDocumentsBatch or the mergeOrUpload/upload actions, and the service accepts up to 1000 documents (or ~16 MB) per batch request. Batching pre-computed vectors this way amortizes HTTP overhead and maximizes indexing throughput, which is exactly what you want when pushing millions of embeddings generated offline by Databricks. This is the documented, supported high-throughput ingestion pattern.

Answer

Stream vectors directly through the Azure AI Search integrated vectorizer skillset

Answer

Send documents one-by-one using synchronous CreateOrUpdate API calls

Answer

Execute direct SQL INSERT statements against the underlying search partition nodes

Question 10

You are implementing a multi-modal AI application that searches across both text descriptions and product images stored in Azure AI Search. Which feature allows you to query both modalities within a unified search index?

Accepted Answer

Multiple vector fields with distinct dimensions and vectorizers in a single index. Azure AI Search supports defining multiple vector fields in a single index, each with its own dimensions and vectorizer, so text embeddings (e.g., 1536-dim from text-embedding-ada-002) and image embeddings (e.g., 512-dim from a CLIP-style model) can coexist and be queried together. This enables unified multi-modal search where a query can target both text and image vector fields, with results merged via hybrid or RRF ranking.

Answer

Single-dimension global vector index restriction

Answer

Mandatory unification of text and image vectors into a single 1536-dimensional field

Answer

External fusion proxy service

Question 11

You are configuring an Azure AI Search vector index. Which TWO parameters are part of the HNSW algorithm configuration settings? Choose two.

Accepted Answer

efSearch. Option A, efSearch, is correct because it is the HNSW parameter that controls the size of the dynamic candidate list used during query time, trading off recall against latency in Azure AI Search vector search. Option B, m, is correct because it is the HNSW parameter specifying the number of bi-directional links created for each node in the graph, which affects index build time, memory, and search accuracy. The other options do not belong: maxTokenLength and shingleSize are text-analyzer settings used in custom analyzers for lexical indexing, not vector HNSW configuration, and clusterCount is not an HNSW parameter in Azure AI Search (it relates to partitioning or clustering concepts, not the HNSW graph settings).

Answer

maxTokenLength

Answer

clusterCount

Answer

shingleSize

Question 12

You are designing an enterprise search architecture that combines Azure AI Search and Azure OpenAI. Which THREE strategies help optimize hybrid search relevance and retrieval quality? Choose three.

Accepted Answer

Tune HNSW parameters (m and efSearch) based on recall and latency trade-offs. Option A is correct because HNSW parameters directly control the approximate nearest neighbor graph: increasing m improves recall at the cost of memory and index build time, while efSearch tunes the query-time candidate list to balance recall against latency, making it a core lever for hybrid search relevance. Option B is correct because Reciprocal Rank Fusion (RRF) merges the ranked result lists from keyword (BM25) and vector queries into a single ranking using 1/(k + rank) scoring, which is exactly how Azure AI Search combines lexical and vector results in hybrid mode. Option C is correct because the semantic ranker applies deep-learning re-ranking (Microsoft's cross-encoder models) over the top results, promoting semantically relevant documents that lexical or vector scores alone may rank lower. Option D is not correct because disabling OData filters does not improve vector recall and removes useful precision controls; filters are applied alongside vector search to narrow the candidate set. Option E is not correct because storing embeddings as uncompressed plaintext in Blob Storage is inefficient and unrelated to search relevance; embeddings should be stored in the search index as Collection(Edm.Single) vectors, ideally with compression such as scalar or binary quantization.

Answer

Disable all OData filters to maximize vector recall

Answer

Store all embeddings as uncompressed plaintext strings in Blob Storage

Question 13

You are optimizing query performance for an Azure AI Search index experiencing high query volumes with vector search. You need to scale out query processing capabilities without increasing index build time. Which action should you perform?

Accepted Answer

Increase the number of search units by adding replica instances. In Azure AI Search, query processing capacity is scaled by adding replicas (search units), not partitions. Replicas host copies of the index and serve queries in parallel, so adding replicas increases query throughput without affecting index build time. Partitions, by contrast, affect index size and write/indexing throughput, so increasing them would lengthen index build time.

Answer

Rebuild the index using exhaustiveKnn

Answer

Increase the number of partition instances

Answer

Upgrade the search service from Standard to Basic tier

Question 14

When configuring vector search in Azure Cosmos DB for NoSQL, which TWO properties must be defined within the container's vector embedding policy? Choose two.

Accepted Answer

Path (the JSON property containing the vector array). Option D is correct because the vector embedding policy must specify the "path" — the JSON property path in each document that holds the vector array — so Cosmos DB knows which field to index for vector search. Option E is correct because the policy must also declare the vector's "dataType" (e.g., float32, float16, int8) and "dimensions" (e.g., 1536), which define the element type and length of the vector array and must match the actual embeddings. The container partition key definition (A) is set in the container's key definition, not the vector embedding policy, and is unrelated to vector indexing. BM25 k1 and b parameters (B) belong to full-text search scoring configuration, not vector search. Replication lag threshold (C) is a consistency/global replication setting and has no place in a vector embedding policy.

Answer

Container partition key definition

Answer

BM25 k1 and b tuning parameters

Answer

Replication lag threshold

Question 15

You are troubleshooting slow query performance in an enterprise Azure AI Search vector deployment. Which THREE architectural or configuration adjustments can improve query throughput and latency? Choose three.

Accepted Answer

Scale out the number of search service replicas. Option A is correct because adding replicas to an Azure AI Search service distributes query load across more nodes, directly increasing query throughput (QPS) and reducing per-query latency, since each replica holds a full copy of the index and can serve queries independently. Option C is correct because vector search is memory-intensive: the HNSW graph and vector indexes must reside in RAM, so deploying on Standard tier or higher (rather than Basic/Free, which have limited memory and no vector support at scale) ensures adequate RAM to avoid disk-bound traversal and throttling. Option D is correct because lowering the efSearch parameter reduces the size of the HNSW candidate list explored during query-time traversal, trading a small amount of recall for faster search and lower latency, which is a standard tuning lever for throughput-sensitive vector workloads. Option B is not correct because ASCII folding tokenizers apply to text/lexical fields, not vector fields, and cannot replace vector embeddings or improve vector similarity search. Option E is not correct because exhaustive KNN scans the entire vector space and is far slower than HNSW approximate search, making it unsuitable for high-QPS production workloads.

Answer

Replace all vector fields with standard ASCII folding tokenizers

Answer

Configure the index to use exhaustive KNN exclusively for high-QPS production workloads