AI-200 Data Management Services And Vector Search — Timed 100 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?

100 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)

Question 11

You are managing an Azure AI Search index with millions of high-dimensional vectors. Users experience intermittent timeout errors during peak query hours. Upon investigation, you find that the search service CPU utilization is at 100%. What is the most effective architectural mitigation?

Accepted Answer

Scale out the search service by adding search units (replicas). CPU saturation at 100% during peak query hours on a vector-heavy index is a capacity problem, and the correct architectural fix is to add replicas (scale out). Replicas host additional copies of the index and serve queries in parallel, distributing the query load and directly relieving CPU pressure. Adding replicas also improves query throughput and high-availability SLA, making it the standard mitigation for query-time saturation.

Answer

Increase the embedding dimension size from 1536 to 3072

Answer

Switch the index from HNSW to exhaustive k-NN search

Answer

Decrease the number of replicas to reduce network chatter

Question 12

You are migrating a large vector dataset into an Azure AI Search index. To maximize ingestion speed and throughput, you temporarily adjust index settings. Which index configuration property should you modify during bulk ingestion?

Accepted Answer

Scale out search units (replicas and partitions) to distribute ingestion load. In Azure AI Search, ingestion throughput is primarily bounded by the number of search units, which are composed of replicas and partitions. Scaling out replicas and partitions distributes the indexing load and increases the resources available for document processing, so option B is correct. This is the recommended temporary adjustment during bulk ingestion, after which you can scale back down.

Answer

Set HNSW efConstruction to 10,000 to maximize graph build precision

Answer

Disable all scoring profiles and set vector dimensions to 1

Answer

Switch the index tier from Standard to Free

Question 13

When configuring vector search in Azure Cosmos DB for NoSQL, which TWO data types are valid for storing vector embeddings within the vector embedding policy? (Choose two)

Accepted Answer

float32. Azure Cosmos DB for NoSQL's vector embedding policy explicitly supports float32 as a vector data type, storing each dimension as a 32-bit floating-point value, which is the most common and precise format for embeddings. Option E (float16) is also correct because the vector embedding policy supports float16 as a lower-precision, memory-efficient alternative for storing embeddings, reducing storage and RU costs while maintaining acceptable recall. The remaining options are not valid vector data types in the policy: boolean (A) stores true/false values, guid (C) stores globally unique identifiers, and string (D) stores text — none of which represent numeric vector arrays. Only float32 and float16 are accepted as the dataType in the vector embedding policy for Cosmos DB for NoSQL.

Answer

boolean

Answer

guid

Answer

string

Question 14

When configuring an Azure AI Search index, which TWO data types can be used for metadata fields that require exact filtering (e.g., category eq 'electronics')? (Choose two)

Accepted Answer

Edm.Int32 (with filterable: true). Option C (Edm.Int32 with filterable: true) is correct because numeric fields such as Edm.Int32 support OData $filter expressions like category eq 5, and setting filterable: true makes the field usable in exact-match filter queries. Option E (Edm.String with filterable: true) is correct because string fields marked filterable: true allow exact equality comparisons such as category eq 'electronics' in Azure AI Search. Option A (Binary stream objects) is incorrect because binary fields are used for storing encoded documents or images and are not filterable for exact metadata matching. Option B (Edm.ComplexType without sub-properties) is incorrect because complex types are not filterable as a whole and require filterable sub-fields to be queried. Option D (Edm.SingleCollection vector fields) is incorrect because vector fields are used for similarity search and are not filterable for exact equality predicates.

Answer

Binary stream objects

Answer

Edm.ComplexType without sub-properties

Answer

Edm.SingleCollection (vector fields)

Question 15

When configuring an Azure AI Search index, which TWO field attributes are required if a field is going to be used for full-text keyword search and filtering? (Choose two)

Accepted Answer

searchable. Option A (searchable) is correct because the searchable attribute must be set to true for a field to be included in full-text keyword search queries processed by the Lucene analyzer; without it, the field is ignored by the inverted index used for keyword matching. Option D (filterable) is correct because the filterable attribute must be enabled for a field to be referenced in OData $filter expressions, which is how Azure AI Search applies filtering on index fields. Option B (vectorSearchProfile) is incorrect because it only assigns a vector search configuration for vector (similarity) queries and is unrelated to keyword search or filtering. Option C (facetable) is incorrect because it only enables the field to be used in faceted navigation via facet counts, not for keyword search or filtering. Option E (sortable) is incorrect because it only allows the field to be used in $orderby clauses, which is a separate capability from full-text search and filtering.

Answer

vectorSearchProfile

Answer

facetable

Answer

sortable

Question 16

Which Azure portal blade allows you to view and manage access keys and connection strings for an Azure AI Search service?

Accepted Answer

Keys. The Keys blade in the Azure portal for an Azure AI Search service is where the two admin keys (primary and secondary) and any query keys are displayed, regenerated, and copied, along with the service endpoint used to build connection strings. This is the standard location for retrieving the credentials needed by SDK clients, REST calls, and indexer data source connections. It is also where you can switch between key-based and role-based access control.

Answer

Data source

Answer

Certificates

Answer

Scale

Question 17

When configuring vector search in Azure AI Search, which TWO compression options or algorithm settings can be defined to optimize resource usage? (Choose two)

Accepted Answer

Scalar quantization configuration. Scalar quantization configuration (A) is correct because it is a vector compression method in Azure AI Search that reduces each vector component from a 32-bit float to a smaller integer type (e.g., int8), cutting memory and disk usage for vector indexes while preserving searchable data. HNSW algorithm parameters such as m and efConstruction (B) are also correct because they directly control the Hierarchical Navigable Small World graph's connectivity and index-build effort, letting you tune index size, memory footprint, and query latency for resource optimization. Blob storage container access level (C) is unrelated, as it governs anonymous read access to blob data, not vector index compression or algorithm behavior. SQL table partitioning scheme (D) applies to relational database storage distribution and has no role in Azure AI Search vector configuration. Cosmos DB throughput auto-scale limits (E) concern RU/s provisioning for Cosmos DB, which is a separate service and not a vector compression or algorithm setting in Azure AI Search.

Answer

Blob storage container access level

Answer

SQL table partitioning scheme

Answer

Cosmos DB throughput auto-scale limits

Question 18

You are writing a query in Azure Cosmos DB for NoSQL to calculate the vector distance between a stored embedding and a query vector. You want to retrieve only the top 5 most similar documents. What is the correct structure of the LIMIT or TOP clause?

Accepted Answer

SELECT TOP 5 c.id, VectorDistance(c.vector, [0.1, 0.2, ...]) AS score FROM c ORDER BY VectorDistance(c.vector, [0.1, 0.2, ...]). Cosmos DB for NoSQL uses the standard SQL TOP clause combined with ORDER BY VectorDistance(...) to return the nearest neighbors. Option D correctly projects the VectorDistance score as an alias, applies TOP 5, and orders by the same distance function, which is the documented pattern for vector similarity search.

Answer

SELECT LIMIT 5 c.id FROM c ORDER BY c.vector

Answer

SELECT c.id FROM c SORT BY VectorDistance LIMIT 5

Answer

SELECT c.id FROM c WHERE VectorDistance(c.vector, [...]) < 5

Question 19

Which property in an Azure Cosmos DB for NoSQL vector embedding policy defines whether the similarity calculation measures cosine, dotproduct, or euclidean distance?

Accepted Answer

distanceFunction. The distanceFunction property in a Cosmos DB vector embedding policy specifies the similarity metric — cosine, dotproduct, or euclidean — used to compare stored vectors against query vectors. It must be declared when the container is created and must match the metric used by the query's VectorDistance function.

Answer

metricType

Answer

algorithmFunction

Answer

similarityMetric

Question 20

You are designing an enterprise RAG application that stores vector embeddings in Azure AI Search. You want to ensure that if the primary Azure region goes down, your search service automatically fails over with minimal data loss. How should you design your geo-replication strategy?

Accepted Answer

Configure geo-replication with replica services in a paired Azure region, enabling read-only failover and re-indexing capabilities. Azure AI Search supports geo-replication by allowing you to create replica services in a paired Azure region. These replicas are read-only and can be promoted to read-write during a failover. This design ensures high availability with minimal data loss because the replicas are continuously synchronized with the primary service, and you can re-index if needed. The other options do not provide automatic failover or are not feasible within Azure AI Search's capabilities.

Answer

Export search indexes to CSV files hourly and upload them manually

Answer

Rely on Azure Blob Storage geo-redundancy to automatically mirror search index memory

Answer

Configure synchronous multi-region write master locks across 10 regions simultaneously