CCNA Data Management Services And Vector Search Questions — Page 2 of 2

Multi-Selectmedium

When configuring an Azure AI Search vectorizer for integrated vectorization, which TWO parameters or connections must be specified to link to an Azure OpenAI deployment? (Choose two)

Select 2 answers

A.Model name (e.g., text-embedding-ada-002)

B.SQL Server connection string

C.Cosmos DB container database name

D.Blob storage SAS token expiration time

E.Resource URL and authentication credentials (or managed identity)

AnswersA, E

The vectorizer must know which embedding model to invoke, so the deployment's model name is supplied in the vectorizer definition; Azure AI Search sends the query text to that model to generate the search vector.

Why this answer

Option A is correct because an Azure AI Search vectorizer that targets Azure OpenAI must specify the embedding model name (for example, text-embedding-ada-002 or text-embedding-3-large) so the service knows which deployed model to invoke for generating vectors. Option E is correct because the vectorizer also requires the Azure OpenAI resource endpoint URL plus authentication details — either an API key or a managed identity — to authorize calls to that deployment. Options B, C, and D are incorrect because SQL Server connection strings, Cosmos DB container database names, and Blob storage SAS token expiration times are unrelated to linking a vectorizer to an Azure OpenAI embedding deployment; they pertain to other data sources or storage access scenarios.

Exam trap

AI-200 often tests the confusion between data source connection details (SQL, Cosmos, Blob) and vectorizer configuration, which only needs the model name and the OpenAI endpoint plus credentials.

Practice this question →

MCQeasy

Which similarity metric measures the cosine of the angle between two vectors, focusing on orientation rather than magnitude, and is commonly used in Azure AI Search?

A.cosine

B.manhattan

C.euclidean

D.dotProduct

AnswerA

Cosine similarity computes the cosine of the angle between two vectors, measuring directional orientation and ignoring magnitude. This makes it suited to Azure AI Search vector queries, where document and query embeddings are compared by semantic direction rather than vector length.

Why this answer

Cosine similarity measures the cosine of the angle between two vectors, which captures their orientation (direction) while ignoring their magnitude. This makes it ideal for comparing text embeddings of different lengths, and it is the default and most commonly used similarity metric in Azure AI Search vector profiles. The option 'cosine' directly names this metric.

Exam trap

AI-200 often tests the confusion between cosine and dotProduct — candidates must remember that cosine explicitly normalizes by magnitude, while dotProduct does not, even though the two are mathematically related.

How to eliminate wrong answers

Option B is wrong because Manhattan (L1) distance sums the absolute differences of vector components — it measures magnitude-sensitive distance, not angular orientation. Option C is wrong because Euclidean (L2) distance measures straight-line distance between points, which is affected by vector magnitude and is not orientation-focused. Option D is wrong because dotProduct computes the sum of element-wise products; while related to cosine (cosine = dotProduct / (||a||·||b||)), it is a distinct metric that is sensitive to magnitude and is not the one described as measuring the cosine of the angle.

Practice this question →

MCQmedium

You are building an AI search solution using Azure AI Search. You want to ensure that users searching for acronyms or synonyms receive relevant results even if the exact keyword does not appear in the document. Which feature should you configure?

A.Synonym maps

B.Scoring profiles

C.Semantic ranker

D.Vector profiles

AnswerA

Synonym maps expand a query term to equivalent terms at query time, so acronyms and synonyms match documents lacking the exact keyword. They are defined per index and applied to searchable fields, directly delivering the recall improvement described.

Why this answer

Synonym maps in Azure AI Search let you define equivalence rules so that a query term expands to its synonyms or acronym expansions at query time. This ensures documents containing the full term are returned even when the user searches with an acronym, and vice versa. Synonym maps are applied per-field and are the correct feature for handling acronyms and synonyms.

Exam trap

AI-200 often tests the confusion between query-time lexical features (synonym maps) and ranking features (scoring profiles, semantic ranker), luring candidates toward semantic ranker when the requirement is term expansion.

How to eliminate wrong answers

Option B is wrong because scoring profiles adjust the ranking of already-matched documents based on field weights or functions; they do not expand the query to match terms that are absent from the document. Option C is wrong because the semantic ranker re-ranks results using language understanding but does not perform synonym expansion for terms not present in the index. Option D is wrong because vector profiles configure HNSW parameters for vector fields and have nothing to do with lexical synonym matching.

Practice this question →

MCQeasy

Which REST API HTTP method is used to create or update an index definition in Azure AI Search?

A.GET

B.PUT

C.PATCH

D.DELETE

AnswerB

PUT is idempotent, so repeated calls create or fully replace the index definition at the specified URI without duplicating resources. POST would create a new index each time, failing the create-or-update requirement, while PATCH performs partial updates only.

Why this answer

Azure AI Search exposes index definitions through its REST API at /indexes/{indexName}, and creating or replacing an index definition uses HTTP PUT. PUT is idempotent and replaces the entire index definition, which is the documented method for creating or updating an index. GET retrieves, PATCH is not supported for index definitions, and DELETE removes the index.

Exam trap

AI-200 often tests whether candidates assume PATCH is available for partial index updates, when Azure AI Search requires PUT with the complete definition.

How to eliminate wrong answers

Option A is wrong because GET only retrieves an existing index definition and cannot create or update one. Option C is wrong because Azure AI Search does not support PATCH for index definitions; partial updates are not available via PATCH on the indexes endpoint. Option D is wrong because DELETE removes an index and does not create or update it.

Practice this question →

MCQmedium

You are implementing a RAG solution where user queries are matched against an Azure AI Search vector index. You want to ensure that search results only return documents where a specific metadata field 'securityLevel' matches the user's clearance. How should you apply this filter?

A.Pass an OData filter expression in the 'filter' parameter of the search query request

B.Create a separate Azure AI Search service for each security level

C.Encode the security level into the vector embedding values directly

D.Filter the results in application memory after receiving all 1000 documents

AnswerA

The OData filter expression is evaluated against the index's filterable fields, restricting the candidate set to documents whose securityLevel matches the user's clearance before results are returned. This enforces per-user authorisation at query time without altering the vector similarity computation.

Why this answer

Passing an OData filter expression in the 'filter' parameter of the search query request is the correct way to restrict results by metadata such as securityLevel. Azure AI Search supports OData filter syntax on filterable fields, and the filter is applied alongside vector search to return only documents matching the predicate. This enforces security trimming at query time without duplicating services or embedding metadata into vectors.

Exam trap

AI-200 often tests the misconception that security filtering should be done in application code or by embedding metadata in vectors, when the correct approach is server-side OData filtering on filterable fields.

How to eliminate wrong answers

Option B is wrong because creating a separate search service per security level is costly, operationally complex, and does not scale; it also duplicates indexes and data unnecessarily. Option C is wrong because encoding security level into vector embedding values is not a reliable filtering mechanism; embeddings are semantic representations, and you cannot deterministically filter on embedded metadata values, nor does it enforce access control. Option D is wrong because filtering in application memory after retrieving all 1000 documents is inefficient, exposes unauthorized documents to the application, and does not scale; it also defeats the purpose of server-side filtering and can leak data.

Practice this question →

MCQhard

You are configuring a vector index in Azure AI Search and want to apply scalar quantization to reduce the memory footprint. What is the primary effect of scalar quantization on float32 vector data?

A.It increases vector dimensions from 1536 to 3072 to improve accuracy

B.It eliminates the need for an HNSW graph structure

C.It converts vectors into plain text strings for keyword indexing

D.It compresses float32 vectors to int8 integers, reducing memory usage by approximately 75%

AnswerD

Scalar quantization maps each float32 component to an int8 value, cutting storage from 32 bits to 8 bits per dimension. That four-to-one reduction lowers vector memory footprint by roughly 75%, while retaining the original vectors for rescoring.

Why this answer

Scalar quantization in Azure AI Search compresses each float32 component of a vector into an 8-bit integer (int8), reducing storage from 4 bytes to 1 byte per dimension — roughly a 75% memory reduction. This allows larger vector indexes to fit in memory and lowers cost, with only a small recall degradation that is typically acceptable for most RAG workloads.

Exam trap

AI-200 often tests the misconception that quantization improves accuracy or changes the ANN algorithm — in reality it trades a small amount of recall for large memory savings while keeping the same HNSW structure.

How to eliminate wrong answers

Option A is wrong because quantization reduces precision, not increases dimensionality — increasing dimensions would increase memory, the opposite of the goal. Option B is wrong because scalar quantization is orthogonal to the HNSW graph; HNSW is still used as the approximate nearest neighbor algorithm, and quantized vectors are stored in the graph nodes. Option C is wrong because quantization keeps vectors as numeric arrays; converting to text would defeat vector similarity search entirely and is not what quantization does.

Practice this question →

MCQhard

You are configuring a Vector Index in Azure AI Search. You need to ensure that the vector similarity search is performed using the Cosine distance metric. Where is this configuration specified?

A.In the indexer definition.

B.In the 'vectorSearch' section of the index definition.

C.In the search query payload.

D.In the field definitions within the index.

AnswerB

The vectorSearch object within the Azure AI Search index definition holds algorithm configurations, including the metric parameter where cosine is selected. Specifying it there binds the distance metric to the vector profile used by searchable vector fields.

Why this answer

In Azure AI Search, the vector search configuration, including the similarity metric such as cosine, dotProduct, or euclidean, is specified in the 'vectorSearch' section of the index definition. This section defines algorithms (like HNSW) and profiles that bind the metric to vector fields. The metric is set at the algorithm level and referenced by vector fields.

Exam trap

AI-200 often tests the misconception that the distance metric is set per query or per field, when it is actually defined in the vectorSearch algorithms section of the index.

How to eliminate wrong answers

Option A is wrong because the indexer definition controls data ingestion and field mappings, not vector similarity metrics. Option C is wrong because the search query payload specifies the query vector and parameters like k, but not the distance metric, which is fixed at index time. Option D is wrong because field definitions declare the vector field and its dimensions and profile reference, but the actual metric is defined in the vectorSearch algorithms section, not in the field itself.

Practice this question →

MCQhard

You are designing an Azure Cosmos DB for NoSQL container to store vector embeddings for a product recommendation engine. Queries will filter on category and then perform vector similarity search. You need to minimize latency and ensure the index supports both operations efficiently. Which indexing policy should you implement?

A.Exclude all paths except the vector property and create a vector index on it.

B.Include the category path in the range index and define a vector index on the embedding property.

C.Use only the default indexing policy, which automatically indexes all properties including vectors.

D.Create a composite index on category and the vector property.

AnswerB

Including the category path in the range index allows efficient filtering, and defining a vector index on the embedding property enables vector similarity search. This combination supports hybrid queries where the filter is applied first, reducing the candidate set for vector search, which minimizes latency and resource consumption. It is the recommended indexing strategy for filtered vector search in Cosmos DB for NoSQL.

Why this answer

For hybrid queries that filter on a scalar property and then perform vector search, the indexing policy must include the scalar property in the range index and define a vector index on the embedding property. This allows the query engine to apply the filter first, reducing the set of documents for vector comparison, which improves performance and lowers RU costs.

Exam trap

The trap here is assuming that indexing all properties by default also covers vector search, when vector indexes require explicit configuration.

Practice this question →

Multi-Selecthard

You are troubleshooting a scenario where hybrid queries in Azure AI Search are returning unexpected relevance rankings. Which THREE factors could influence the final score when using hybrid search with semantic ranking? (Choose three)

Select 3 answers

A.Virtual machine CPU core count assigned to the client application

B.Semantic ranker deep learning re-scoring

C.BM25 keyword match relevance scores

D.Reciprocal Rank Fusion (RRF) score combination weights

E.Azure Blob Storage container access tier (Hot vs Cool)

AnswersB, C, D

The semantic ranker applies deep learning re-scoring over the top results returned by the fused ranking, so its presence and configuration directly alter final relevance order. This re-scoring layer operates after RRF, meaning its model output can override the earlier lexical and vector ordering.

Why this answer

Option B is correct because in hybrid search with semantic ranking, the semantic ranker applies deep learning models to re-score the top results returned by the initial retrieval, directly influencing the final relevance ranking. Option C is correct because hybrid search combines keyword-based BM25 scoring with vector similarity, so the BM25 keyword match relevance scores contribute to the fused ranking. Option D is correct because Reciprocal Rank Fusion (RRF) is the algorithm Azure AI Search uses to merge keyword and vector result sets, and its rank-based combination determines the fused score that feeds into semantic re-ranking.

Option A is incorrect because the CPU core count of the client application has no bearing on how Azure AI Search computes relevance scores server-side. Option E is incorrect because Blob Storage access tiers affect storage cost and latency, not the relevance scoring pipeline of a search index.

Exam trap

AI-200 often tests the misconception that infrastructure factors like VM size or storage tier affect search relevance, when only BM25, RRF, and semantic ranking do.

Practice this question →

MCQmedium

You are developing a RAG solution and need to evaluate the quality of your vector retrieval results from Azure AI Search. Which metric is commonly used to measure the proportion of relevant documents retrieved in the top-k results?

A.HNSW efSearch latency

B.Request Units per second (RU/s)

C.BM25 term frequency

D.Recall@k

AnswerD

Recall@k measures the proportion of all relevant documents that appear within the top-k retrieved results, directly matching the stated evaluation goal. It differs from precision@k, which instead measures how many retrieved documents are relevant, so recall@k satisfies the retrieval-quality constraint.

Why this answer

Recall@k is the metric that measures the proportion of relevant documents retrieved in the top-k results. It is defined as the number of relevant documents retrieved in the top-k divided by the total number of relevant documents available. This metric is widely used in information retrieval and RAG evaluation to assess retrieval quality.

Exam trap

AI-200 often tests the distinction between retrieval quality metrics (like recall@k) and performance metrics (like latency or RU/s). Candidates might confuse recall@k with precision or other metrics, or mistakenly choose a performance-related option.

How to eliminate wrong answers

Option A is wrong because HNSW efSearch latency is a performance metric for the HNSW algorithm, not a retrieval quality metric. Option B is wrong because Request Units per second (RU/s) is a throughput metric for Cosmos DB, not for Azure AI Search. Option C is wrong because BM25 term frequency is a component of the BM25 ranking algorithm, not a metric for evaluating retrieval results.

Practice this question →

MCQeasy

When configuring an Azure Cosmos DB for NoSQL container to store embeddings, what data type must the vector property be stored as within the JSON document?

A.A base64 encoded string

B.An array of integers

C.An array of 32-bit floating-point numbers

D.A binary blob

AnswerC

Azure Cosmos DB for NoSQL stores vector embeddings as a JSON array of 32-bit floating-point numbers, matching the VectorDistance system function's expected input. This satisfies the stem's requirement that the vector property be a native JSON array, since Cosmos DB has no dedicated vector column type and rejects other numeric precisions.

Why this answer

Azure Cosmos DB for NoSQL stores vector embeddings as a JSON array of 32-bit floating-point numbers (float32), which is the format its native vector indexing and DiskANN-based similarity search expect. Each element represents one dimension of the embedding, and the container's vector policy declares dimensions and the float32 data type.

Exam trap

AI-200 often tests the misconception that embeddings can be stored as strings or integers, when Cosmos DB NoSQL requires a JSON array of float32 values matching the declared vector policy.

How to eliminate wrong answers

Option A is wrong because base64-encoded strings are not natively indexed or queried as vectors by Cosmos DB's vector search; they would require application-side decoding and cannot leverage the vector index. Option B is wrong because integer arrays lose the precision needed for embedding similarity — embeddings are inherently floating-point, and truncating to integers degrades recall. Option D is wrong because binary blobs are not a supported vector representation in the Cosmos DB NoSQL vector policy; the JSON document model requires an array of numbers.

Practice this question →

MCQeasy

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?

A.VARCHAR(MAX) JSON string

B.VECTOR native data type

C.FLOAT array collection

D.VARBINARY(MAX) blob

AnswerB

The VECTOR native data type stores embeddings directly in Azure SQL Database, satisfying the requirement for native vector storage. Unlike storing embeddings as JSON or VARBINARY, VECTOR enables efficient similarity searches and integrates with functions such as VECTOR_DISTANCE, avoiding manual serialisation and preserving dimensional semantics for AI workloads.

Why this answer

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.

Exam trap

The trap is that VARCHAR(MAX) JSON and VARBINARY(MAX) are technically capable of holding vector data, so candidates pick them as 'good enough' — but the question asks for the native type, which is VECTOR.

How to eliminate wrong answers

Option A is wrong because storing vectors as a VARCHAR(MAX) JSON string works but is not native — it requires parsing and cannot use native vector functions or indexes efficiently. Option C is wrong because 'FLOAT array collection' is not a valid Azure SQL data type; SQL Server has no array type. Option D is wrong because VARBINARY(MAX) stores raw bytes but provides no vector semantics, distance functions, or indexing — you'd have to implement everything manually.

Practice this question →

MCQmedium

You are building a RAG solution using Azure AI Search. Documents are updated frequently, and you need each document's vector embedding to be regenerated automatically whenever its text changes, without writing custom code to detect changes. Which Azure AI Search feature should you configure?

A.A synonym map that links text terms to their vector representations.

B.An indexer with a skillset that includes the Azure OpenAI Embedding skill.

C.A scoring profile that boosts documents with recently updated timestamps.

D.A custom Web API skill that calls Azure OpenAI directly and writes vectors to the index.

AnswerB

An indexer with an Azure OpenAI Embedding skill reads source documents, applies the embedding model, and writes vectors into the index. When combined with a change detection policy, it automatically reprocesses only changed documents, so embeddings stay current without custom code.

Why this answer

An indexer with the Azure OpenAI Embedding skill automatically chunks and vectorizes source content during indexing. When paired with a change detection policy (such as a high-water mark column or change tracking), only modified documents are reprocessed, keeping embeddings synchronized without custom code. This is the standard no-code approach for maintaining vector freshness in Azure AI Search.

Exam trap

The trap here is assuming that vector fields update automatically when source text changes, when in fact an indexer and change detection policy must be configured to regenerate embeddings.

Practice this question →

MCQhard

You are designing a data layer architecture in Azure Cosmos DB for NoSQL for an AI application that performs high-frequency writes and real-time vector searches. You need to understand how vector indexing impacts write operations. What is the primary trade-off?

A.Vector properties cannot be updated after initial document creation

B.Writes are completely blocked until the vector index reaches 100% synchronization

C.Writing documents consumes more Request Units (RUs) because vector indexes must be updated

D.Writes require explicit distributed transactions across regions

AnswerC

Vector indexes must be updated on every insert, and each index write consumes additional Request Units beyond the document write itself. This directly satisfies the high-frequency write constraint: indexing overhead raises RU cost per operation, so write throughput is limited by provisioned RU budget.

Why this answer

Writing documents consumes more Request Units (RUs) because vector indexes must be updated on every write. In Azure Cosmos DB for NoSQL, vector indexing adds overhead to write operations since the index must be maintained as documents are inserted or updated. This is the primary trade-off: faster vector search at the cost of higher write RU consumption.

Exam trap

AI-200 often tests the misconception that vector indexing blocks writes or requires special transactions, when the real trade-off is increased RU consumption for index maintenance.

How to eliminate wrong answers

Option A is wrong because vector properties can be updated after document creation; Cosmos DB supports updating vector fields, and the index is updated accordingly, so this is not a limitation. Option B is wrong because writes are not completely blocked until the vector index reaches 100% synchronization; Cosmos DB uses eventual consistency for indexing, and writes proceed while indexing occurs asynchronously. Option D is wrong because writes do not require explicit distributed transactions across regions; Cosmos DB handles replication automatically, and vector indexing does not introduce a requirement for explicit distributed transactions.

Practice this question →

MCQeasy

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?

A.Exhaustive K-Nearest Neighbor (exhaustiveKnn)

B.Hierarchical Navigable Small World (hnsw)

C.Locality-Sensitive Hashing (lsh)

D.Inverted File with Product Quantization (ivf-pq)

AnswerB

Hierarchical Navigable Small World (hnsw) builds a multi-layer proximity graph, enabling approximate nearest neighbour search that trades a small recall loss for markedly faster queries. It directly satisfies the stem's requirement for ANN search balancing recall speed with accuracy, unlike exhaustive k-nearest neighbour (knn), which guarantees exact results but scales linearly and cannot approximate.

Why this answer

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.

Exam trap

AI-200 often tests whether candidates recognize that Azure AI Search only exposes hnsw and exhaustiveKnn, tricking them into selecting ivf-pq or lsh because those are common in other vector databases.

How to eliminate wrong answers

Option A is wrong because exhaustiveKnn performs a brute-force scan of all vectors, which yields exact recall but scales poorly and is too slow for large indexes, so it does not balance speed with accuracy. Option C is wrong because Locality-Sensitive Hashing (lsh) is not a supported vector search algorithm configuration in Azure AI Search; it is a general ANN technique but not exposed as an index algorithm here. Option D is wrong because Inverted File with Product Quantization (ivf-pq) is not a native Azure AI Search algorithm configuration; while IVF and PQ are common in other vector databases, Azure AI Search exposes hnsw and exhaustiveKnn, not ivf-pq.

Practice this question →

Multi-Selectmedium

When configuring an Azure AI Search vector profile, which TWO elements must be successfully referenced together to make the profile functional? (Choose two)

Select 2 answers

A.A Cognitive Services storage blob container

B.An algorithm configuration name

C.A vectorizer name (if using integrated vectorization)

D.An Azure SQL connection string

E.A Cosmos DB throughput RU/s setting

AnswersB, C

A vector profile must bind a specific algorithm configuration by name, which defines the HNSW or exhaustive KNN parameters used to build and query the vector field. Without this reference, the profile cannot determine how vectors are indexed, so it fails to function.

Why this answer

Option B is correct because a vector profile in Azure AI Search must reference a valid algorithm configuration name (the HNSW or exhaustive KNN configuration defined in the index's vectorSearch.algorithms collection) that determines how vector similarity is computed during queries. Option C is correct because when integrated vectorization is used, the vector profile must also reference a vectorizer name (defined in the vectorSearch.vectorizers collection) so the search service can convert text queries into embeddings at query time. These two references — algorithm configuration and vectorizer — are the required components that make a vector profile functional.

Option A is incorrect because a Cognitive Services storage blob container is not part of a vector profile definition; blob containers are used as data sources for indexers, not for vector profiles. Option D is incorrect because an Azure SQL connection string belongs to a data source definition for indexers, not to a vector profile. Option E is incorrect because Cosmos DB RU/s throughput is a database provisioning setting and has no role in defining a vector profile.

Exam trap

AI-200 often tests whether candidates know that a vector profile is a composite object requiring both an algorithm configuration and (for integrated vectorization) a vectorizer — many pick unrelated data-source components like blob containers or SQL connections.

Practice this question →

MCQhard

You are configuring semantic ranking in Azure AI Search to improve search relevance for your enterprise application. Which tier of Azure AI Search is required to enable semantic ranking?

A.Storage Optimized (L1)

B.Standard (S1 or higher)

C.Free

D.Basic

AnswerB

Semantic ranking is unavailable on Free or Basic tiers; it requires Standard S1 or above. Selecting Standard satisfies the tier constraint in the stem, enabling the semantic reranker to reorder results and improve relevance for the enterprise application.

Why this answer

Semantic ranking in Azure AI Search requires the Standard tier (S1) or higher — it is not available on Free or Basic tiers. Semantic ranking uses Microsoft's language models to rerank the top results from BM25 or vector search, improving relevance for natural-language queries. Enabling it on a supported tier is done by adding a semantic configuration to the index and setting queryType to 'semantic'.

Exam trap

AI-200 often tests the assumption that Basic or Free tiers support semantic ranking; the trap is remembering that semantic ranking starts at Standard (S1) and is a separately metered feature.

How to eliminate wrong answers

Option A is wrong because Storage Optimized (L1) is designed for large indexes with lower query throughput and does not support semantic ranking — it is optimized for storage, not semantic reranking workloads. Option C is wrong because the Free tier does not support semantic ranking and has strict limits on index size, replicas, and features. Option D is wrong because the Basic tier, while supporting vector search, does not include semantic ranking — you must move to Standard (S1) or higher.

Practice this question →

MCQmedium

You are building a hybrid search solution using Azure AI Search that combines BM25 full-text search with vector search. What is the name of the feature that intelligently combines and normalizes scores from different retrieval systems before presenting the final top results?

A.Min-Max Score Scaling

B.Cosine Distance Normalization

C.Cross-Encoder Re-ranking

D.Reciprocal Rank Fusion (RRF)

AnswerD

RRF merges the BM25 and vector result sets by fusing each document's reciprocal rank rather than raw scores, so incomparable scoring scales never need normalising. This directly satisfies the stem's requirement to intelligently combine and normalise scores from different retrieval systems into one ranked result list.

Why this answer

Reciprocal Rank Fusion (RRF) is the algorithm Azure AI Search uses to merge BM25 and vector result sets in hybrid queries. It converts each result's rank into a reciprocal score (1/(k+rank)) and sums them, producing a normalized combined ranking without needing to align raw score scales. This is why hybrid search in Azure AI Search 'just works' without manual score normalization.

Exam trap

AI-200 often tests whether candidates know the specific named algorithm (RRF) rather than generic normalization terms — many pick 'Min-Max Score Scaling' because it sounds like what fusion does.

How to eliminate wrong answers

Option A is wrong because Min-Max Score Scaling is a generic normalization technique, not the named feature Azure AI Search uses for hybrid fusion. Option B is wrong because cosine distance normalization only applies to vector similarity scores and does not combine heterogeneous result sets. Option C is wrong because cross-encoder re-ranking is a separate semantic ranking stage that runs after fusion, not the fusion algorithm itself.

Practice this question →

Multi-Selecthard

When designing a hybrid search architecture that integrates Azure AI Search with an Azure OpenAI embedding model, which THREE challenges must you typically address regarding data management and retrieval? (Choose three)

Select 3 answers

A.Ensuring model version consistency between ingestion embeddings and query embeddings

B.Managing re-indexing strategies when updating source documents or schema definitions

C.Provisioning HDInsight Hadoop clusters for vector distance calculations

D.Determining optimal text chunk size and overlap to balance context and precision

E.Configuring Azure SQL Server relational foreign key cascading deletes

AnswersA, B, D

Ingestion and query embeddings must come from the same model version, because vectors from different versions occupy incompatible spaces, degrading similarity. Pinning the deployment and re-embedding existing documents when the model changes prevents mismatched vector comparisons.

Why this answer

Option A is correct because vector search only returns meaningful results when the query embedding is generated by the same model and version that produced the document embeddings; mixing model versions or dimensions causes similarity scores to be invalid, so you must pin and track the embedding deployment/version across ingestion and query paths. Option B is correct because when source documents change or the index schema (fields, analyzers, vector profiles, dimensions) is modified, you must plan re-indexing or incremental refresh strategies to keep the index synchronized and avoid stale or orphaned vectors. Option D is correct because chunk size and overlap directly affect retrieval quality: chunks that are too large dilute the embedding's semantic focus, while chunks that are too small lose context, and overlap controls continuity across boundaries, so tuning these values is a core data-management decision.

Option C is not needed because vector distance calculations are performed natively by Azure AI Search's vector search capabilities, not by provisioning HDInsight Hadoop clusters. Option E is not relevant because Azure SQL Server foreign key cascading deletes concern relational data integrity and have no role in embedding generation, vector indexing, or hybrid retrieval in Azure AI Search.

Exam trap

AI-200 often tests whether candidates conflate search infrastructure with unrelated big-data or relational tools; the trap is picking HDInsight or SQL options that sound technical but have no role in vector retrieval.

Practice this question →

Multi-Selecthard

You are designing a high-performance RAG data layer architecture using Azure AI Search. Which THREE indexing and retrieval strategies should you implement to maximize recall and precision? (Choose three)

Select 3 answers

A.Enable semantic ranker to re-order top results using deep learning models

B.Disable all scoring and ranking algorithms to save CPU cycles

C.Tune HNSW parameters (m, efConstruction, efSearch) for optimal recall vs latency balance

D.Store embeddings as plain text strings in unindexed fields

E.Implement hybrid search combining BM25 keyword matching with vector similarity

AnswersA, C, E

The semantic ranker re-orders the top hybrid results using deep learning language models, promoting passages that genuinely answer the query. This directly raises precision at the top of the result list without changing the underlying recall.

Why this answer

Option A is correct because Azure AI Search's semantic ranker applies deep-learning language models (Microsoft's semantic re-ranking) to re-order the top BM25/vector results, improving precision by promoting semantically relevant documents that lexical or vector scoring alone may rank lower. Option C is correct because HNSW (Hierarchical Navigable Small World) is the approximate nearest neighbor algorithm used in Azure AI Search vector indexes, and tuning m (number of bi-directional links per node), efConstruction (index-time candidate list size), and efSearch (query-time candidate list size) directly controls the recall-versus-latency tradeoff — higher values increase recall at the cost of latency. Option E is correct because hybrid search fuses BM25 keyword scoring with vector similarity (via Reciprocal Rank Fusion in Azure AI Search), capturing both exact term matches and semantic similarity, which raises recall and precision versus either method alone.

Option B is incorrect because disabling scoring and ranking would eliminate relevance ordering entirely, destroying precision rather than maximizing it. Option D is incorrect because embeddings must be stored in vector fields (Collection(Edm.Single) with a vector profile and HNSW configuration) to be searchable; storing them as plain text in unindexed fields makes them unusable for vector retrieval.

Exam trap

AI-200 often tests whether candidates understand that recall and precision require a combination of indexing (HNSW tuning), retrieval (hybrid search), and re-ranking (semantic ranker), rather than a single silver bullet.

Practice this question →

MCQhard

You are optimizing storage costs and search latency for a massive Azure AI Search vector index containing 50 million records, each with 3,072-dimensional embeddings from text-embedding-3-large. Which Azure AI Search feature should you implement to reduce memory footprint while maintaining acceptable recall?

A.Exhaustive K-nearest neighbor (exact KNN) search

B.Scoring profiles with magnitude boosting

C.Scalar Quantization (SQ)

D.Semantic enrichment with Azure AI Language

AnswerC

Scalar Quantization compresses each vector component from 32-bit floats to 8-bit integers, cutting index memory roughly fourfold across 50 million records. This directly reduces the memory footprint constraint while retaining acceptable recall, unlike binary quantization which sacrifices far more accuracy.

Why this answer

Scalar Quantization (SQ) compresses each float32 vector component into a smaller integer (typically 8-bit), reducing the in-memory and on-disk footprint of the vector index by roughly 4x while preserving enough precision to maintain acceptable recall. For a 50-million-record index with 3,072-dimension embeddings, this is the Azure AI Search feature explicitly designed to trade a small amount of recall for substantial memory and cost savings.

Exam trap

AI-200 often tests whether candidates confuse memory-reduction techniques (SQ, BQ, PQ) with ranking or enrichment features, tempting them to pick 'exhaustive KNN' as if it were an optimization.

How to eliminate wrong answers

Option A is wrong because exhaustive KNN performs a brute-force comparison against every vector, which increases latency and memory pressure rather than reducing footprint — it is the opposite of what is needed at 50M scale. Option B is wrong because scoring profiles with magnitude boosting affect how text relevance scores are weighted in ranking; they have no effect on vector index memory. Option D is wrong because semantic enrichment with Azure AI Language adds NLP-derived metadata (entities, key phrases) to documents and does not compress or shrink the vector index.

Practice this question →

Multi-Selectmedium

When configuring an Azure AI Search vector index, which TWO parameters can be adjusted within the HNSW algorithm configuration to trade off between search speed, memory usage, and recall accuracy? (Choose two)

Select 2 answers

A.efSearch

B.replicaCount

C.partitionCount

D.maxTextLength

E.m

AnswersA, E

efSearch controls how many candidate neighbours the HNSW search explores at query time. Raising it improves recall accuracy at the cost of slower searches, while lowering it speeds queries and reduces recall, directly providing the speed, memory and accuracy trade-off the stem requires.

Why this answer

Option A, efSearch, is correct because it sets the size of the dynamic candidate list used during query time in HNSW; increasing efSearch explores more neighbors, improving recall accuracy at the cost of slower searches, while decreasing it speeds up queries with lower recall. Option E, m, is correct because it defines the number of bidirectional links created for each node in the HNSW graph; a higher m improves recall and accuracy but consumes more memory, whereas a lower m reduces memory usage and speeds up indexing/search with reduced recall. Option B, replicaCount, is incorrect because it controls the number of replicas for high availability and query throughput in Azure AI Search, not the HNSW speed/memory/recall tradeoff.

Option C, partitionCount, is incorrect because it controls index partitioning for storage and write scaling, not HNSW tuning. Option D, maxTextLength, is incorrect because it is a field/analyzer-related setting for text content length, unrelated to HNSW graph parameters.

Exam trap

AI-200 often tests confusion between service-scaling parameters (replicas, partitions) and algorithm-level HNSW parameters (m, efSearch, efConstruction), so candidates must recognize which layer each knob operates at.

Practice this question →

MCQeasy

Which property in an Azure Cosmos DB for NoSQL SQL query specifies the maximum number of vector search results to return?

A.TOP

B.FETCH FIRST

C.LIMIT

D.MAXROWS

AnswerA

TOP sets the maximum number of results returned by a Cosmos DB for NoSQL query, directly satisfying the vector search result limit. Applied as `SELECT TOP N`, it caps rows after the ORDER BY VectorDistance ranking, so the nearest N vectors are returned without retrieving the full candidate set.

Why this answer

In the Azure Cosmos DB for NoSQL SQL query syntax, TOP is the keyword that limits the number of results returned, and it is used with vector search queries to cap the number of nearest-neighbor results. For example, 'SELECT TOP 10 c.id FROM c ORDER BY VectorDistance(c.embedding, @queryVector)' returns the 10 closest matches. This mirrors T-SQL semantics rather than PostgreSQL or MySQL syntax.

Exam trap

AI-200 often tests cross-database SQL syntax confusion; the trap is picking LIMIT or FETCH FIRST because they are familiar from PostgreSQL or MySQL, when Cosmos DB for NoSQL exclusively uses TOP.

How to eliminate wrong answers

Option B is wrong because FETCH FIRST is ANSI SQL / PostgreSQL / Oracle syntax and is not supported in Cosmos DB for NoSQL. Option C is wrong because LIMIT is MySQL/PostgreSQL syntax and Cosmos DB for NoSQL does not recognize it. Option D is wrong because MAXROWS is not a Cosmos DB SQL keyword at all — it is not part of the NoSQL query grammar.

Practice this question →

MCQmedium

You are building a RAG application using Azure AI Search. You want to ensure that the search results provided to the LLM are as relevant as possible by leveraging a re-ranking model. Which service must be enabled to utilize the 'Semantic Ranker'?

A.Standard Tier or higher

B.Basic Tier

C.Free Tier

D.Storage Optimized Tier

AnswerA

Semantic Ranker requires Azure AI Search at Standard tier or above; Free and Basic tiers do not expose semantic ranking. Enabling it satisfies the stem's relevance constraint by applying Microsoft's language models to re-rank the initial BM25 or vector result set, promoting semantically closest chunks before they reach the LLM.

Why this answer

Semantic Ranker in Azure AI Search requires the Standard tier or higher; it is not available on the Free or Basic tiers. Enabling Semantic Ranker allows the service to re-rank search results using a deep learning model, improving relevance for RAG applications by promoting semantically relevant documents.

Exam trap

AI-200 often tests the minimum tier required for Semantic Ranker — candidates may incorrectly assume Basic or Free tiers support it, but Standard is the minimum.

How to eliminate wrong answers

Option B is wrong because the Basic tier does not support Semantic Ranker; it only offers basic indexing and querying capabilities. Option C is wrong because the Free tier lacks Semantic Ranker and has strict limits on storage and indexes. Option D is wrong because 'Storage Optimized' is a tier optimized for large indexes with lower query throughput, but it is not the minimum tier for Semantic Ranker; Standard is the entry point.

Practice this question →

100

MCQhard

You are designing a RAG solution where documents are dynamically updated in Azure AI Search. You notice that search results return outdated information immediately after document updates. What is the cause of this behavior?

A.Semantic ranker caches search results for exactly 30 days

B.Azure OpenAI embedding models require a 24-hour cool-down period before new embeddings become valid

C.Vector indexes in Azure AI Search are read-only after creation and cannot accept updates

D.The indexer has not yet run its scheduled synchronization cycle to process changes from the data source

AnswerD

Indexers pull changes on a schedule rather than continuously, so freshly updated source documents remain absent from the index until the next synchronisation cycle completes. The stale results are expected latency, not a query or scoring fault.

Why this answer

In Azure AI Search, data source changes are not automatically reflected in the index; an indexer must run to pull, transform, and load updated content. If the indexer is on a schedule (e.g., every 5 minutes or hourly), there is an inherent delay between the source update and the index refresh. Until that synchronization cycle completes, queries hit the old index data, returning outdated results.

This is expected behavior, not a bug, and can be mitigated by triggering the indexer on-demand or using a change detection policy.

Exam trap

AI-200 often tests the misconception that Azure AI Search automatically syncs with data sources in real-time, leading candidates to overlook the need for indexer scheduling or triggering.

How to eliminate wrong answers

Option A is wrong because the semantic ranker does not cache results at all—it re-ranks the top results from the initial query using semantic models, and there is no 30-day cache. Option B is wrong because Azure OpenAI embedding models do not have a 24-hour cool-down; embeddings are generated immediately upon request, and new embeddings become valid as soon as they are indexed. Option C is wrong because vector indexes in Azure AI Search are fully updatable; you can add, update, or delete documents and their vectors at any time, provided the index schema supports it.

Practice this question →

101

MCQmedium

You are writing a query in Azure Cosmos DB for NoSQL to retrieve documents based on vector similarity against a target embedding. Which built-in SQL function should you use in the ORDER BY clause?

A.CosSimilarity()

B.EmbeddingDistance()

C.GetVectorDistance()

D.VectorDistance()

AnswerD

VectorDistance() computes cosine, dot product or Euclidean distance between stored vectors and the query embedding, so ordering by it returns the nearest neighbours first. It is the only built-in NoSQL function that satisfies the vector similarity ranking constraint in the ORDER BY clause.

Why this answer

Azure Cosmos DB for NoSQL exposes the VectorDistance() built-in function, which computes the similarity/distance between a stored vector property and a query vector, and is used inside ORDER BY to rank results by similarity. It supports cosine, dot product, and Euclidean metrics via an optional third argument. This is the documented function for vector search queries in the NoSQL API.

Exam trap

AI-200 often tests whether candidates recognize the exact built-in function name, since distractors like CosSimilarity() and GetVectorDistance() sound plausible but are not part of the Cosmos DB SQL API.

How to eliminate wrong answers

Option A is wrong because CosSimilarity() is not a Cosmos DB NoSQL function — it resembles naming from other vector databases and is a distractor. Option B is wrong because EmbeddingDistance() does not exist in the Cosmos DB SQL grammar. Option C is wrong because GetVectorDistance() is also not a valid Cosmos DB function; it mimics generic naming but is not part of the API surface.

Practice this question →

102

Multi-Selecthard

You are optimizing an Azure Cosmos DB for NoSQL vector search container. Which THREE properties must be correctly configured inside the vectorEmbeddingPolicy JSON object? (Choose three)

Select 3 answers

A.path

B.httpPort

C.dataType

D.distanceFunction

E.sslEnabled

AnswersA, C, D

path identifies the document property holding the vector array, telling Cosmos DB which field to index for vector search. Without it the policy cannot locate embeddings, so it must be configured as the stem demands.

Why this answer

The vectorEmbeddingPolicy JSON object in an Azure Cosmos DB for NoSQL container requires three properties: path, dataType, and distanceFunction. Option A (path) is correct because it specifies the JSON path to the array property in each document that holds the vector embedding, such as "/embedding". Option C (dataType) is correct because it defines the data type of the vector elements, with supported values like float32, float16, int8, and uint8, which must match the stored vector data.

Option D (distanceFunction) is correct because it specifies the similarity metric used for vector search, such as cosine, dotproduct, or euclidean, and is required for the index to compute nearest neighbors. Options B (httpPort) and E (sslEnabled) are not part of the vectorEmbeddingPolicy; these are connection or endpoint settings, not properties of the vector embedding policy JSON object.

Exam trap

The trap is confusing networking or security properties (httpPort, sslEnabled) with vector-specific configuration — candidates who have seen Cosmos DB connection strings may mistakenly include them.

Practice this question →

103

MCQeasy

Your company stores product catalog items in Azure Cosmos DB for NoSQL and needs to implement vector search for recommendation capabilities. Which indexing policy property must you add to enable vector indexing on a container?

A.compositeIndexes

B.vectorIndexes

C.spatialIndexes

D.fullTextIndexes

AnswerB

The vectorIndexes property in the container's indexing policy defines vector paths, types, and similarity metrics, which Cosmos DB for NoSQL requires before it will index and serve vector search queries. Omitting it leaves embeddings unindexed, so VectorDistance queries fail or scan.

Why this answer

Azure Cosmos DB for NoSQL requires a `vectorIndexes` array in the container's indexing policy to define vector indexing on vector-typed properties. Each entry specifies the vector path and the vector index type (flat, quantizedFlat, or diskANN). Without this property, vector search queries cannot be served efficiently or at all against the container.

Exam trap

AI-200 often tests confusion between indexing policy sub-properties, tricking candidates who pick `compositeIndexes` or `spatialIndexes` because they sound like advanced indexing features.

How to eliminate wrong answers

Option A is wrong because `compositeIndexes` defines multi-property composite indexes for ORDER BY and filter operations on scalar fields, not vector similarity indexing. Option C is wrong because `spatialIndexes` enables geospatial indexing for GeoJSON point/polygon data used with ST_DISTANCE and ST_WITHIN, unrelated to vector embeddings. Option D is wrong because `fullTextIndexes` (where available) supports full-text search on string fields via Lucene-style queries, not vector similarity search on float arrays.

Practice this question →

104

MCQhard

You are designing a high-throughput RAG pipeline where documents are continuously ingested and queried. You choose Azure Cosmos DB for NoSQL as your vector store. How does Cosmos DB handle vector indexing updates when new documents are inserted?

A.Vector indexes are updated asynchronously in the background by the database engine

B.You must manually trigger an index rebuild stored procedure every hour

C.Vector search is completely unavailable until the entire collection is re-indexed from scratch

D.New documents cannot be queried using VectorDistance until the container is restarted

AnswerA

Cosmos DB's vector index is maintained by the database engine without blocking writes, so inserts return quickly while index updates propagate in the background. This asynchronous behaviour satisfies the continuous-ingestion, high-throughput constraint in the stem.

Why this answer

Azure Cosmos DB for NoSQL automatically updates vector indexes asynchronously in the background when new documents are inserted. This means that after insertion, there may be a slight delay before the new vectors are indexed and available for vector search queries. The database engine handles the indexing without manual intervention.

Exam trap

AI-200 often tests the asynchronous nature of vector indexing in Cosmos DB. Candidates might think indexing is synchronous or requires manual intervention, but it's automatic and asynchronous.

How to eliminate wrong answers

Option B is wrong because you do not need to manually trigger an index rebuild; Cosmos DB manages indexing automatically. Option C is wrong because vector search remains available for existing documents; only the new documents are not immediately searchable until indexed. Option D is wrong because new documents can be queried using VectorDistance once they are indexed; a container restart is not required.

Practice this question →

105

MCQmedium

You are developing an enterprise retrieval-augmented generation (RAG) application using Azure AI Search. You need to configure a vector index to store dense vector embeddings alongside traditional text fields. Which property within the Azure AI Search index definition must be explicitly configured with a vector search profile to enable HNSW (Hierarchical Navigable Small World) algorithm indexing?

A.vectorIndexKind

B.compressionMethod

C.vectorSearchProfile

D.similarityFunction

AnswerC

The `vectorSearchProfile` property on a vector field binds that field to a named profile in the index's `vectorSearch` configuration, where the HNSW algorithm and its parameters are defined. Without this assignment, Azure AI Search cannot apply HNSW indexing to the embeddings, so the field must reference the profile explicitly.

Why this answer

In an Azure AI Search index, the vectorSearchProfile property on a vector field binds that field to a named profile defined in the index's vectorSearch configuration. The profile in turn references an algorithm configuration (for example, an HNSW parameters object) and optionally a compression method, so setting vectorSearchProfile is what actually activates HNSW indexing for the field.

Exam trap

AI-200 often tests whether candidates know that the field-level vectorSearchProfile is the binding point, while algorithm parameters (HNSW) and compression live in the profile — so options like vectorIndexKind or similarityFunction sound authoritative but are not the enabling property.

How to eliminate wrong answers

Option A is wrong because vectorIndexKind is not a valid Azure AI Search index property — the algorithm is selected through the algorithm configuration referenced by the profile, not a 'kind' field. Option B is wrong because compressionMethod is a property of a vector search profile (used for scalar or binary quantization), not the field-level property that enables HNSW. Option D is wrong because similarityFunction is a legacy/related concept for scoring (cosine, dotProduct, euclidean) and does not itself wire a field to an HNSW algorithm configuration.

Practice this question →

106

MCQmedium

You are evaluating Cosmos DB for NoSQL vs. Azure AI Search for a vector search application. Your application requires strict ACID compliance for metadata updates along with vector search. Which should you choose and why?

A.Cosmos DB because it is the only service that supports vectors.

B.Cosmos DB because it supports document-level ACID transactions.

C.Azure AI Search because it supports better hybrid search.

D.Azure AI Search because it uses HNSW for faster searches.

AnswerB

Cosmos DB for NoSQL provides native transactional guarantees within a single logical partition, satisfying the strict ACID requirement for metadata updates. Its integrated vector indexing and search capability handles embeddings in the same store, avoiding cross-service consistency gaps that Azure AI Search alone cannot close.

Why this answer

Cosmos DB for NoSQL supports document-level ACID transactions via the transactional batch API, ensuring metadata updates are atomic and consistent. When the requirement combines strict ACID compliance for metadata with vector search, Cosmos DB is the correct choice because Azure AI Search does not provide ACID transactional guarantees for document updates. This aligns the service's transactional model with the application's consistency requirement.

Exam trap

AI-200 often tests the trade-off between search richness (Azure AI Search) and transactional consistency (Cosmos DB), luring candidates toward Azure AI Search for its hybrid search and HNSW speed when the requirement explicitly demands ACID.

How to eliminate wrong answers

Option A is wrong because Azure AI Search also supports vectors, so Cosmos DB is not the only service with vector support—the reason to choose Cosmos DB is ACID, not exclusivity. Option C is wrong because hybrid search quality is not the stated requirement, and Azure AI Search lacks the ACID transaction guarantee the application needs. Option D is wrong because HNSW is used by Azure AI Search for fast approximate nearest neighbor search, but speed is not the requirement; ACID compliance is, and HNSW does not provide transactions.

Practice this question →

107

Multi-Selectmedium

When configuring vector search in Azure Cosmos DB for NoSQL, which TWO steps are required to prepare a container for vector search before inserting documents? (Choose two)

Select 2 answers

A.Define the vectorEmbeddingPolicy at container creation or update

B.Define vectorIndexes within the indexingPolicy

C.Mount an NFS network share for vector file storage

D.Install the pgvector extension on the container

E.Create a relational foreign key constraint to Azure SQL

AnswersA, B

Defining the vectorEmbeddingPolicy at container creation or update declares the vector properties, dimensions, data type and distance function that Cosmos DB's indexing engine requires. Without this policy, the container cannot interpret or index vector fields, so the stem's requirement to prepare the container before inserting documents is satisfied.

Why this answer

Option A is correct because Azure Cosmos DB for NoSQL requires a vectorEmbeddingPolicy on the container to declare the vector properties, including the path to the vector field, the data type (e.g., float32), dimensions, and distance function (cosine, dotproduct, or euclidean) before vectors can be stored and queried. Option B is correct because you must also define vectorIndexes inside the container's indexingPolicy, specifying the vector path and index type (flat, quantizedFlat, or diskANN), so the vector data is actually indexed and searchable. Options C, D, and E are incorrect: NFS shares, the pgvector extension, and relational foreign keys belong to other systems (file storage, PostgreSQL, and relational databases respectively) and are not part of Cosmos DB for NoSQL vector search configuration.

Exam trap

AI-200 often tests the misconception that vector search in Cosmos DB requires external extensions or relational features, when in fact it is natively supported through container policies.

Practice this question →

108

MCQmedium

You are configuring vector indexing in Azure Cosmos DB for MongoDB (vCore). You need to choose an indexing type for your vector property to balance query performance and recall accuracy for high-dimensional data. Which vector index type should you select for approximate nearest neighbor (ANN) search?

A.FULLTEXT index

B.HNSW (Hierarchical Navigable Small World)

C.B-Tree index

D.HASH index

AnswerB

HNSW builds a hierarchical proximity graph, giving logarithmic-complexity approximate nearest neighbour search with high recall on high-dimensional vectors. This satisfies the balance requirement, outperforming IVF and flat indexes on the recall-latency trade-off Cosmos DB for MongoDB (vCore) exposes.

Why this answer

HNSW (Hierarchical Navigable Small World) is a graph-based approximate nearest neighbor algorithm that builds a multi-layer navigable graph, delivering high recall with low latency for high-dimensional vectors. In Azure Cosmos DB for MongoDB vCore, HNSW is the supported vector index type for ANN search, and it is the recommended choice when you need to balance query performance and recall accuracy. FULLTEXT, B-Tree, and HASH indexes are not designed for vector similarity search and cannot perform ANN queries.

Exam trap

The trap here is confusing traditional database index types (B-Tree, HASH, FULLTEXT) with vector index types; candidates who have not worked with vector search may pick B-Tree or FULLTEXT because they are familiar, but only HNSW supports ANN in Cosmos DB for MongoDB vCore.

How to eliminate wrong answers

Option A is wrong because a FULLTEXT index performs lexical token-based text search (inverted index), not vector similarity; it cannot compute cosine or Euclidean distance between embeddings. Option C is wrong because a B-Tree index supports range and equality queries on scalar values, not high-dimensional vector proximity search. Option D is wrong because a HASH index supports exact-match equality lookups only; it has no notion of nearest neighbor or distance ranking, so it cannot perform ANN search.

Practice this question →

109

MCQhard

You are troubleshooting a performance issue where an Azure AI Search indexer fails to complete within the scheduled execution window when processing large PDF documents. What is the most effective configuration change to resolve the timeout issue?

A.Configure the indexer maxRunTime property and scale out search units or adjust batch size

B.Convert all vector fields to Edm.String

C.Switch the search service to the Free tier

D.Delete all semantic configurations from the index

AnswerA

The maxRunTime property extends or caps indexer execution, while scaling out search units and tuning batch size raise throughput so large PDFs finish within the window. Together these address the scheduled-window timeout constraint directly, unlike enrichment or skillset changes.

Why this answer

Indexer timeouts on large PDFs are typically caused by the indexer exceeding the scheduled run window while skillset enrichment and document cracking proceed slowly. Increasing maxRunTime extends the allowed execution window, and scaling out search units (or reducing batch size) increases throughput so the indexer completes within the schedule. These are the documented levers for resolving indexer timeout issues in Azure AI Search.

Exam trap

AI-200 often tests whether candidates confuse query-time features (semantic ranker, scoring profiles) with indexer-time performance controls, tempting them to remove semantic configs instead of tuning maxRunTime and scaling.

How to eliminate wrong answers

Option B is wrong because converting vector fields to Edm.String destroys the vector representation and breaks vector search entirely; it does not address indexer runtime. Option C is wrong because the Free tier has the lowest throughput and no scaling, which would worsen timeouts rather than resolve them. Option D is wrong because semantic configurations affect query-time ranking, not indexer execution time, and removing them provides no performance benefit to the indexing pipeline.

Practice this question →

110

Multi-Selectmedium

You are designing a vector search solution using Azure AI Search. Which THREE of the following are necessary steps to configure an index to support vector search?

Select 3 answers

A.Define a 'vectorSearch' configuration within the index schema.

B.Set the index to 'ReadOnly' mode.

C.Assign a 'vectorSearchProfile' to the vector-capable fields.

D.Ensure all vector fields are set to 'Edm.String'.

E.Define vector fields as type 'Collection(Edm.Single)'.

AnswersA, C, E

The vectorSearch object is the index-level container declaring algorithms and profiles; vector fields reference it through a profile. Without it, the service has no HNSW or exhaustive KNN configuration to build the vector index, so vector queries cannot be served.

Why this answer

Option A is correct because the index schema must include a 'vectorSearch' configuration block that declares the vector search algorithms (e.g., HNSW or exhaustive KNN) and the profiles used by the index. Option C is correct because each vector field must reference a 'vectorSearchProfile' that ties the field to a specific algorithm and vectorizer configuration defined in the 'vectorSearch' section. Option E is correct because Azure AI Search represents vector embeddings as 'Collection(Edm.Single)', a collection of single-precision floats, which is the required data type for vector fields.

Option B is incorrect because setting the index to 'ReadOnly' mode is unrelated to vector search configuration and would only prevent updates to the index. Option D is incorrect because 'Edm.String' is used for text fields, not vector fields, and would not store the numeric embedding arrays required for vector search.

Exam trap

AI-200 often tests whether candidates conflate the three distinct schema artifacts — 'vectorSearch' config, 'vectorSearchProfile', and the 'Collection(Edm.Single)' field type — with unrelated index settings like read-only mode or string field types, so picking 'Edm.String' or a permissions flag instead of the numeric collection type is the classic wrong-answer trap.

Practice this question →

111

MCQmedium

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?

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

B.JOIN vectorIndex ON c.id = vectorIndex.id

C.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])

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

AnswerC

Vector search in Cosmos DB for NoSQL requires ORDER BY on the VectorDistance() function so results are ranked by similarity, combined with TOP to limit returned rows. The SELECT projects the score alongside the document id, satisfying the required query structure.

Why this answer

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.

Exam trap

The trap is assuming VectorDistance() can be used in a WHERE filter or that a JOIN is needed, when the correct pattern requires it in SELECT and ORDER BY with TOP N.

How to eliminate wrong answers

Option A is wrong because using VectorDistance() in a WHERE clause with a comparison does not leverage the vector index and does not follow the required top-k pattern; it also returns no similarity score. Option B is wrong because Cosmos DB does not support JOIN with a vector index; vector search is performed via the VectorDistance() function, not a join. Option D is wrong because GROUP BY on VectorDistance() is not a valid vector search pattern and does not rank or limit results.

Practice this question →

112

MCQeasy

When designing a data layer architecture for an AI application using Azure AI Search, what is the primary role of an integrated vectorizer?

A.To execute full-text BM25 keyword matching alongside vector calculations.

B.To automatically convert raw source text fields into vector embeddings during indexing and queries without requiring external orchestration code.

C.To compress vector indexes using lossy compression algorithms to save disk storage.

D.To generate cryptographic hashes for document deduplication.

AnswerB

An integrated vectorizer is attached to index fields and query inputs, calling the embedding model automatically during indexing and at query time. This removes the need for external orchestration code to generate embeddings, satisfying the no-code embedding requirement in Azure AI Search.

Why this answer

An integrated vectorizer in Azure AI Search is a configuration that binds an embedding model (e.g., Azure OpenAI text-embedding-ada-002) to an index so that raw text fields are automatically converted into vector embeddings at both indexing time and query time. This eliminates the need for external orchestration code to call the embedding API, chunk text, and push vectors into the index.

Exam trap

AI-200 often tests whether candidates confuse the vectorizer (embedding generation) with the semantic ranker (reranking) or with quantization (compression), leading them to pick an unrelated feature.

How to eliminate wrong answers

Option A is wrong because BM25 keyword matching is handled by the search engine's text index independently of the vectorizer; the vectorizer's job is embedding generation, not lexical scoring. Option C is wrong because the vectorizer does not compress indexes — compression is handled by quantization features like Scalar or Binary Quantization. Option D is wrong because cryptographic hashing for deduplication is unrelated to embedding generation; the vectorizer produces semantic vectors, not hashes.

Practice this question →

113

Multi-Selecthard

You are designing a data layer architecture for an enterprise AI assistant that requires high-performance vector search, structured filtering, and multi-tenant isolation. Which THREE design patterns should you consider? (Choose three)

Select 3 answers

A.Combining vector similarity with metadata filters to narrow search scope

B.Storing all tenant data in a single unindexed JSON blob without partition keys

C.Using tenant-specific partition keys or metadata filter tags for multi-tenant isolation

D.Hardcoding all user prompts directly into the search index schema

E.Implementing hybrid search to capture both exact keyword matches and conceptual similarities

AnswersA, C, E

Hybrid filtering applies metadata predicates alongside vector similarity, so tenant identifiers and structured attributes restrict the candidate set before or during nearest-neighbour search. This satisfies the stem's structured filtering and multi-tenant isolation requirements while preserving high-performance vector search across partitioned data.

Why this answer

Option A is correct because combining vector similarity with metadata filters (pre-filtering or post-filtering on structured attributes) narrows the candidate set, improving both relevance and latency for an AI assistant that needs structured filtering alongside semantic search. Option C is correct because tenant-specific partition keys or metadata filter tags enforce logical isolation in a shared vector index, ensuring queries only return a tenant's own data and satisfying multi-tenant isolation requirements. Option E is correct because hybrid search fuses dense vector similarity with sparse keyword matching (for example BM25 plus embeddings, often combined via reciprocal rank fusion), capturing both exact term matches and conceptual similarity for higher recall and precision.

Option B is wrong because an unindexed JSON blob with no partition keys destroys search performance and provides no tenant isolation. Option D is wrong because hardcoding user prompts into the index schema is brittle, non-scalable, and violates separation of data from schema design.

Exam trap

The trap is that 'single unindexed JSON blob' and 'hardcoding prompts' are obviously bad, but candidates sometimes hesitate on hybrid search, thinking vector search alone suffices — the exam expects you to recognize that enterprise assistants need both keyword and semantic retrieval.

Practice this question →

114

Multi-Selecthard

When configuring vector search algorithms in Azure AI Search, you can tune several parameters associated with the Hierarchical Navigable Small World (HNSW) graph. Which THREE parameters are configurable within an HNSW algorithm profile?

Select 3 answers

A.efConstruction

B.bm25K1

C.chunkOverlapSize

D.efSearch

E.m

AnswersA, D, E

efConstruction controls the size of the dynamic candidate list during index construction, directly governing graph quality and build-time cost. It is one of the three tunable HNSW parameters in Azure AI Search, alongside m and efSearch, satisfying the stem's requirement for configurable HNSW profile settings.

Why this answer

In Azure AI Search, an HNSW algorithm profile exposes three tunable graph parameters: efConstruction (option A), which controls the size of the dynamic candidate list during index construction and thus the quality of the built graph; efSearch (option D), which controls the size of the candidate list at query time and trades recall against latency; and m (option E), which sets the number of bidirectional links created per node and governs graph connectivity and memory usage. These are exactly the parameters documented for the HNSW configuration object in Azure AI Search. Option B (bm25K1) is a parameter of the BM25 ranking function used for keyword relevance scoring, not vector search, and option C (chunkOverlapSize) relates to how documents are split during chunking in a skillset or integrated vectorization pipeline, not to the HNSW graph itself.

Exam trap

AI-200 often tests whether candidates can distinguish HNSW graph parameters (m, efConstruction, efSearch) from BM25 text-scoring parameters (k1, b) and chunking parameters (chunkSize, chunkOverlap).

Practice this question →

115

MCQeasy

Which Azure AI Search feature allows you to re-order search results using advanced machine learning models trained by Microsoft to dramatically improve semantic relevance?

A.BM25 Scoring

B.Fuzzy Search

C.Reciprocal Rank Fusion

D.Semantic Ranker

AnswerD

Semantic Ranker re-orders results using Microsoft's advanced machine learning models, satisfying the stem's requirement for dramatically improved semantic relevance. It reranks an initial result set, promoting contextually meaningful matches over keyword-only ordering. This directly addresses the need to re-order search results with Microsoft-trained models.

Why this answer

Semantic Ranker is the Azure AI Search feature that applies Microsoft's deep learning models (based on transformer/BERT-style architectures) to re-rank an initial BM25 result set, promoting results that are semantically relevant to the query rather than just lexically matching. It operates as an L2 ranking stage on top of the L1 retrieval results, using the query and document text to compute semantic relevance scores. This dramatically improves relevance for natural-language queries where keyword overlap is weak.

Exam trap

AI-200 often tests the distinction between the L1 lexical ranker (BM25) and the L2 ML-based re-ranker (Semantic Ranker), so candidates who see 'machine learning models trained by Microsoft' and pick BM25 or RRF get it wrong.

How to eliminate wrong answers

Option A is wrong because BM25 is the L1 lexical ranking algorithm (a probabilistic term-frequency/inverse-document-frequency scorer) that Semantic Ranker actually re-orders — it is not the ML-based re-ranker itself. Option B is wrong because fuzzy search only handles typos and approximate string matches via edit-distance logic; it does not perform semantic re-ranking. Option C is wrong because Reciprocal Rank Fusion is a technique for merging multiple ranked result lists (e.g., vector and keyword results in hybrid search) into one, not a Microsoft-trained semantic relevance model.

Practice this question →

116

MCQhard

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?

A.Rebuild the index using exhaustiveKnn

B.Increase the number of partition instances

C.Increase the number of search units by adding replica instances

D.Upgrade the search service from Standard to Basic tier

AnswerC

Adding replicas increases the search units available for query processing, distributing vector queries across more nodes. This scales out query throughput directly, satisfying the high query volume constraint, while leaving partitions untouched so index build time and index size remain unchanged.

Why this answer

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.

Exam trap

AI-200 often tests the distinction between scaling for query throughput (replicas) versus scaling for storage/indexing (partitions); candidates frequently confuse the two and pick partitions.

How to eliminate wrong answers

Option A is wrong because exhaustiveKnn forces a full brute-force scan of all vectors, which is slower and does not scale out query processing — it actually degrades performance. Option B is wrong because increasing partitions scales storage and indexing throughput, not query throughput, and it increases index build time. Option D is wrong because Basic tier is a lower tier than Standard and cannot support the same scale or vector search features; downgrading would reduce capacity.

Practice this question →