CCNA Data Management Services And Vector Search Questions

Option A is correct because Azure Cosmos DB is designed as a low-latency operational database, offering single-digit millisecond point reads and writes (by key and partition key) for business records, whereas Azure AI Search is a search index optimized for query throughput rather than transactional point operations. Option B is correct because Cosmos DB natively stores schema-flexible JSON documents and, with vector indexing/vector search support, can hold operational documents and their embeddings together in the same container. Option D is correct because Cosmos DB supports multi-document ACID transactions within a single logical partition (transactional batch), which Azure AI Search cannot provide since it is not a transactional database.

Option C is not correct because advanced BM25 keyword ranking and neural semantic re-ranking are core capabilities of Azure AI Search, not differentiators of Cosmos DB. Option E is not correct because automatic PDF text extraction, OCR, and document chunking via indexers are Azure AI Search (AI enrichment/indexer) features, not Cosmos DB features.

Option A is correct because adding replicas to an Azure AI Search service distributes query load across more nodes, directly increasing query throughput (QPS) and reducing per-query latency, since each replica holds a full copy of the index and can serve queries independently. Option C is correct because vector search is memory-intensive: the HNSW graph and vector indexes must reside in RAM, so deploying on Standard tier or higher (rather than Basic/Free, which have limited memory and no vector support at scale) ensures adequate RAM to avoid disk-bound traversal and throttling. Option D is correct because lowering the efSearch parameter reduces the size of the HNSW candidate list explored during query-time traversal, trading a small amount of recall for faster search and lower latency, which is a standard tuning lever for throughput-sensitive vector workloads.

Option B is not correct because ASCII folding tokenizers apply to text/lexical fields, not vector fields, and cannot replace vector embeddings or improve vector similarity search. Option E is not correct because exhaustive KNN scans the entire vector space and is far slower than HNSW approximate search, making it unsuitable for high-QPS production workloads.

Option A is correct because Azure Cosmos DB is designed for global distribution with turnkey multi-region replication and single-digit millisecond read/write latencies at the 99th percentile, which is a decisive factor when the vector store must serve globally distributed users; Azure AI Search does not provide the same multi-master, multi-region replication model. Option B is correct because Azure AI Search natively provides full-text search with BM25 ranking, scoring profiles, and semantic re-ranking (semantic ranker/L2 reranking), capabilities that Cosmos DB's vector search does not offer out of the box. Option E is correct because Cosmos DB is a transactional NoSQL database offering low-latency CRUD operations (point reads/writes, optimistic concurrency via ETags) in the same store as vector indexes, which matters when the application must mutate documents and query embeddings together.

Option C is not relevant because neither service runs Hadoop MapReduce jobs directly over vector indexes, and vector search is not a MapReduce workload. Option D is incorrect because Cosmos DB is a NoSQL document database, not a relational engine with SQL tables and foreign key constraints, and Azure AI Search is not relational either.

Option B (name) is correct because every field in an Azure AI Search index schema requires a unique name that identifies the field within the fields collection, and this name is used in queries, filters, and result documents. Option E (type) is correct because each field must declare an Edm data type (such as Edm.String, Edm.Int32, Edm.Boolean, Edm.DateTimeOffset, or Collection(Edm.String)) so the search engine knows how to index, store, and query the field's values. Option A (analyzerName) is not required for every field; analyzers apply only to searchable string fields and default to the standard Lucene analyzer when omitted.

Option C (scoringProfile) is not a field-level property at all; scoring profiles are defined at the index level to influence relevance ranking. Option D (vectorDimensions) is only required for fields of type Collection(Edm.Single) that participate in vector search, not for every field.

Azure SQL Database (A) is correct because it natively supports a VECTOR data type and vector similarity functions such as VECTOR_DISTANCE, enabling cosine and Euclidean similarity search directly in T-SQL alongside relational transactional workloads. Azure Cosmos DB for NoSQL (C) is correct because it provides native vector indexing and vector search (including DiskANN-based indexing) with similarity functions like VectorDistance, so it can store and query embeddings alongside JSON documents. Azure Queue Storage (B) is a simple message-queue service with no data types or query engine, so it cannot store vectors or perform similarity search.

Azure Table Storage (D) is a key-value/NoSQL table store without vector data types or similarity functions. Azure Cache for Redis Basic tier (E) lacks the RediSearch/vector modules, so it cannot perform vector similarity search in that tier.

Option B is correct because enabling diagnostic logging and streaming audit logs to Azure Monitor / Log Analytics provides the tamper-evident activity trail and monitoring required for regulatory compliance (e.g., PCI DSS, SOX) on financial document workloads. Option D is correct because configuring Customer-Managed Keys (CMK) via Azure Key Vault gives the organization control over the encryption keys protecting data at rest in Cosmos DB, satisfying requirements for key ownership, rotation, and revocation that Microsoft-managed keys do not meet. Option E is correct because restricting network access with Virtual Network service endpoints and Azure Private Link removes public internet exposure, ensuring only approved private endpoints within the VNet can reach the Cosmos DB and Azure AI Search resources.

Option A is wrong because storing backups in unencrypted public blob containers directly violates encryption-at-rest and access-control mandates. Option C is wrong because disabling authentication keys and allowing anonymous public access eliminates authentication and authorization, which is unacceptable for sensitive financial data.

Option A is correct because a well-chosen partition key that evenly distributes data and query load across physical partitions prevents hot partitions, which is essential for predictable performance and scalability in Cosmos DB for NoSQL. Option B is correct because enabling multi-region write replication (multi-master) provides global low-latency writes and improves availability by allowing the account to continue serving requests even if a region becomes unavailable. Option E is correct because provisioning adequate Request Units (RUs) or configuring autoscale throughput ensures the database has enough throughput capacity to handle workload demands, preventing throttling (429 errors) and maintaining predictable performance.

Option C is incorrect because storing all documents in a single logical partition without a partition key creates a hot partition and limits scalability, harming both availability and performance. Option D is incorrect because disabling automatic indexing entirely removes the default indexing policy that supports efficient queries, which would degrade query performance rather than improve it.

Option B is correct because hybrid search always includes a keyword (full-text) component, which requires at least one searchable Edm.String field in the index so the query can perform BM25-scored term matching via the inverted index. Option C is correct because the vector half of a hybrid query needs a vector field of type Collection(Edm.Single) (Edm.SingleCollection) plus an attached vector profile (with HNSW or exhaustive KNN algorithm and a vectorizer if integrated vectorization is used) so the query engine can run the approximate nearest neighbor search. Option E is correct because semantic ranking is not automatic — it requires a semanticConfiguration defined on the index (specifying title, content, and keyword priority fields) that is referenced in the query's semanticSearch settings to invoke the L2 semantic reranker.

Option A is not required: Azure Blob Storage is only an optional data source for indexers/pull-based ingestion, and hybrid queries can run against any populated index regardless of origin. Option D is not required: Azure AI Search natively performs reciprocal rank fusion (RRF) to merge keyword and vector scores internally, so no external Azure Functions score-merging logic is needed.

Option A is correct because Azure AI Search scales along two independent dimensions: replicas provide query throughput and high availability, while partitions provide index storage and write parallelism, so right-sizing both to your QPS and index size is the core capacity-planning practice. Option C is correct because scalar quantization compresses float32 vectors to narrower types (for example int8), cutting memory usage and speeding up HNSW graph traversal with only modest recall loss, which improves cost-efficiency at high scale. Option D is correct because Azure Monitor exposes search unit metrics such as CPU, memory, and storage utilization, letting you detect saturation and resize replicas or partitions before performance degrades.

Option B is wrong because vector fields hold numeric embeddings, not raw PDF binaries, which belong in blob storage or a separate content field. Option E is wrong because the Free tier has no SLA, tiny storage and index limits, and cannot support a high-scale production workload.

Option A is correct because Azure RBAC provides fine-grained authorization over Azure AI Search, allowing you to separate roles such as Search Service Contributor (index management) from Search Index Data Reader/Contributor (query and data access), enforcing least privilege on sensitive indexes. Option B is correct because Microsoft Entra ID managed identities let Azure services authenticate to Azure OpenAI and Azure AI Search without embedding credentials, eliminating secret sprawl and enabling token-based access that can be scoped and audited. Option E is correct because Azure Private Endpoints assign private IP addresses from your VNet to Azure AI Search and Azure OpenAI, keeping traffic on the Microsoft backbone and blocking public internet exposure of these services.

Option C is wrong because disabling TLS would expose embedding payloads and queries to interception; TLS 1.2+ must remain enforced. Option D is wrong because storing API keys in plain text on public web servers directly exposes credentials, violating secret-management best practices such as Azure Key Vault or managed identities.

Option A is correct because Azure AI Search is purpose-built as a search engine that natively supports full-text search using the BM25 ranking algorithm as well as hybrid search that combines keyword and vector queries, which Cosmos DB for NoSQL does not provide out of the box. Option D is correct because Azure AI Search includes built-in semantic re-ranking (semantic ranker/L2 reranking) that reorders results using deep-learning models to improve relevance and accuracy, a capability Cosmos DB for NoSQL lacks natively. Option B is not a factor favoring Azure AI Search, since petabyte-scale storage is a strength of Cosmos DB for NoSQL rather than a search service.

Option C is not a factor favoring Azure AI Search, because high-frequency transactional ACID updates to metadata are handled by Cosmos DB for NoSQL's transactional capabilities, not by a search index. Option E is not a factor favoring Azure AI Search, as lowest possible database-level latency is a characteristic of Cosmos DB for NoSQL's globally distributed, low-latency data plane rather than the search service.

When creating a vector profile in Azure AI Search, the two required parameters are the profile's name and the algorithm configuration it references. Option B (name) is correct because every vector profile must have a unique name within the search index so it can be referenced by vector fields via the vectorSearchProfile property. Option A (algorithm) is correct because a vector profile must point to a configured vector search algorithm (for example, an HNSW or exhaustive KNN configuration defined in the index's algorithms collection) that determines how the vector index is built and queried.

Options C (sqlConnectionString), D (vmSize), and E (cosmosDatabaseName) are incorrect because they are unrelated to Azure AI Search vector profile definitions: sqlConnectionString and cosmosDatabaseName pertain to data source connections for indexers, and vmSize relates to compute sizing in other Azure services, not to vector profile configuration.

Option A is correct because Azure Cosmos DB restore operations always create a new account (or restore into a new account) rather than overwriting the existing account, which is the standard mechanism for both periodic and continuous backup restores. Option C is correct because the periodic backup mode supports configurable backup intervals and retention periods (with defaults of every 4 hours and 2 copies retained, extendable via support), letting you tailor the schedule to your RPO needs. Option D is correct because continuous backup mode enables point-in-time restore (PITR) for the last 30 days (or 7 days in some configurations), which is ideal for protecting vector embedding data against accidental deletes or corruption.

Option B is not applicable because Cosmos DB for NoSQL is not SQL Server and does not use .bak files or native SQL Server restore tooling. Option E is not a supported capability because Cosmos DB does not provide FTP-based manual file export into local VM storage as a backup mechanism.

Option A is correct because both Azure AI Search (via OData filter expressions in the query) and Azure Cosmos DB for NoSQL (via a WHERE clause on non-vector fields in the VectorDistance query) allow pre-filtering results on scalar/non-vector document properties. Option C is correct because both services support HNSW (Hierarchical Navigable Small World) as an approximate nearest neighbor indexing algorithm for vector fields. Option E is correct because both platforms perform similarity search by computing vector distance metrics such as cosine, dot product, or Euclidean distance.

Option B is incorrect because Semantic Ranker is a feature exclusive to Azure AI Search and is not available in Cosmos DB for NoSQL. Option D is incorrect because neither service automatically translates SQL into vector queries; Cosmos DB uses its own SQL-like syntax with the VectorDistance function, and Azure AI Search uses its own query DSL, so no such automatic translation exists.

Option D is correct because the vector embedding policy must specify the "path" — the JSON property path in each document that holds the vector array — so Cosmos DB knows which field to index for vector search. Option E is correct because the policy must also declare the vector's "dataType" (e.g., float32, float16, int8) and "dimensions" (e.g., 1536), which define the element type and length of the vector array and must match the actual embeddings. The container partition key definition (A) is set in the container's key definition, not the vector embedding policy, and is unrelated to vector indexing.

BM25 k1 and b parameters (B) belong to full-text search scoring configuration, not vector search. Replication lag threshold (C) is a consistency/global replication setting and has no place in a vector embedding policy.

Option A is correct because HNSW parameters directly control the approximate nearest neighbor graph: increasing m improves recall at the cost of memory and index build time, while efSearch tunes the query-time candidate list to balance recall against latency, making it a core lever for hybrid search relevance. Option B is correct because Reciprocal Rank Fusion (RRF) merges the ranked result lists from keyword (BM25) and vector queries into a single ranking using 1/(k + rank) scoring, which is exactly how Azure AI Search combines lexical and vector results in hybrid mode. Option C is correct because the semantic ranker applies deep-learning re-ranking (Microsoft's cross-encoder models) over the top results, promoting semantically relevant documents that lexical or vector scores alone may rank lower.

Option D is not correct because disabling OData filters does not improve vector recall and removes useful precision controls; filters are applied alongside vector search to narrow the candidate set. Option E is not correct because storing embeddings as uncompressed plaintext in Blob Storage is inefficient and unrelated to search relevance; embeddings should be stored in the search index as Collection(Edm.Single) vectors, ideally with compression such as scalar or binary quantization.

Option A is correct because Azure AI Search natively supports an Azure Cosmos DB data source for indexers, which reads the container's change feed (including inserts, updates, and deletes when soft-delete/change-feed policies are configured) and incrementally pushes documents into the vector index. Option B is correct because Azure Cosmos DB emits container mutation events to Azure Event Grid, which can trigger downstream orchestration (for example, Functions, Logic Apps, or custom handlers) that updates Azure AI Search documents via its REST/SDK APIs. Option C is correct because the Azure Cosmos DB change feed can be consumed by an Azure Function trigger, and the function can call the Azure AI Search REST API (for example, the index or merge-or-upload actions) to upsert vectors and fields in near real time.

Option D is not appropriate because a full scan plus drop-and-rebuild every 5 minutes is a costly, high-latency batch pattern rather than an incremental synchronization mechanism, and Azure Data Factory is not the recommended vector-index sync path. Option E is not a real capability: Azure Cosmos DB does not provide native bidirectional memory-mapped replication to Azure AI Search replicas; synchronization must be implemented through indexers, change feed consumers, or event-driven pipelines.

Option A is correct because the HNSW efSearch parameter controls the size of the dynamic candidate list during vector search; lowering efSearch reduces the number of distance computations, cutting latency at some cost to recall, which is exactly the recall/latency trade-off needed under heavy vector query loads. Option C is correct because scalar quantization compresses float32 vectors into smaller representations (e.g., int8), reducing memory footprint and memory bandwidth pressure so more vectors fit in RAM and queries execute faster. Option E is correct because adding search replicas horizontally distributes query traffic across multiple nodes, increasing concurrent query throughput and preventing any single node from becoming a latency bottleneck.

Option B is incorrect because disabling caching removes a latency-reducing mechanism and pushing documents per partition beyond limits is unsupported and degrades performance. Option D is incorrect because exhaustive k-NN scans every vector for each query, which dramatically increases compute and latency and is unsuitable as a default under heavy load.

Option C is correct because Azure AI Search supports security trimming via OData filter expressions such as tenantId eq 'tenant-1' applied to vector queries, which enforces tenant isolation by restricting results to documents matching the caller's tenant identifier while still allowing shared indexes. Option E is correct because provisioning dedicated indexes or service tiers for enterprise tenants provides physical/logical isolation and dedicated compute, ensuring predictable vector search latency and strict data separation for high-compliance customers. Option A is wrong because disabling HNSW and relying on exhaustive brute-force (exhaustive KNN) search sacrifices scalability and latency, and brute-force across all tenant partitions does not provide tenant isolation.

Option B is wrong because storing all tenants' embeddings in a single unpartitioned vector field without metadata tags prevents filtering and security trimming, breaking tenant isolation. Option D is wrong because moving embeddings to Blob Storage and computing cosine similarity client-side eliminates Azure AI Search's optimized vector indexing and integrated filtering, harming performance and isolation.

In Azure Cosmos DB for NoSQL, the vector embedding policy's "distanceFunction" property accepts exactly three values: cosine, dotproduct, and euclidean. Option D (euclidean) is correct because Euclidean distance is one of the natively supported metrics, measuring straight-line distance between vectors and typically used with normalized or unnormalized embeddings. Option E (cosine) is correct because cosine similarity is the default and most commonly used metric, measuring the angle between vectors and ideal for text embeddings where magnitude is irrelevant.

Option A (hamming) is not supported; it applies to binary/categorical string comparison, not the float32 vector indexes Cosmos DB builds. Option B (manhattan) is not supported; only cosine, dotproduct, and euclidean are valid distanceFunction values. Option C (jaccard) is not supported; it is a set-similarity measure used in data mining, not a Cosmos DB vector distance metric.

Option A is correct because Azure AI Search validates vector length at ingestion time: if the source vector has more (or fewer) dimensions than the index field's configured 'dimensions' value, the indexer fails with a dimension mismatch error. Option D is correct because the vector field must be defined as Collection(Edm.Single) (or another supported vector type) and the source data must supply a numeric array; an array of strings or other non-numeric type cannot be cast to the vector field and causes ingestion to fail. Option B is not a valid reason because a deprecated embedding model still produces numeric vectors that the indexer can ingest; deprecation affects the model's availability, not the indexer's type/dimension validation.

Option C is not a valid reason because marking a Collection(Edm.Single) field as 'filterable' is a supported configuration (though it consumes extra storage) and does not by itself cause ingestion failure. Option E is not a valid reason because an 'AzureOpenAI' skill is only needed to generate embeddings at index time; if the source already contains vectors, no such skill is required, and its absence does not cause an ingestion failure.

Option A is correct because Normalized RU consumption across physical partitions is the key Azure Cosmos DB metric for detecting hot spotting; if one physical partition consistently shows much higher normalized RU usage than others, vector search throughput is throttled by that partition. Option D is correct because the RU charge returned in each query response header (x-ms-request-charge) reveals the actual cost of each vector query, letting you identify expensive queries and compare them against provisioned throughput. Option E is correct because vector indexing in Cosmos DB for NoSQL is performed by an index transformation, and if that transformation is still in progress or stuck, vector queries may scan more data, return incomplete results, or run slower, so checking index transformation progress is essential.

Option B is not relevant because Blob Storage access tiers (Hot vs Cool) affect blob storage cost and latency, not Cosmos DB vector query performance. Option C is not relevant because App Service SSL certificate expiration affects HTTPS connectivity to a web app, not the internal performance of Cosmos DB vector search.

Option B (vectorEmbeddingPolicy) is correct because the container's indexing policy must declare the vector embedding policy, which defines the vector paths, data type (e.g., float32), dimensions, and distance function (cosine, dotproduct, or euclidean) so Cosmos DB knows how to interpret and compare the stored embeddings. Option C (vectorIndexes) is also correct because the indexing policy must include a vectorIndexes section that specifies the vector path and the index type (flat, quantizedFlat, or diskANN) used to perform the similarity search. Together, vectorEmbeddingPolicy and vectorIndexes are the two required elements inside the indexing policy for vector search on Azure Cosmos DB for NoSQL.

Option A (fullTextPolicy) is incorrect because it relates to full-text search (full-text indexing and scoring), not vector search. Option D (spatialIndexes) is incorrect because it configures geospatial indexing for GeoJSON data, which is unrelated to vector similarity. Option E (partitionKeyDefinition) is incorrect because the partition key is defined at the container level, not within the indexing policy.