AI-200: Connect to and Consume Azure Services

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Connect to and Consume Azure Services

A Python Azure Function app is deployed to Azure. The function has this binding metadata and fails to start the listener because the connection value cannot be resolved. Which Function App configuration setting should you add?

{
  "type": "serviceBusTrigger",
  "queueName": "embedding-jobs",
  "connection": "JobsBus"
}

Options:

• A. JobsBus with the Service Bus connection string

• B. FUNCTIONS_WORKER_RUNTIME set to servicebus

• C. AzureWebJobsStorage with the Service Bus connection string

• D. ServiceBus__queueName set to embedding-jobs

Best answer: A

Explanation: Azure Functions bindings resolve the connection property from Function App application settings. In this case, the Service Bus trigger specifies connection: "JobsBus", so the deployed Function App must have an application setting named JobsBus that contains the connection information for the Service Bus namespace. Values in local.settings.json are for local development and are not automatically available after deployment.

The key point is that the setting name must match the binding’s connection value, not the queue name or the worker runtime.

• Storage setting confusion fails because AzureWebJobsStorage is for the Functions host storage account, not the Service Bus trigger connection.
• Worker runtime confusion fails because FUNCTIONS_WORKER_RUNTIME identifies the language worker, such as Python, not a Service Bus extension.
• Queue name setting fails because the queue name is already specified in the binding metadata and does not supply credentials.

Question 2

Topic: Connect to and Consume Azure Services

An ingestion service publishes custom events to an Azure Event Grid topic. The embed-worker Azure Function subscription currently has these filters: subjectBeginsWith=/documents/ and includedEventTypes=DocumentClassified. The function should receive only events that start vector indexing.

Trace:

Which subscription change routes only relevant events to the Function?

Options:

• A. Enable dead-lettering for legal-review events.

• B. Add only DocumentClassified to included event types.

• C. Add an advanced filter: data.workflow StringIn vector-index.

• D. Change the subject prefix to /documents/contoso/.

Best answer: C

Explanation: Event Grid event subscriptions can filter by subject, event type, and advanced filters over event data fields. In the trace, the unwanted legal-review event has the same subject prefix and event type as the desired vector-index event. The only visible field that distinguishes the relevant workflow is data.workflow, so the subscription needs an advanced filter on that property before delivery to the Azure Function. Subject and event type filters are useful, but they are already too broad for this workflow.

Dead-lettering handles events that cannot be delivered successfully; it does not select events based on business content.

• Subject narrowing still allows the legal-review document event because it is also under the Contoso documents path.
• Event type filtering is already present, and both delivered document events have DocumentClassified.
• Dead-lettering is for delivery failures, not for excluding events that match a workflow value.

Question 3

Topic: Connect to and Consume Azure Services

A containerized Python service creates embeddings for uploaded documents. The API must submit durable work items to Azure Service Bus so scaled worker replicas can drain the backlog. Each document should be processed by only one replica, and repeatedly failing work items must be retained for later inspection. Which configuration best matches this behavior?

Options:

• A. Use a Service Bus queue with competing consumers and dead-letter handling.

• B. Use a Service Bus topic with one subscription per worker replica.

• C. Use Event Grid custom events with each worker as an event handler.

• D. Use a Service Bus queue and manually re-enqueue every failed message.

Best answer: A

Explanation: Azure Service Bus queues fit command-style back-end work where each message represents a unit of work that should be handled by one consumer. Multiple worker replicas can listen to the same queue as competing consumers, allowing the backlog to scale out without duplicating processing for every replica. For work items that repeatedly fail, Service Bus dead-letter handling provides a separate place to inspect poison messages instead of losing them or blocking new work. A topic/subscription pattern is better when multiple independent subscribers each need their own copy of the same message.

• Per-replica subscriptions would broadcast a copy to each worker subscription, causing duplicate document processing.
• Event Grid handlers are better for event notification, not durable command-style queue processing with competing consumers.
• Manual re-enqueue risks creating retry loops and ignores the built-in dead-letter pattern for poison messages.

Question 4

Topic: Connect to and Consume Azure Services

A Python worker consumes the validate subscription on the Azure Service Bus topic orders. After a schema deployment, the dead-letter count rose from 0 to 1,240. A sampled dead-lettered message shows:

DeadLetterReason: SchemaValidationFailed
DeadLetterErrorDescription: missing customerId
Application properties: traceparent, sourceFile, schemaVersion
Body: can be corrected from source record

You need to replay corrected messages without losing the diagnostic context. What should you do next?

Options:

• A. Edit the DLQ message body and renew the lock until processed

• B. Receive in peek-lock, copy diagnostics, resend corrected messages, then complete originals

• C. Complete DLQ messages first, then rebuild them from application logs

• D. Abandon DLQ messages so Service Bus retries the subscription

Best answer: B

Explanation: Azure Service Bus dead-lettered messages should be handled as diagnostic records until recovery is safely complete. Receive from the subscription dead-letter queue in peek-lock mode, inspect and preserve DeadLetterReason, DeadLetterErrorDescription, correlation or trace properties, and relevant application properties. Then create a corrected message, include the needed diagnostic context in application properties or an audit store, send it back through the topic with the required routing properties, and complete the original dead-lettered message only after the send succeeds. If the resend fails, the original remains available for another recovery attempt. The key takeaway is to copy context before removing the DLQ message.

• Complete first loses the safest recovery record if the rebuild or resend fails.
• Abandoning DLQ messages does not replay them to the original subscription; they remain dead-lettered.
• Editing in place is not the Service Bus recovery model; create and send a corrected message copy.

Question 5

Topic: Connect to and Consume Azure Services

An Azure Service Bus queue feeds a Python worker that calls an AI enrichment API. The business wants lower end-to-end latency. After a deployment enabled prefetching, queue depth and dead-letter counts increased.

Exhibit: Current evidence

Which operational action should you take next?

Options:

• A. Reduce prefetchCount to match concurrency and processing time.

• B. Increase maxDeliveryCount so messages avoid the DLQ.

• C. Increase lockDuration while keeping prefetchCount=200.

• D. Scale out workers without changing prefetchCount.

Best answer: A

Explanation: Service Bus prefetch can improve throughput only when prefetched messages are processed before their locks expire. Here, each worker can process only 8 messages concurrently, while 200 messages may be locked into the local cache. With 35-45 second handlers and a 60-second lock, many messages can expire before the handler even starts. The MessageLockLostException, high delivery count, and DLQ reason show that repeated redelivery is wasting capacity and increasing latency. Reducing or temporarily disabling prefetch aligns locked messages with actual processing capacity; after lock losses stop, concurrency or scale-out can be tuned safely.

• Higher delivery count hides the symptom longer but does not stop lock expiration or repeated processing.
• More workers only may create more locally prefetched locked messages and can amplify redelivery.
• Longer locks only does not fix a prefetch backlog far larger than the safe processing window.

Question 6

Topic: Connect to and Consume Azure Services

A back-end API receives requests to generate embeddings for uploaded documents. The API must return quickly, the work must be retained if processors are unavailable, and other services must be notified only after processing completes.

Flow:

Client -> HTTP API -> Step 1 -> Step 2 -> Cosmos DB
                              -> Step 3 -> subscribers

Which mapping correctly completes the flow?

Options:

• A. Step 1 App Configuration key; Step 2 timer-triggered Function; Step 3 Key Vault secret

• B. Step 1 HTTP-triggered Function; Step 2 synchronous embedding call; Step 3 API response

• C. Step 1 Event Grid event; Step 2 event-triggered Function; Step 3 Service Bus queue message

• D. Step 1 Service Bus queue; Step 2 queue-triggered Function; Step 3 Event Grid event

Best answer: D

Explanation: For a long-running AI back-end operation, separate the intake path from the processing path. The HTTP API should accept the request and enqueue a durable command so the work survives processor downtime and can be retried or dead-lettered. An Azure Function can use a Service Bus trigger to execute the embedding operation asynchronously. After the function stores the result, Event Grid is appropriate for completion notification because subscribers react to a fact that already happened.

The key distinction is command processing versus event notification: Service Bus queues are for reliable work items, while Event Grid is for publishing completion events to interested subscribers.

• Starting with Event Grid treats the embedding request like a notification, not a durable work command that processors can backlog.
• Synchronous Function processing conflicts with the requirement for the API to return quickly and tolerate unavailable processors.
• Configuration and secrets do not provide request intake, queued work execution, or subscriber notification.

Question 7

Topic: Connect to and Consume Azure Services

A back-end API currently sends each completed operation as one message to a Service Bus queue. A new release adds three independent consumers: fulfillment needs only shipment operations, billing needs only charge and refund operations, and analytics needs all operations. The message contract already includes an operationType property. What is the best next implementation step?

Options:

• A. Have the API send duplicate messages to three queues.

• B. Increase the queue lock duration before adding consumers.

• C. Attach all three consumers to the existing queue.

• D. Create a Service Bus topic with filtered subscriptions per consumer.

Best answer: D

Explanation: Service Bus topics and subscriptions are designed for publish-subscribe fan-out when multiple consumers need different views of the same published operation stream. The API should publish each operation once to a topic. Each consumer reads from its own subscription, and subscription filters can use operationType so fulfillment, billing, and analytics receive the appropriate messages independently. This avoids competing-consumer behavior on a single queue, where one consumer receives a message and the others do not. It also avoids pushing routing and duplication logic into the API. Queue tuning settings such as lock duration are useful for processing behavior, not for delivering different filtered views to multiple consumers.

• Single queue consumers fail because queue consumers compete for messages instead of each receiving the operation stream.
• Duplicate queue sends add publisher-side routing and duplication that topics and subscriptions are meant to handle.
• Lock duration tuning is premature because it does not solve fan-out or consumer-specific filtering.

Question 8

Topic: Connect to and Consume Azure Services

A Python API receives user requests for a RAG feature and uses the Azure Service Bus SDK to enqueue work for an Azure Function. Users report that requests fail before a job ID is returned.

Observed evidence:

span: POST /rag/request
child span: ServiceBusSender.send_messages
status: Error
exception: UnauthorizedAccessException
message: status-code: 403
queue incoming messages: 0
dead-letter messages: 0
model endpoint spans: none

Which root cause best fits the evidence?

Options:

• A. The Azure Function is abandoning messages repeatedly.

• B. The API identity lacks permission to send to Service Bus.

• C. The model is producing invalid RAG responses.

• D. The vector store query is timing out.

Best answer: B

Explanation: The evidence points to an Azure service consumption boundary, not to AI product behavior. The failing span is ServiceBusSender.send_messages, and the exception is a 403 authorization failure. Because the queue shows no incoming or dead-letter messages and there are no model endpoint spans, the request does not reach the worker, vector retrieval, or model-generation stages. The next focus should be the API’s Service Bus authentication and authorization, such as the managed identity role assignment or configured credential used by the SDK. Business-level RAG behavior can only be investigated after the service call succeeds.

• Model behavior is not supported because no model endpoint span appears in the trace.
• Function processing is unlikely because no messages are entering the queue or dead-lettering.
• Vector timeout is contradicted by the failure occurring before retrieval starts.

Question 9

Topic: Connect to and Consume Azure Services

A team has deployed a Python function that generates embeddings for product manuals. New manuals are uploaded to an Azure Storage container. The workflow should start when a blob is created and pass event metadata so the function can read the blob. There is no need for competing workers to process command messages. What should you implement next?

Options:

• A. Add Azure Managed Redis before triggering enrichment.

• B. Create an Event Grid subscription for blob-created events.

• C. Add a timer trigger that scans the container.

• D. Create a Service Bus queue for upload commands.

Best answer: B

Explanation: Azure Event Grid is designed for event-driven workflows where a service reacts to something that already happened, such as a new blob being created. In this scenario, the upload is the event source and the embedding function is the event handler. Creating an Event Grid subscription for blob-created events connects those pieces directly and passes event metadata that the function can use to locate the blob. Service Bus is better when an application sends command messages that must be processed by consumers, often with brokered queue semantics. Here, the requirement is notification and reaction to an event, not command processing.

• Service Bus queue solves command-style message processing, but the stem describes reacting to storage events.
• Timer scanning adds polling delay and unnecessary complexity when the storage event can trigger the workflow.
• Managed Redis may help caching later, but it does not connect the blob-created event to the function.

Question 10

Topic: Connect to and Consume Azure Services

A RAG service lets tenants request a full re-embedding job. Each request is intentional work that must be handled by one worker, retried, and dead-lettered if it cannot complete. Other services only need to be notified after the job finishes. Which configuration should you use?

Options:

• A. Service Bus topic for requests; all subscriptions execute each job.

• B. Event Grid topic for requests; Service Bus queue for completions.

• C. Event Grid topic for requests; Event Grid subscriptions for workers.

• D. Service Bus queue for requests; Event Grid topic for completions.

Best answer: D

Explanation: Command-driven work represents an instruction to perform an action, usually with ownership, retries, and dead-letter handling. A Service Bus queue is the right fit for the re-embedding request because one worker should claim and process each job. Event-notification-driven work announces that something already happened and can fan out to multiple independent consumers. Publishing the completion through Event Grid lets other services react without owning the original job execution.

The key distinction is intent: use Service Bus for the command to do work, and use Event Grid for the notification that work has completed.

• Event request fails because Event Grid is better for notifications than owned command execution by one worker.
• Queued completion limits a completion announcement to a competing consumer pattern instead of event fan-out.
• Topic per worker can duplicate job execution across subscriptions, which violates the one-worker requirement.

Continue with full practice

Use the AI-200 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AI-200 on Web View AI-200 Practice Test

Related focused pages

• Free AI-200 Full-Length Practice Exam
• Develop Containerized Solutions on Azure
• Develop AI Solutions by Using Azure Data Management Services
• Secure, Monitor, and Troubleshoot Azure Solutions

Free review resource

Read the AI-200 Cheat Sheet for compact concept review before returning to timed practice.