AI-200 Practice Questions

To reduce both query latency and Request Unit (RU) consumption in Azure Cosmos DB, lowering the consistency level to eventual consistency is highly effective, as it consumes half the RUs for read operations compared to strong consistency and offers the lowest read latency. Additionally, implementing a composite indexing policy for frequently used filter attributes and query predicates ensures the database engine can efficiently evaluate filters before or during the vector search, significantly reducing the search space and the RUs required to process the query.

A: Increasing provisioned throughput accommodates higher RU usage but does not reduce actual RU consumption.

C: Removing indexes on filter attributes would force cross-partition or full scans, drastically increasing RU consumption and latency.

D: Strong consistency doubles the RU cost for reads and increases latency; full-text indexing does not optimize vector similarity searches.

1. Microsoft Learn: "Consistency levels in Azure Cosmos DB" - Section: Consistency levels and throughput.

2. Microsoft Learn: "Vector search in Azure Cosmos DB for NoSQL" - Section: Indexing policies and vector search optimization.

To authenticate to Azure Key Vault without storing credentials in application files, the API should utilize a system-assigned managed identity (D). This identity is tied directly to the lifecycle of the specific application resource, which inherently minimizes the blast radius if the application is compromised. To enforce the principle of least privilege, this managed identity must be granted the Key Vault Secrets User role specifically at the vault scope (C). This ensures the identity only has the minimum permissions necessary to read secret contents and cannot manage the vault or access other resources within the subscription.

A. Storing secrets in App Configuration contradicts the requirement to use Key Vault for secrets and does not solve the authentication challenge.

B. Assigning the Key Vault Administrator role at the subscription scope violates the principle of least privilege and maximizes the blast radius.

Microsoft Learn: "Provide access to Key Vault keys

certificates

and secrets with an Azure role-based access control" (Section: Assign the Key Vault Secrets User role).

Microsoft Learn: "What are managed identities for Azure resources?" (Section: System-assigned managed identity).

In Azure Cosmos DB for NoSQL, vector embeddings are large arrays. If not explicitly excluded from the standard indexing policy, Cosmos DB attempts to index every element, leading to excessive Request Unit (RU) consumption and storage costs. Vector indexes are defined separately, so the vector field must be excluded from standard indexing. Additionally, Strong consistency requires reading from a quorum, which doubles the RU cost for read operations compared to Eventual consistency. Switching to Eventual consistency reduces RU consumption and improves read latency.

A. Incorrect because Cosmos DB does not support composite indexes that combine scalar fields with vector embedding properties.

C. Incorrect because replicating data via change feed does not improve the query performance or reduce RU consumption of the primary database.

- Microsoft Learn: "Vector search in Azure Cosmos DB for NoSQL"

Section: Vector indexing policies. (https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/vector-search)

- Microsoft Learn: "Consistency levels in Azure Cosmos DB"

Section: Consistency levels and throughput. (https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels)

To ensure data consistency and prevent serving outdated data, the most effective caching strategy is to trigger cache invalidation when the underlying source data changes. This proactive approach guarantees that the AI inference API will fetch the latest data on the next request, minimizing the risk of stale data while avoiding the overhead of excessively short expiration times or complex synchronization mechanisms.

A. Resetting expiration on read (sliding expiration) prolongs the life of potentially stale data if it is frequently accessed.

B. Disabling expiration ensures data remains in the cache indefinitely, leading to highly outdated data being served.

C. The allkeys-lru eviction policy manages memory by removing least recently used keys; it does not ensure data freshness.

Microsoft Learn: Caching guidance - Azure Architecture Center. Section: "Managing data consistency" and "Cache invalidation". Document ID: azure/architecture/best-practices/caching.

To receive messages from an Azure Service Bus queue using modern Azure SDKs, a specific initialization sequence is required to establish connections and configure the event-driven processing loop.

First, instantiate a ServiceBusClient to authenticate and establish a connection to the Service Bus namespace. Second, use this client to create a ServiceBusProcessor scoped to the specific target queue. Third, before the processor can consume messages, you must register event handlers (e.g., ProcessMessageAsync and ProcessErrorAsync) to define the business logic for incoming messages and connection errors. Finally, start the message processor to initiate the asynchronous message pump. Dead-lettering a message is an operational action executed within the message handler itself, not a configuration step.

Microsoft Learn. (2023). Quickstart: Send and receive messages from an Azure Service Bus queue (.NET). Azure Service Bus Documentation. Section: "Receive messages". Retrieved from Microsoft official documentation. This document details the architectural sequence of initializing the ServiceBusClient, creating the ServiceBusProcessor, hooking up the ProcessMessageAsync and ProcessErrorAsync handlers, and invoking StartProcessingAsync().

Microsoft Learn. (2023). Azure.Messaging.ServiceBus Namespace. Azure SDK for .NET. Section: "ServiceBusProcessor Class". Retrieved from Microsoft official documentation. Details the lifecycle and required handler registration before calling the start method.

To use a custom domain in Azure Container Apps, the app must first have ingress enabled to receive external traffic and generate an initial endpoint. Next, you initiate the configuration in the Azure portal by adding the custom domain name to the app, which generates a unique domain verification code. You then use this code to add the necessary DNS records (such as A/CNAME and TXT records) at your domain provider. Once the DNS records are created, you return to the Azure portal to validate the ownership of the custom domain name. Finally, after successful validation, you bind the TLS/SSL certificate to the custom domain to secure the connection and enable HTTPS access.

Microsoft Azure Official Documentation: "Custom domain names and certificates in Azure Container Apps"

Section: Add a custom domain and managed certificate.

Details: This document outlines the exact sequential workflow required in the Azure Portal, verifying that HTTP ingress must be enabled before adding the domain, followed by DNS propagation, validation, and certificate binding.

Link: https://learn.microsoft.com/en-us/azure/container-apps/custom-domains-certificates

Microsoft Azure Official Documentation: "Custom Domain Names and Free Managed Certificates in Container Apps"

Section: Domain Validation and Certificate Binding steps.

Details: Specifies the requirement of generating the domain validation code (asuid TXT record) by first adding the custom domain name in Azure, applying it to the DNS provider, validating it, and then securing it with a managed or custom certificate.

Link: https://learn.microsoft.com/en-us/azure/container-apps/custom-domains-managed-certificates

To test a new revision without affecting production traffic, configure the container app to use Multiple revision mode. Single revision mode automatically routes all traffic to the latest deployed revision upon readiness, whereas Multiple revision mode supports the concurrent activation of multiple versions. This enables direct access to new revisions via specific endpoints without shifting primary ingress traffic. To allocate a specific percentage of incoming requests to a secondary version (e.g., 20%), configure Traffic splitting. This feature requires Multiple revision mode and allows the proportional distribution of HTTP traffic among active revisions to facilitate A/B testing or blue-green deployments. "Traffic isolation" is not a valid revision management configuration in Azure Container Apps.

Microsoft Learn. (2025). Traffic splitting in Azure Container Apps. Section: Update existing revision. https://learn.microsoft.com/en-us/azure/container-apps/traffic-splitting

Microsoft Learn. (2025). Update and deploy changes in Azure Container Apps. Section: Revision modes / Work with multiple revisions. https://learn.microsoft.com/en-us/azure/container-apps/revisions

Yes: The Python code uses r.hset() on line 10. In Redis, HSET is used to set the string value of a hash field. Therefore, the embedding is being stored as a field ("embedding") within a hash map stored at the key "doc:1".

No: Merely storing vector bytes in a hash field does not enable similarity search. To perform vector similarity searches in Redis (using the RediSearch module), you must explicitly create an index on the data using the FT.CREATE command, defining a schema that specifies the vector field, dimensionality, and distance metric (e.g., COSINE, L2). The provided code lacks this index creation step.

Yes: The code uses r.expire("doc:1", 600) on line 11. The EXPIRE command in Redis sets a timeout on a key in seconds. 600 seconds is mathematically equivalent to exactly 10 minutes.

Redis Documentation (HSET): Redis command reference for HSET, detailing how it sets fields in the hash stored at a key. (Available at redis.io/commands/hset)

Redis Documentation (Vector Similarity): Redis documentation on Vector Similarity Search, which explicitly states that an index must be created (FT.CREATE) over hashes or JSON documents to query vectors. (Available at redis.io/docs/interact/search-and-query/search/vectors)

Redis Documentation (EXPIRE): Redis command reference for EXPIRE, confirming the timeout parameter is represented in seconds. (Available at redis.io/commands/expire)

By default, the Azure Service Bus Python SDK creates receivers in PeekLock mode (ServiceBusReceiveMode.PEEK_LOCK).

1. In PeekLock mode, messages are not removed immediately upon receipt; they are hidden from other consumers for a specific lock duration. The receiver must explicitly call a completion method to remove the message from the queue.
2. If message processing fails or the receiver crashes before completing the message, the lock will eventually expire. Once the lock expires, the message becomes visible again in the queue and can be picked up and retried by another consumer.
3. If a message contains an invalid payload (such as malformed JSON) that causes an unhandled exception during processing, the message will not be completed. It will continuously reappear in the queue after its lock expires until it reaches the queue's configured max_delivery_count, at which point it is automatically moved to the dead-letter queue (DLQ).

Microsoft Learn: Azure Service Bus - Receive Modes. Details the default PeekLock behavior requiring explicit message settlement. (https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-transfers-locks-settlement)

Microsoft Learn: Azure Service Bus - Dead-letter queues. Explains how the MaximumDeliveryCount property works when messages fail to process and locks expire. (https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues)

Azure SDK for Python Documentation: azure.servicebus.ServiceBusReceiver. Confirms ServiceBusReceiveMode.PEEK_LOCK as the default argument for get_queue_receiver. (https://learn.microsoft.com/en-us/python/api/azure-servicebus/azure.servicebus.servicebusclient)

In Azure Cosmos DB, the default consistency level applied to newly provisioned accounts is Session. You can override this default consistency level on a per-request basis, but this override applies exclusively to read operations within the SDK client. Because overrides do not affect the write path, write operations will always execute using the account's configured default consistency level and will ignore any per-request client configuration. Therefore, configuring the request for a consistent prefix successfully downgrades the read operation to consistent prefix, while the write operation remains securely at the default session consistency.

1: Microsoft Learn, "Manage consistency levels in Azure Cosmos DB", Section: Utilize session tokens. (Document ID: how-to-manage-consistency)

2: Microsoft Learn, "Consistency level choices", Section: Override the default consistency level. (Document ID: consistency-levels)