Q01 - Question
A claim workflow waits for an ApprovalResponse external event from an adjuster. The approval endpoint sometimes receives the same decision more than once. Adjusters also sometimes respond to an older review request after the workflow issues a new one. You must prevent duplicate approval records and stop outdated responses from changing the claim. Which two actions should you take? Each correct answer presents part of the solution.
Domain: Connect to and consume Azure services (20–25%) Type: Multiple choice
- A. Include a stable approval request ID and approval version in the event payload. Accept only events that match the current document and approval version.
- B. Treat the most recently arrived event as the current decision, and use arrival order to resolve conflicting responses.
- C. Use an activity that atomically records the first valid decision and reports whether the decision already exists.
- D. Poll the approval database from the orchestrator in a loop until a valid decision record appears.
A and C are correct.
Explanation: External events have an at-least-once delivery guarantee, and clients can also submit the same decision more than once. A stable approval request ID and version let the orchestrator accept only a response for the current review request. An activity that atomically records the first valid decision makes the business operation idempotent. A duplicate event then doesn't create a second approval record.
B is incorrect: Avoid using arrival order alone when several systems can raise events. The event payload and durable approval record must provide enough information to determine whether a response is current.
D is incorrect: Don't repeatedly poll from inside the orchestrator. An external event provides a more efficient resume signal, and the suspended orchestration doesn't hold a worker while it waits.
Q02 - Question
You create an event subscription for a real-time content classification handler. You set the event time-to-live (TTL) to 30 minutes and the maximum number of delivery attempts to 10. You don't configure any other delivery options. During a handler outage, operators must be able to review every event that Event Grid can't deliver, including the reason for each failure. What should you do?
Domain: Connect to and consume Azure services (20–25%) Type: Single choice
- A. Increase the maximum number of delivery attempts to 30. Event Grid then retains undelivered events until the handler recovers.
- B. Enable output batching so that Event Grid groups failed events and redelivers them in one request.
- C. Create a storage account and a Blob Storage container, and then specify that container as the dead-letter endpoint on the event subscription.
- D. Keep the current configuration. Event Grid sends events that exceed the retry limits to a dead-letter destination by default.
C is correct.
Explanation: When Event Grid exhausts all retry attempts or the event TTL expires, it can send the undelivered event to a dead-letter destination. You must create an Azure Blob Storage account and container before configuring it as the dead-letter endpoint. Each dead-lettered event includes diagnostic properties such as deadLetterReason and lastDeliveryOutcome for investigation.
A is incorrect: Event Grid stops retrying at whichever limit is reached first. With a 30-minute TTL, only about six delivery attempts complete, so increasing the maximum attempts has no additional effect. Without dead-lettering, the events are dropped.
B is incorrect: Output batching reduces HTTP overhead for high-throughput delivery but does not retain undeliverable events. A failed batch is retried as a whole.
D is incorrect: Dead-lettering is disabled by default. If you do not configure a dead-letter endpoint, events that exceed retry limits are dropped.
Q03 - Question
An orchestrator uses context.task_any() to race a document-processing activity against a durable timer. When the timer wins, the workflow marks the document as TimedOut. In some cases, the activity finishes later and writes a result that downstream systems treat as current. What should you do?
Domain: Connect to and consume Azure services (20–25%) Type: Single choice
- A. Have the activity check an operation record or cancellation flag when practical, make its write idempotent, and design the workflow to ignore a late result after its terminal deadline.
- B. Keep the current design, because the timer winning the task_any() race cancels the running activity.
- C. Replace the durable timer with time.sleep() in the orchestrator, and check the activity result after the delay.
- D. Increase the number of retry attempts for the activity so that it completes before the workflow deadline.
A is correct.
Explanation: A timer that wins a task_any() race doesn't automatically cancel an activity that already started. The activity can still finish and produce an external side effect. Use an operation record or cancellation flag that the activity checks when practical. Make the eventual write idempotent, and define a rule that ignores a late result after the terminal deadline.
B is incorrect: The timer doesn't stop the started activity, so the late write can still occur.
C is incorrect: Blocking waits such as time.sleep() don't belong in orchestrator functions. Durable timers record the deadline without keeping compute resources active.
D is incorrect: A retry policy limits attempts, while a timeout limits how long the workflow waits. More attempts add elapsed time and model quota use and don't prevent the late write.
Q04 - Question
An Event Grid event subscription delivers events to a webhook that starts an inference run. Each inference run takes about 60 seconds. You observe repeated deliveries, and some inference runs execute twice for the same event. You need to make delivery reliable and prevent duplicate inference runs. Which two actions should you take? Each correct answer presents part of the solution.
Domain: Connect to and consume Azure services (20–25%) Type: Multiple choice
- A. Return 202 (Accepted) as soon as the handler receives the event, and run the inference asynchronously.
- B. Return 400 Bad Request when a downstream vector database is temporarily unavailable.
- C. Store the event id of each processed event, and skip events with an id that the handler already processed.
- D. Set the maximum number of delivery attempts to 1 so that Event Grid never delivers the same event twice.
A and C are correct.
Explanation: Event Grid waits 30 seconds for a response and retries if the endpoint does not respond in time. For operations taking longer than 30 seconds, you should return 202 (Accepted) immediately and process the event asynchronously. Because Event Grid provides at-least-once delivery, you must also implement idempotent processing by tracking the event id to detect and deduplicate repeated deliveries.
B is incorrect: Event Grid does not retry 400 Bad Request responses. You should return a 503 status code if your service is temporarily overloaded or unavailable so that Event Grid will retry the delivery.
D is incorrect: Setting the maximum delivery attempts to 1 removes retries for transient failures such as service restarts and cold starts. Furthermore, at-least-once delivery guarantees mean duplicates might still be received even with a limit of 1.
Q05 - Question
Your document extraction workers use peek-lock mode, and some contract documents take up to eight minutes to process. Operations reports that these documents are sometimes processed twice by different workers. No inference request can be lost. You want the simplest code change in the processing loop. What should you do?
Domain: Connect to and consume Azure services (20–25%) Type: Single choice
- A. Set the queue lock duration to 10 minutes.
- B. Switch the receiver to receive-and-delete mode so that other workers can't receive the message again.
- C. Register each received message with an AutoLockRenewer and set max_lock_renewal_duration longer than the expected processing time.
- D. Increase the queue's max_delivery_count so that the message is redelivered more times before it is dead-lettered.
C is correct.
Explanation: When processing takes longer than the lock duration, the lock expires and Service Bus makes the message available to another consumer, which causes duplicate processing. The AutoLockRenewer class renews the lock in the background until the maximum renewal duration elapses. You don't need to add manual renewal calls to your processing loop.
A is incorrect: You can configure the queue lock duration up to a maximum of five minutes, so a 10-minute lock isn't possible.
B is incorrect: Receive-and-delete mode removes the message on delivery. If a worker crashes during inference, the request is lost.
D is incorrect: The max delivery count controls when a repeatedly failing message moves to the dead-letter queue. It doesn't stop the lock from expiring during long processing.
Q06 - Question
An orchestration processes a large claim archive with one flat fan-out/fan-in pattern. Measurements show that the fan-in step is slow because one orchestrator loads and aggregates every individual document result. You need to reduce the state that one orchestration handles. You also want an independent status for each part of the archive. What should you do?
Domain: Connect to and consume Azure services (20–25%) Type: Single choice
- A. Replace context.task_all() with sequential awaits so that the orchestrator aggregates one result at a time.
- B. Return the extracted text from each activity so that the orchestrator can aggregate results without extra storage reads.
- C. Increase the number of activities that the orchestrator schedules at once in the single flat fan-out.
- D. Partition the archive by policy or month. Use sub-orchestrations that return counts and result locations, and have the parent aggregate those summaries.
D is correct.
Explanation: One orchestrator performs the fan-in step on one worker at a time, so a flat fan-in can become a bottleneck. Sub-orchestrations let child orchestrations process separate partitions and return compact summaries. The parent aggregates those summaries instead of every document result. Each partition also gets an independent status.
A is incorrect: Sequential processing adds the latency of every item and doesn't reduce the results that one orchestrator must aggregate.
B is incorrect: Returning extracted text expands orchestration history, and Durable Functions must load that data during replay.
C is incorrect: Scheduling more work at once doesn't reduce the aggregation work in one orchestrator. A sudden activity burst can also exceed model rate limits or saturate a downstream data service.
Q07 - Question
An orchestrator calls a classification activity with call_activity_with_retry. The activity raises an exception when a claim's confidence score is below 0.80. Monitoring shows repeated model calls that return the same low score, and these calls consume model quota. Low-confidence claims must go to an adjuster for review. What should you do?
Domain: Connect to and consume Azure services (20–25%) Type: Single choice
- A. Increase max_number_of_attempts in RetryOptions so that the model has more chances to return a higher confidence score.
- B. Add a randomized delay in the orchestrator before each retry attempt to spread the model calls over time.
- C. Return a structured business outcome that includes the confidence score, and route low-confidence claims to an approval branch in the orchestrator.
- D. Catch the exception in the orchestrator, and call the classification activity again without a retry policy.
C is correct.
Explanation: A low confidence score is an expected business decision, not an infrastructure error. Activities should raise failures only when the orchestrator must treat them as technical errors. When the call succeeds but the content doesn't meet an application rule, return a structured outcome. The orchestrator can then route the claim through an explicit workflow branch without consuming retry attempts.
A is incorrect: Retries help only when another attempt can succeed without changing the request. More attempts consume more time, model quota, and function resources.
B is incorrect: Random behavior doesn't belong in orchestrator code because the orchestrator must stay deterministic during replay.
D is incorrect: Calling the activity again still repeats the model call. The low-confidence result still isn't routed to the approval step.
Q08 - Question
You maintain a Durable Functions app that processes insurance claim documents. The orchestrator passes full extracted document text to activities. Activities return complete model responses to the orchestrator. Replay time and storage operations are increasing. The orchestration history also retains sensitive claim content. What should you change?
Domain: Connect to and consume Azure services (20–25%) Type: Single choice
- A. Pass the full document text as orchestration input instead of activity input so that activities receive smaller payloads.
- B. Store the content in Azure Blob Storage, and pass a blob URL with compact metadata such as the document ID and confidence score.
- C. Compress the complete model responses inside the orchestrator before the orchestrator returns its result.
- D. Add a storage access token to the orchestration input so that each activity can read the content directly.
B is correct.
Explanation: Durable Functions serializes orchestration inputs, activity inputs, and activity outputs into the durable store. Large payloads increase storage operations, replay time, memory use, and the amount of sensitive data retained in history. Store large content in a data service such as Azure Blob Storage. Pass only a reference and the fields that the orchestrator needs for its next decision.
A is incorrect: Orchestration inputs are also serialized into orchestration history, so the full text stays in the durable store.
C is incorrect: The orchestrator still receives and handles the complete model responses. Keep large results out of the orchestration, write them from the activity, and return a reference.
D is incorrect: Don't place secrets or access tokens in orchestration inputs or outputs. Use managed identities and a service such as Azure Key Vault for credentials.
Q09 - Question
A function app has a system-assigned managed identity. One function writes classification results by using a Cosmos DB output binding configured with CosmosDBConnection__accountEndpoint. The same function calls Azure OpenAI Service through an SDK client that uses DefaultAzureCredential. You need to remove all connection strings and API keys and apply least privilege. Which two role assignments should you grant to the managed identity? Each correct answer presents part of the solution.
Domain: Connect to and consume Azure services (20–25%) Type: Multiple choice
- A. Key Vault Secrets User
- B. Cosmos DB Built-in Data Contributor
- C. Cognitive Services OpenAI User
- D. Azure Service Bus Data Sender
B and C are correct.
Explanation: An identity-based Cosmos DB connection uses the account endpoint, and the managed identity needs the Cosmos DB Built-in Data Contributor role to write documents. Azure OpenAI Service has no dedicated binding, so the SDK client authenticates with DefaultAzureCredential. In production, this credential uses the managed identity, which needs the Cognitive Services OpenAI User role.
A is incorrect: The Key Vault Secrets User role is required for Key Vault references. This design removes stored secrets, so the function does not read from Key Vault.
D is incorrect: The Azure Service Bus Data Sender role is for Service Bus output bindings. This function does not write to Service Bus, so the role adds access the function does not need.
Q10 - Question
Your classification service publishes com.contoso.ai.InferenceCompleted events to a custom topic. Each event payload includes a data.confidence value. You need high-confidence results above 0.9 to go to an automated publishing handler, and lower-confidence results to go to a separate handler. You want to avoid custom routing logic in your code. What should you configure on the event subscription for the automated publishing handler?
Domain: Connect to and consume Azure services (20–25%) Type: Single choice
- A. A subject filter that uses --subject-ends-with with the value 0.9.
- B. An event type filter that uses --included-event-types com.contoso.ai.InferenceCompleted.
- C. An event delivery schema setting that converts events from CloudEvents schema to Event Grid schema.
- D. An advanced filter that uses the NumberGreaterThan operator on data.confidence with the value 0.9.
D is correct.
Explanation: Advanced filters let you make routing decisions based on the content of the event data. The evidence specifically highlights confidence-based routing, where you route events to different handlers based on a confidence score threshold, such as using data.confidence NumberGreaterThan 0.9 for high-confidence results.
A is incorrect: Subject filters match a prefix or suffix of the subject path. They do not evaluate numeric values within the data payload.
B is incorrect: An event type filter selects events by their type. Because both high-confidence and low-confidence results share the same event type, this filter cannot separate them.
C is incorrect: The event delivery schema setting controls the format delivered to the handler, not the routing logic. Additionally, CloudEvents-to-Event Grid schema conversion is not supported.