AI-200 Data Management Services And Vector Search — Timed 10 Questions

Question 1

You are optimizing an Azure AI Search vector index with millions of documents. Users report high latency during vector queries. You decide to implement vector compression to reduce memory footprint and improve search throughput. Which compression method is natively supported in Azure AI Search?

10 minute time limit — choose an answer to begin.

Accepted Answer

Scalar Quantization (SQ). Azure AI Search natively supports Scalar Quantization (SQ) as a vector compression method, which reduces float32 vectors to int8, cutting memory footprint by roughly 4x with minimal recall loss. It is configured via a compression configuration referenced by the vector profile, and the field must be typed Edm.ByteCollection (or use the built-in rescoring/oversampling options) to store the quantized values.

Answer

Autoencoders

Answer

Principal Component Analysis (PCA)

Answer

Product Quantization (PQ)

Question 2

You are developing a retrieval-augmented generation (RAG) solution using Azure AI Search. You need to configure a vector index to store 1536-dimensional embeddings generated by text-embedding-ada-002. Which parameter must you configure in the vector profile's algorithm configuration to use HNSW as the underlying approximate nearest neighbor algorithm?

Accepted Answer

algorithm.name set to hnsw. In Azure AI Search, the HNSW approximate nearest neighbor algorithm is selected by naming the algorithm configuration 'hnsw' in the vector profile's algorithm configuration. The vector profile references an algorithm configuration by name, and setting algorithm.name to 'hnsw' tells the search service to use the Hierarchical Navigable Small World graph for ANN search. This is the documented, supported value for enabling HNSW-based vector search.

Answer

algorithm.name set to exhaustiveKnn

Answer

vectorSearch.compression set to scalarQuantization

Answer

vectorSearch.algorithm.type set to faiss

Question 3

You are configuring a vector search profile in Azure AI Search. Which TWO parameters are required when defining an algorithm configuration using the HNSW algorithm? (Choose two)

Accepted Answer

efConstruction. When defining an HNSW algorithm configuration in Azure AI Search, the two required tuning parameters are efConstruction (option B) and m (option C). efConstruction sets the size of the dynamic candidate list during index construction, controlling the recall/quality versus build-time tradeoff, and it is a mandatory parameter of the HNSW parameters object. m specifies the number of bi-directional links created for each node in the HNSW graph, directly governing graph connectivity and recall, and it is likewise required. The other options do not belong: vectorDimensions (A) is a property of the vector field definition, not the HNSW algorithm configuration; compressionType (D) relates to vector compression/quantization settings rather than HNSW parameters; and shardCount (E) is a scaling/index-partition setting, not an HNSW algorithm parameter.

Answer

vectorDimensions

Answer

compressionType

Answer

shardCount

Question 4

You are managing an Azure AI Search index that uses integrated vectorization with Azure OpenAI. When a user sends a query string, you want Azure AI Search to automatically vectorize the query text before performing the vector search. Which feature must you configure in the index schema?

Accepted Answer

A custom Web API skillset. Integrated vectorization in Azure AI Search uses a vectorizer configuration connected to Azure OpenAI to automatically convert plain text queries into vector embeddings.

Answer

A cognitive services attachment on the storage account

Answer

An Azure Logic App trigger

Question 5

You are designing a multi-tenant AI application using Azure Cosmos DB for NoSQL. Each tenant has their own set of embeddings, and you need to filter vector search results strictly by tenantId while maintaining high query performance. How should you structure your vector index definition?

Accepted Answer

Include tenantId in the container's standard indexing policy with a range index, and filter using a WHERE clause alongside ORDER BY VectorDistance(). For multi-tenant vector search in Cosmos DB for NoSQL, you should include tenantId in the container's standard indexing policy with a range index and filter using a WHERE clause alongside ORDER BY VectorDistance(). Cosmos DB can combine a scalar filter (tenantId) with the vector search, ensuring results are scoped to the tenant while still using the vector index for similarity ranking. This maintains performance and isolation without duplicating containers.

Answer

Store tenantId inside the vector array as the first element

Answer

Use spatial indexes on tenantId

Answer

Create a separate container for every tenant automatically

Question 6

When querying an Azure AI Search vector index using the REST API or SDK, what parameter specifies the number of nearest neighbors to retrieve?

Accepted Answer

k. In Azure AI Search vector queries, the 'k' parameter (exposed as 'k' in the REST API and 'kNearestNeighborsCount' in some SDKs) specifies how many nearest neighbors to return from the vector index. It is the standard k-NN parameter name inherited from vector search literature. Setting k controls the size of the candidate set returned by the ANN algorithm.

Answer

radius

Answer

top

Answer

depth

Question 7

You are building a multi-modal AI application that searches across both product images and product descriptions. You store your data in Azure AI Search. How should you define your index schema to support searching with both image embeddings and text embeddings?

Accepted Answer

Define two separate Edm.SingleCollection vector fields with distinct dimensions and vector profiles. Azure AI Search requires each vector field to declare its own dimensions and be associated with a vector profile that references an HNSW or exhaustive KNN algorithm configuration. Because image embeddings (e.g., from Azure AI Vision) and text embeddings (e.g., from Azure OpenAI) typically have different dimensions and may use different algorithms, the correct design is two separate Edm.SingleCollection vector fields, each with its own dimensions and vector profile. This allows independent vector queries and hybrid ranking across both modalities.

Answer

Concatenate the image and text embeddings into a single 3072-dimensional vector field

Answer

Use a single Edm.String field containing both embeddings as JSON strings

Answer

Create two completely separate search services

Question 8

You are troubleshooting a slow vector query performance issue in Azure Cosmos DB for NoSQL. Which THREE actions can you take to improve vector search execution times? (Choose three)

Accepted Answer

Use the diskANN indexing type instead of flat indexes for large collections. Option A is correct because diskANN is the approximate nearest neighbor (ANN) index type in Cosmos DB for NoSQL designed for large-scale vector search; it dramatically reduces latency and RU cost compared to flat (exact, brute-force) indexes, which scan every vector. Option B is correct because effective partition key choice spreads vector data and query load across physical partitions, enabling parallel execution and avoiding hot partitions that throttle vector query throughput. Option E is correct because applying filter conditions (e.g., WHERE on scalar properties) narrows the candidate set before vector distance ranking, so fewer vectors are compared and execution time drops. Option C is not correct because base64 encoding is merely a serialization format for storing vectors; it does not improve search execution time and can add conversion overhead. Option D is not correct because disabling all non-vector indexing policies removes indexes that support the filters and predicates used to pre-filter vector queries, which typically degrades rather than improves performance.

Answer

Convert all vector embeddings to base64 string format

Answer

Disable all non-vector indexing policies on the container

Question 9

You are planning the disaster recovery and high availability strategy for an Azure AI Search service storing critical vector indexes for an AI assistant. Which THREE practices should you implement? (Choose three)

Accepted Answer

Configure at least two replicas for high availability during service updates. Option A is correct because configuring at least two replicas ensures the search service remains available during service updates and provides query redundancy; Azure AI Search requires two or more replicas for high availability SLA during updates. Option B is correct because geo-replication (available for services created with the newer architecture) lets you create a secondary search service in a paired region and sync data for cross-region disaster recovery and read access. Option D is correct because deploying search units across Azure Availability Zones (where supported) protects against zone-level failures and improves availability within a region. Option C is incorrect because storing vector embeddings as flat text files in local VM temp storage is not durable, not part of Azure AI Search's managed index, and temp storage is ephemeral. Option E is incorrect because the Free tier has no SLA, limited storage/index capacity, and no automated backups, so it cannot support a critical disaster recovery strategy.

Answer

Store all vector embeddings as flat text files in local VM temp storage

Answer

Rely solely on the Free tier with automated backups

Question 10

When designing an AI architecture that uses Azure AI Search, which TWO methods can be used to ingest documents and their vector embeddings into the search index? (Choose two)

Accepted Answer

Push API using HTTP POST requests to upload documents directly. Option C is correct because Azure AI Search exposes a REST push API where you send HTTP POST requests (for example to /indexes/{index}/docs/index) containing JSON documents that include both the content fields and the vector fields, allowing you to upload documents and their embeddings directly into the index. Option E is correct because Azure AI Search indexers can connect to supported data sources (such as Azure Blob Storage, Azure SQL Database, or Cosmos DB) and, with integrated vectorization, automatically chunk, embed, and load documents and their vectors into the index. Option A is incorrect because Azure AI Search does not expose its index as a mountable NFS share; indexes are accessed via the REST API or SDKs, not a filesystem. Option B is incorrect because there is no FTP interface into the search engine's storage directory; ingestion happens through the API or indexers. Option D is incorrect because you cannot restore a SQL Server .bak file directly into an Azure AI Search index; that is a database restore operation, not a search ingestion method.

Answer

Direct mounting of an NFS network share as the search index

Answer

FTP file transfer into the search engine storage directory

Answer

Direct SQL Server backup restore (.bak file import)