|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.event-driven-workflows-event-grid.knowledge-check |
| 3 | +title: Module assessment |
| 4 | +metadata: |
| 5 | + title: Module Assessment |
| 6 | + description: Module assessment |
| 7 | + ms.date: 02/13/2026 |
| 8 | + author: jeffkoms |
| 9 | + ms.author: jeffko |
| 10 | + ms.topic: unit |
| 11 | +durationInMinutes: 5 |
| 12 | +content: "Choose the best response for each of the following questions." |
| 13 | +quiz: |
| 14 | + questions: |
| 15 | + - content: "You're building an AI content moderation application. You need to emit events when your inference service completes a classification. What type of Event Grid topic should you use to publish these events?" |
| 16 | + choices: |
| 17 | + - content: "A custom topic" |
| 18 | + isCorrect: true |
| 19 | + explanation: "Custom topics are user-defined endpoints where your applications post events. Since the inference service is your application code (not an Azure service), you create a custom topic to publish application-level events like inference completion." |
| 20 | + - content: "A system topic" |
| 21 | + isCorrect: false |
| 22 | + explanation: "System topics are created automatically for Azure service events such as Blob Storage or Key Vault. Only the Azure service itself can publish to system topics. Your application code can't publish directly to system topics." |
| 23 | + - content: "An Event Hubs topic" |
| 24 | + isCorrect: false |
| 25 | + explanation: "Event Hubs is a separate Azure service for streaming data ingestion. While Event Grid can deliver events to Event Hubs as a handler, Event Hubs doesn't provide the topic functionality that Event Grid custom topics offer for event routing." |
| 26 | + |
| 27 | + - content: "You're designing custom events for an AI pipeline and want to enable subscribers to filter events based on which pipeline stage produced them. Which CloudEvents attribute is best suited for path-based filtering with prefix and suffix matches?" |
| 28 | + choices: |
| 29 | + - content: "The `subject` attribute" |
| 30 | + isCorrect: true |
| 31 | + explanation: "The subject attribute provides a path for filtering. You can set it to a hierarchical value like `/pipelines/embeddings/batch-42` and use `subjectBeginsWith` or `subjectEndsWith` filters on subscriptions to route events based on pipeline stage or other path components." |
| 32 | + - content: "The `type` attribute" |
| 33 | + isCorrect: false |
| 34 | + explanation: "The type attribute categorizes the event (such as `com.contoso.ai.InferenceCompleted`) and enables event type filtering with exact matches. It doesn't support prefix or suffix filtering like the subject attribute does." |
| 35 | + - content: "The `source` attribute" |
| 36 | + isCorrect: false |
| 37 | + explanation: "The source attribute identifies the originating system or component but doesn't support the prefix and suffix filtering that subject filtering provides. Source is combined with type to uniquely identify the event context, not for path-based routing." |
| 38 | + |
| 39 | + - content: "Your AI handler endpoint occasionally experiences cold-start latency that exceeds 30 seconds. You want to ensure events are still delivered successfully after the handler warms up. What should you do?" |
| 40 | + choices: |
| 41 | + - content: "Rely on Event Grid's automatic retry mechanism with exponential backoff" |
| 42 | + isCorrect: true |
| 43 | + explanation: "Event Grid automatically retries failed deliveries using exponential backoff when an endpoint doesn't respond within 30 seconds or returns a transient error. The retry schedule starts at 10 seconds and scales up to 24 hours, giving your handler time to recover from cold starts." |
| 44 | + - content: "Configure a dead-letter destination to capture timed-out events" |
| 45 | + isCorrect: false |
| 46 | + explanation: "Dead-lettering captures events that can't be delivered after all retry attempts are exhausted. For cold-start transient failures, Event Grid's automatic retries handle the situation without needing dead-lettering. Dead-lettering is for events that permanently fail delivery." |
| 47 | + - content: "Set the event time-to-live to 30 seconds to match the timeout" |
| 48 | + isCorrect: false |
| 49 | + explanation: "Setting TTL to 30 seconds would cause events to be dropped or dead-lettered very quickly, before retries have a chance to succeed. For transient issues like cold starts, you want a longer TTL so events can be retried over time." |
| 50 | + |
| 51 | + - content: "You need to route AI moderation events to different handlers based on whether the content was flagged for review. The flagged status is stored in the `data.status` field of the event payload. Which filtering approach should you use?" |
| 52 | + choices: |
| 53 | + - content: "Advanced filtering with the `StringIn` operator on `data.status`" |
| 54 | + isCorrect: true |
| 55 | + explanation: "Advanced filters match on values within the event body using operators like `StringIn`, `NumberGreaterThan`, and `BoolEquals`. You can create a subscription with `--advanced-filter data.status StringIn flagged` to receive only events where the status field equals 'flagged'." |
| 56 | + - content: "Event type filtering with `--included-event-types`" |
| 57 | + isCorrect: false |
| 58 | + explanation: "Event type filtering matches on the event's type attribute, not on data payload fields. If all moderation events use the same event type regardless of flagged status, type filtering can't distinguish between flagged and non-flagged content." |
| 59 | + - content: "Subject filtering with `--subject-begins-with`" |
| 60 | + isCorrect: false |
| 61 | + explanation: "Subject filtering matches on the subject attribute using prefix or suffix patterns, not on fields within the event data payload. To filter based on a value inside the data object, you need advanced filtering." |
| 62 | + |
| 63 | + - content: "You're deploying an AI inference service to Azure Functions and need to publish events to an Event Grid custom topic. What authentication approach should you use for production workloads?" |
| 64 | + choices: |
| 65 | + - content: "Microsoft Entra ID with a managed identity assigned to the function app" |
| 66 | + isCorrect: true |
| 67 | + explanation: "Microsoft Entra ID authentication is recommended for production because it eliminates the need to manage and rotate shared secrets. You assign a managed identity to the function app and grant it the Event Grid Data Sender role on the custom topic." |
| 68 | + - content: "Access key authentication using the `aeg-sas-key` header" |
| 69 | + isCorrect: false |
| 70 | + explanation: "Access key authentication works but requires managing and rotating shared secrets. For production AI applications, Microsoft Entra ID with managed identity provides better security without key management overhead." |
| 71 | + - content: "Store the access key in the function app's application settings" |
| 72 | + isCorrect: false |
| 73 | + explanation: "While storing access keys in application settings is better than hardcoding them, it still requires key rotation and management. Microsoft Entra ID with managed identity avoids these operational concerns entirely." |
0 commit comments