Courseiva

CCNA Event Driven Integration Questions

25 of 100 questions · Page 2/2 · Event Driven Integration · Answers revealed

76
Multi-Selecthard

You are designing a big data telemetry ingestion pipeline using Azure Event Hubs. Which THREE configuration options or properties must you consider when planning Event Hubs capacity and scaling? (Choose three)

Select 3 answers
A.Partition Count
B.Service Bus Lock Duration
C.Event Grid Webhook Handshake Timeout
D.Throughput Units (TUs) or Processing Units (PUs)
E.Message Retention Period
AnswersA, D, E

Partition count sets the maximum throughput unit for an event hub and cannot be changed after creation, so it directly governs ingest scale and consumer parallelism. Planning capacity requires fixing it upfront to satisfy the pipeline's telemetry throughput and scaling constraints.

Why this answer

Partition Count (A) is correct because partitions are the fundamental unit of scale and parallelism in Event Hubs; the number of partitions determines the maximum concurrent readers per consumer group and directly caps ingress/egress throughput, so it must be planned up front since it cannot be reduced after creation. Throughput Units (TUs) or Processing Units (PUs) (D) are correct because they define the provisioned capacity of the namespace (TUs for Standard/Dedicated, PUs for Premium), governing ingress (e.g., 1 MB/s per TU) and egress limits and enabling auto-inflate scaling. Message Retention Period (E) is correct because it determines how long events remain available in the partition stream (1–7 days Standard, up to 90 days Premium/Dedicated), which affects storage consumption, replay/recovery windows, and downstream checkpointing design.

Service Bus Lock Duration (B) is incorrect because it is a Service Bus queue/subscription peek-lock setting, not an Event Hubs property. Event Grid Webhook Handshake Timeout (C) is incorrect because it belongs to Event Grid event subscription delivery validation, not Event Hubs capacity planning.

Exam trap

AI-200 often tests the confusion between Event Hubs and Service Bus properties — candidates pick 'Lock Duration' because it sounds like a scaling knob, but it belongs to Service Bus, not Event Hubs.

77
MCQeasy

Your application publishes custom events to an Azure Event Grid topic. You want to ensure that event publishers transmit data over secure HTTPS endpoints only. How should you enforce this?

A.You must install a self-signed SSL certificate on the publisher client machine.
B.Event Grid enforces HTTPS by default for all custom topic publishing endpoints.
C.Configure an Azure Firewall rule allowing port 80 outbound.
D.You must configure an Azure Application Gateway in front of the Event Grid topic.
AnswerB

Event Grid custom topics accept publisher traffic only over TLS 1.2+ HTTPS endpoints; plain HTTP requests are rejected outright, so no extra configuration is needed to satisfy the stem's secure-transport constraint. This default enforcement means publishers cannot transmit event data unencrypted, meeting the requirement without custom domain or firewall changes.

Why this answer

Azure Event Grid custom topics expose a publishing endpoint that only accepts HTTPS (TLS 1.2+) requests — there is no HTTP listener. Publishers must POST events to the topic's HTTPS URL using the `aeg-sas-key` header or Microsoft Entra ID token. Because HTTPS is the only supported transport, no additional configuration (certificates, firewalls, or gateways) is required to enforce it.

Exam trap

AI-200 often tests the misconception that Azure services require you to manually enable or configure HTTPS, when in fact Event Grid (like most Azure PaaS endpoints) enforces HTTPS by default and offers no HTTP option.

How to eliminate wrong answers

Option A is wrong because Event Grid uses a Microsoft-managed TLS certificate on its endpoint; publishers never install certificates on client machines — they simply trust the public CA chain. Option C is wrong because opening port 80 outbound would enable HTTP traffic, which Event Grid does not accept anyway; the publishing endpoint does not listen on port 80. Option D is wrong because Application Gateway is a reverse proxy/load balancer for your own backends, not a prerequisite for Event Grid's built-in HTTPS enforcement — Event Grid terminates TLS itself.

78
MCQhard

You are designing an AI streaming pipeline using Azure Event Hubs with Apache Kafka enabled. Existing Java producers using the Kafka producer API need to authenticate against Event Hubs securely using Microsoft Entra ID (OAuth 2.0). How should you configure the Kafka producer client properties?

A.Use plain text authentication with the Event Hub root SAS key as the username and password.
B.Deploy an Event Grid webhook proxy between the Kafka producer and Event Hubs.
C.Set the bootstrap.servers property to the Service Bus AMQP connection string.
D.Configure security.protocol=SASL_SSL, sasl.mechanism=OAUTHBEARER, and implement an OAuthBearerTokenCallbackHandler for Microsoft Entra ID token acquisition.
AnswerD

Configuring `security.protocol=SASL_SSL` with `sasl.mechanism=OAUTHBEARER` satisfies the stem's Microsoft Entra ID requirement, since Event Hubs' Kafka endpoint accepts OAuth 2.0 tokens over SASL. The callback handler supplies fresh bearer tokens to the Java producer, replacing connection-string SASL/PLAIN authentication without altering existing producer code.

Why this answer

The correct configuration is to set security.protocol=SASL_SSL, sasl.mechanism=OAUTHBEARER, and implement an OAuthBearerTokenCallbackHandler for Microsoft Entra ID token acquisition. Azure Event Hubs with Kafka enabled supports OAuth 2.0 authentication via SASL/SSL. The Kafka producer must be configured to use SASL_SSL and the OAUTHBEARER mechanism, and the callback handler must obtain a token from Microsoft Entra ID (formerly Azure AD) and present it to Event Hubs.

Exam trap

AI-200 often tests the confusion between SAS key authentication and OAuth 2.0 for Kafka-enabled Event Hubs, leading candidates to choose plain text SAS or incorrect protocol settings.

How to eliminate wrong answers

Option A is wrong because using plain text authentication with the Event Hub root SAS key is insecure and does not use Microsoft Entra ID; it also transmits credentials in plain text. Option B is wrong because deploying an Event Grid webhook proxy is unnecessary and does not provide authentication; Event Grid is for event routing, not for proxying Kafka connections. Option C is wrong because setting the bootstrap.servers property to the Service Bus AMQP connection string is incorrect; Event Hubs Kafka endpoint uses a different hostname (e.g., <namespace>.servicebus.windows.net:9093) and AMQP is not used for Kafka protocol.

79
Multi-Selectmedium

Your development team is implementing an event-driven microservices architecture using Azure Service Bus. You need to ensure strict FIFO (First-In, First-Out) message processing order for related financial transaction events in an AI fraud-detection workflow. Which THREE configuration steps are required? (Choose three)

Select 3 answers
A.Implement a MessageSession receiver in your client application to process messages sequentially per session.
B.Set a Session ID on all related messages sent to the queue.
C.Configure partitioning on the Service Bus namespace tier.
D.Enable sessions on the Azure Service Bus queue.
E.Enable duplicate detection with a 10-minute history window.
AnswersA, B, D

A MessageSession receiver accepts a session lock and processes its messages one at a time, preserving order. Without this sequential per-session consumption pattern, even session-enabled queues could be drained concurrently, breaking the FIFO requirement for financial events.

Why this answer

Option D is correct because sessions must be explicitly enabled on the Service Bus queue (via the EnableSession property) before session-based FIFO ordering can be used; without this, session IDs are ignored. Option B is correct because setting a Session ID on all related financial transaction messages groups them into the same session, guaranteeing that messages with the same SessionId are delivered in order. Option A is correct because the receiving client must use a MessageSession receiver (via AcceptMessageSessionAsync) to process each session's messages sequentially and in FIFO order.

Option C is not required because partitioning is a throughput/availability feature and does not provide FIFO ordering; in fact, partitioned entities without sessions do not guarantee ordering. Option E is not required because duplicate detection only prevents duplicate message submission within the history window and has no role in enforcing FIFO processing order.

Exam trap

AI-200 often tests whether candidates confuse duplicate detection (deduplication) with sessions (FIFO ordering) — candidates pick duplicate detection thinking it enforces order, when only sessions provide FIFO guarantees.

80
MCQeasy

Your AI ingestion pipeline ingests millions of clickstream events per second from IoT devices and streams them into an Azure ML training pipeline. Which Azure service is specifically designed for high-throughput, low-latency telemetry ingestion at this scale?

A.Azure Notification Hubs
B.Azure Event Hubs
C.Azure Event Grid
D.Azure Service Bus Queues
AnswerB

Azure Event Hubs is a partitioned event-ingestion service built for millions of events per second with low latency, buffering telemetry before downstream consumption, which matches the clickstream ingestion requirement far better than batch-oriented storage services.

Why this answer

Azure Event Hubs is designed for high-throughput, low-latency ingestion of telemetry data, capable of handling millions of events per second. It is optimized for streaming scenarios like IoT telemetry and clickstream data, making it ideal for this use case.

Exam trap

AI-200 often tests the confusion between Event Hubs (high-throughput streaming) and Service Bus (enterprise messaging with transactions), or Event Grid (event routing). Candidates may pick Service Bus due to its reliability features, but the scale requirement points to Event Hubs.

How to eliminate wrong answers

Option A is wrong because Azure Notification Hubs is for sending push notifications to mobile devices, not for high-volume telemetry ingestion. Option C is wrong because Azure Event Grid is for event routing and reactive programming, not for high-throughput streaming. Option D is wrong because Azure Service Bus Queues are for enterprise messaging with guaranteed delivery, but not designed for millions of events per second.

81
Multi-Selectmedium

When designing an event-driven architecture using Azure Event Grid, which THREE security or delivery mechanisms can be configured on an event subscription? Each correct answer represents a valid configuration option.

Select 3 answers
A.AMQP 1.0 broker transaction coordination
B.Advanced filtering based on event data property values
C.Dead-letter destination pointing to an Azure Blob Storage container
D.Service Bus session lock duration extension
E.Managed Identity for authenticating secure delivery to webhooks
AnswersB, C, E

Advanced filtering evaluates event payload properties against operators such as string comparisons and numeric ranges, so subscribers receive only matching events. This satisfies the stem's requirement for a configurable delivery mechanism on an Event Grid event subscription, reducing handler invocations and downstream processing costs.

Why this answer

Option B is correct because Event Grid event subscriptions support advanced filtering, which evaluates event data fields (such as string, number, boolean, and arrays) against operators like StringContains, NumberGreaterThan, and BoolEquals to route only matching events. Option C is correct because an event subscription can define a dead-letter destination, which must be an Azure Blob Storage container, where undeliverable events are stored along with a reason for delivery failure. Option E is correct because Event Grid supports using a managed identity (system-assigned or user-assigned) on the event subscription to authenticate delivery to supported destinations such as webhooks and Service Bus, avoiding embedded secrets.

Option A is not applicable because AMQP 1.0 broker transaction coordination is a Service Bus/AMQP messaging concept, not an Event Grid subscription setting. Option D is not applicable because Service Bus session lock duration is a Service Bus queue/subscription feature and cannot be configured on an Event Grid event subscription.

Exam trap

AI-200 often tests whether candidates can distinguish Event Grid subscription features (filtering, dead-letter, managed identity) from Service Bus features (sessions, AMQP transactions) that are irrelevant to Event Grid.

82
MCQmedium

Your AI application consumes messages from an Azure Service Bus queue. During peak hours, processing takes longer than expected, and messages are frequently locked out and redelivered prematurely. You want to increase the time a message remains locked by the receiver. Where should you configure this setting?

A.On the Azure Service Bus queue properties by modifying the LockDuration setting.
B.On the Event Grid subscription retry interval settings.
C.On the Event Hubs consumer group retention period.
D.In the Azure Function host.json file under the eventHubs retry policy.
AnswerA

LockDuration on the queue determines how long a receiver holds a message lock before it becomes visible again. Raising it prevents premature redelivery during peak processing, directly addressing the lock expiry described in the stem.

Why this answer

The LockDuration setting on a Service Bus queue controls how long a message is locked by a receiver before it becomes available for redelivery. Increasing this value prevents premature lock expiration during long processing, directly addressing the described issue.

Exam trap

AI-200 often tests whether candidates know that LockDuration is a queue-level property, not a client-side or function-level setting, and may confuse it with Event Hubs or Event Grid retry configurations.

How to eliminate wrong answers

Option B is wrong because Event Grid subscription retry intervals govern event delivery retries, not Service Bus message locks. Option C is wrong because Event Hubs consumer group retention period controls how long events are retained in the event stream, unrelated to message locking. Option D is wrong because the host.json eventHubs retry policy configures retry behavior for Event Hubs triggers in Azure Functions, not Service Bus lock duration.

83
MCQhard

You are designing an enterprise-grade event-driven system where producers send financial transactions to Azure Event Hubs. You must guarantee that every single message is accounted for and that no data is lost even if an entire availability zone suffers a catastrophic failure. Which deployment configuration should you select for your Event Hubs namespace?

A.Configure Event Grid system topics with auto-delete set to false.
B.Deploy a Basic tier Event Hubs namespace with 30 consumer groups.
C.Use Azure Storage Queues configured with RA-GRS replication.
D.Deploy an Event Hubs namespace in a region supporting Availability Zones with zone redundancy enabled (Premium or Dedicated tier).
AnswerD

Zone redundancy replicates Event Hubs data across Availability Zones within the region, so message durability survives a full zone failure. Premium or Dedicated tier is required to enable this, satisfying the constraint that no transaction is lost during catastrophic zone outage.

Why this answer

Zone-redundant Event Hubs, available in Premium and Dedicated tiers, replicates data across three availability zones within a region. This ensures that if an entire availability zone fails, the namespace remains available and no committed messages are lost, satisfying the requirement for catastrophic AZ failure resilience.

Exam trap

AI-200 often tests the confusion between geo-replication (cross-region) and zone-redundancy (within-region), or assumes Basic tier supports high availability features when it does not.

How to eliminate wrong answers

Option A is wrong because Event Grid system topics are for event routing, not for storing financial transactions, and auto-delete settings do not provide zone redundancy or message durability. Option B is wrong because Basic tier Event Hubs does not support availability zones, has limited throughput units, and lacks the replication needed for AZ failure tolerance. Option C is wrong because Azure Storage Queues with RA-GRS provide geo-replication for storage, not event streaming, and RA-GRS replication is asynchronous with potential data loss, plus it does not meet the Event Hubs requirement.

84
MCQmedium

You are implementing an event-driven architecture where an Azure Function acts as an Event Grid subscriber. Occasionally, the downstream cognitive service is throttled, causing failures. You need to ensure that unprocessable events are not lost and can be inspected later. Where should you configure a dead-letter destination?

A.On the Azure Function trigger binding definition using the deadLetterQueueName property.
B.On the Azure Storage account firewall settings as an IP filter exception.
C.On the Event Grid event subscription, specify an Azure Blob Storage container as the dead-letter endpoint.
D.Inside the Azure Function application configuration settings as an Application Insights error sink.
AnswerC

Event Grid dead-lettering stores undeliverable events when a subscriber fails, such as throttling. Setting an Azure Blob Storage container as the dead-letter endpoint on the event subscription preserves those events for later inspection instead of losing them.

Why this answer

Event Grid event subscriptions support a native dead-letter destination where events that cannot be delivered (after retries are exhausted) are stored as blobs in an Azure Storage container. This is configured on the event subscription itself, not on the subscriber, because Event Grid owns the delivery and retry lifecycle. The dead-lettered blob retains the original event payload plus failure metadata, enabling later inspection and reprocessing.

Exam trap

The trap here is confusing Service Bus dead-letter queues (a broker-side feature on queues/subscriptions) with Event Grid dead-letter destinations (a subscription-level blob storage setting) — candidates often pick the Function trigger binding because that is where they configure Service Bus dead-lettering.

How to eliminate wrong answers

Option A is wrong because deadLetterQueueName is a Service Bus / Storage Queue concept, not an Event Grid trigger binding property — Event Grid dead-lettering is configured on the subscription, not the Function trigger. Option B is wrong because storage firewall IP filters control network access, not event delivery failure handling. Option D is wrong because Application Insights is a telemetry and diagnostics sink; it can log exceptions but does not preserve the original undeliverable event payload for replay.

85
MCQmedium

Your application publishes messages to an Azure Service Bus queue. The messages contain sensitive personal data. Enterprise compliance mandates that message payloads are encrypted end-to-end at the application layer before being sent to Service Bus. How should you implement this?

A.Encrypt the message payload in your application code using a key from Azure Key Vault before sending, and decrypt upon receipt.
B.Configure Event Grid advanced filters to redact sensitive keys.
C.Enable Service Bus Premium Geo-Disaster Recovery with encryption enabled.
D.Use Shared Access Signature tokens with 5-minute expirations.
AnswerA

Service Bus encrypts data at rest and in transit, but not end-to-end at the application layer. Encrypting the payload in code with an Azure Key Vault key before sending, then decrypting on receipt, satisfies the compliance mandate for application-layer end-to-end encryption.

Why this answer

End-to-end application-layer encryption means the payload must be encrypted before it leaves the producer and decrypted only by the consumer, so the broker never sees plaintext. Using a key from Azure Key Vault to encrypt in code and decrypt on receipt satisfies this because Service Bus only transports ciphertext, and key custody stays in Key Vault.

Exam trap

AI-200 often tests whether candidates conflate platform-level encryption (at-rest CMK, TLS in transit, SAS authorization) with true application-layer end-to-end encryption, so options mentioning 'encryption enabled' or 'SAS tokens' look secure but do not meet the requirement.

How to eliminate wrong answers

Option B is wrong because Event Grid advanced filters evaluate event metadata for routing and cannot redact or encrypt message payloads. Option C is wrong because Geo-Disaster Recovery is a metadata replication feature for namespace failover and does not provide application-layer payload encryption. Option D is wrong because SAS tokens are an authorization mechanism for accessing the namespace; short expirations improve security posture but do not encrypt message contents.

86
MCQeasy

An AI system uses Azure Service Bus queues for processing text-generation jobs. A specific job causes the worker function to crash repeatedly, leading to the message being redelivered continuously. Which Service Bus feature should you configure to capture these poison messages after a specific delivery count is reached?

A.Duplicate detection
B.Dead-letter queue (DLQ)
C.Autoforwarding
D.Partitioning
AnswerB

The dead-letter queue moves messages aside once their delivery count exceeds the configured maximum, halting the crash-redelivery loop. This captures the poison message for later inspection, satisfying the requirement to isolate it after a specific delivery count.

Why this answer

The dead-letter queue (DLQ) captures messages that cannot be processed successfully after a specified number of delivery attempts. By configuring the queue's MaxDeliveryCount, you can automatically move poison messages to the DLQ after they exceed that count, preventing infinite redelivery loops. This allows you to inspect and handle problematic messages separately.

Exam trap

AI-200 often tests whether candidates confuse duplicate detection with dead-lettering, or assume that autoforwarding handles poison messages.

How to eliminate wrong answers

Option A is wrong because duplicate detection identifies and removes duplicate messages based on MessageId, not messages that fail processing. Option C is wrong because autoforwarding automatically forwards messages from one queue or subscription to another, which does not address poison messages. Option D is wrong because partitioning distributes messages across multiple partitions for scalability, not for handling failed deliveries.

87
MCQmedium

Your team is building an automated image moderation pipeline. When an image is uploaded to Azure Blob Storage, you need to trigger an Azure Function to process it using Azure AI Vision. You want to ensure the lowest latency and native cloud event integration. Which integration approach should you configure?

A.Attach an Azure Event Hubs capture policy to the storage container.
B.Use an Azure Logic Apps polling trigger to check the storage container every minute for new files.
C.Configure an Azure Event Grid system topic and subscription for blob storage events targeting the Azure Function.
D.Write a background worker service that reads the Azure Service Bus queue populated by storage transactions.
AnswerC

An Event Grid system topic on the storage account pushes BlobCreated events to the Function through a native subscription, giving push-based, near-instant invocation rather than polling. This satisfies the lowest-latency and native cloud event integration constraints, unlike Blob Storage's legacy polling-based triggers or manual queue wiring.

Why this answer

Azure Event Grid natively integrates with Blob Storage via system topics and delivers blob-created events to subscribers such as Azure Functions with near-real-time push delivery. This is the lowest-latency, event-driven pattern and requires no polling or intermediate queue.

Exam trap

AI-200 often tests whether candidates default to polling or queue-based patterns when a native push-based event integration (Event Grid) is available, missing the latency and simplicity advantage.

How to eliminate wrong answers

Option A is wrong because Event Hubs capture is for streaming ingestion to storage, not for reacting to blob creation events. Option B is wrong because Logic Apps polling triggers introduce latency (up to the polling interval) and are not native event-driven integrations. Option D is wrong because Service Bus does not automatically receive blob storage events; you would need an intermediary publisher, adding complexity and latency.

88
Multi-Selectmedium

You are troubleshooting an Azure Function triggered by an Azure Event Grid subscription. The function is failing to receive events. Which TWO diagnostic steps should you take in the Azure Portal or via Azure CLI? Each correct answer is a valid troubleshooting action.

Select 2 answers
A.Inspect the configured dead-letter blob storage container for undelivered event files.
B.Verify the AMQP listener port 5671 firewall rules on the function app.
C.Check Event Grid metric charts for delivery failures, dropped events, and matched events.
D.Review Service Bus session lock renewal logs.
E.Check Event Hubs consumer group checkpoint offset status.
AnswersA, C

Inspecting the dead-letter container reveals events Event Grid could not deliver, confirming whether delivery failed after matching. This satisfies the diagnostic need to distinguish subscription or filtering faults from endpoint failures, since dead-lettered files only appear when delivery attempts to the function were exhausted.

Why this answer

Option A is correct because Event Grid supports a dead-letter destination (a Storage blob container) where events are written when they cannot be delivered to the subscriber, so inspecting that container reveals undelivered event files and their failure reasons. Option C is correct because Event Grid exposes metrics such as Delivery Failed Events, Dropped Events, and Matched Events in Azure Monitor, which directly show whether events are being matched to the subscription and whether delivery to the function is failing. Option B is not applicable because AMQP port 5671 is used by Service Bus and Event Hubs, not by Event Grid, which delivers events over HTTPS (port 443) to webhook/function endpoints.

Option D is not applicable because Service Bus session lock renewal is a Service Bus feature unrelated to Event Grid subscriptions. Option E is not applicable because Event Hubs consumer group checkpoints relate to Event Hubs consumption, not to Event Grid event delivery to an Azure Function.

Exam trap

AI-200 often tests whether candidates can identify the correct diagnostic surfaces for Event Grid delivery failures, luring them toward AMQP, Service Bus session, or Event Hubs checkpoint options that belong to other services.

89
MCQeasy

Your team is developing an Azure Function that acts as an Event Grid webhook subscriber. You want to test the function locally using the Azure Functions Core Tools CLI. Which command starts the local runtime and enables local event ingestion?

A.func start
B.dotnet watch run-eventgrid
C.az eventgrid topic local-debug
D.az functionapp deployment source config
AnswerA

`func start` launches the local Functions host, which exposes the Event Grid webhook endpoint on localhost so events can be posted for ingestion. This satisfies the stem's requirement to run the runtime locally via Core Tools while enabling local event delivery, without deploying to Azure.

Why this answer

The Azure Functions Core Tools command `func start` launches the local Functions host, which exposes the HTTP trigger endpoint (typically http://localhost:7071/api/<function>) that Event Grid can target as a webhook subscriber. It also loads local.settings.json so you can point at a real Event Grid subscription for end-to-end local testing. This is the standard way to run and debug a function locally before deploying.

Exam trap

The trap is that candidates look for an Event Grid-specific local command, but the correct answer is the generic Functions host command `func start` — Event Grid has no local emulator in Core Tools.

How to eliminate wrong answers

Option B is wrong because `dotnet watch run-eventgrid` is not a valid .NET CLI command — `dotnet watch run` exists but has no Event Grid-specific verb, and it does not start the Functions host. Option C is wrong because `az eventgrid topic local-debug` is not a real Azure CLI command; `az eventgrid topic` supports create/list/show/delete, not a local-debug operation, and Azure CLI cannot run a local Event Grid emulator. Option D is wrong because `az functionapp deployment source config` configures continuous deployment source for a deployed Function App in Azure, not a local runtime.

90
MCQeasy

An event subscriber endpoint hosted on an Azure App Service web app is failing to receive events from an Azure Event Grid system topic. Upon investigation, you discover Event Grid received a handshake validation failure. What is the most likely cause?

A.The event payload exceeded the 1 megabyte size limit.
B.The Service Bus connection string was incorrectly formatted.
C.The web app did not correctly handle and echo back the validation code during the Webhook handshake.
D.The App Service pricing tier does not support HTTPS connections.
AnswerC

Event Grid validates a webhook subscription by sending a SubscriptionValidationEvent containing a validation code; the endpoint must echo that code back in the response. If the App Service returns anything else, validation fails and the subscription is rejected, so events never flow.

Why this answer

Event Grid requires a webhook validation handshake when a new event subscription is created. The subscriber endpoint must respond to the validation event by echoing back the validation code within a short timeout. If the web app fails to handle this handshake—for example, by not returning the validation code or returning an error—Event Grid marks the subscription as failed and does not deliver events.

The most likely cause is that the web app did not correctly process and echo the validation code.

Exam trap

AI-200 often tests the misconception that event delivery failures are due to payload size or authentication, when the root cause is often the initial webhook validation handshake not being handled correctly.

How to eliminate wrong answers

Option A is wrong because the 1 MB event size limit applies to event payloads, not to the handshake validation, and a size violation would produce a different error. Option B is wrong because Service Bus connection strings are unrelated to Event Grid system topic subscriptions; Event Grid uses webhooks or other event handlers. Option D is wrong because Azure App Service supports HTTPS on all pricing tiers, including the free tier, so HTTPS support is not the issue.

91
MCQhard

You are designing a multi-tenant AI ingestion pipeline using Azure Event Hubs. You need to ensure that low-priority tenants cannot starve high-priority tenants of partition resources. Which feature should you implement?

A.Set the Capture interval to 60 seconds for low-priority partitions.
B.Deploy separate Event Hubs namespaces for high-priority and low-priority tenants.
C.Configure RBAC permissions to restrict low-priority tenants to Reader roles.
D.Enable Azure DDoS Protection Standard on the Event Hubs consumer group.
AnswerB

Separate Event Hubs namespaces give each tenant tier independent throughput units and partition capacity, so low-priority tenants cannot consume the partitions high-priority tenants depend on. This isolation directly satisfies the requirement to prevent resource starvation across priority tiers.

Why this answer

Event Hubs throughput and partition resources are scoped to a namespace, so tenants sharing a single namespace compete for the same throughput units and partitions. Deploying separate namespaces for high-priority and low-priority tenants physically isolates their throughput units, partitions, and throttling limits, preventing noisy-neighbor starvation. This is the standard multi-tenant isolation pattern for Event Hubs.

Exam trap

The trap is assuming that RBAC or Capture settings can enforce performance fairness; candidates must recognize that Event Hubs isolation for throughput requires namespace-level separation, not permission or capture tuning.

How to eliminate wrong answers

Option A is wrong because the Capture interval only controls how often captured data is written to Blob Storage or Data Lake; it has no effect on partition allocation or consumer throughput, so it cannot prevent starvation. Option C is wrong because RBAC Reader roles only restrict control-plane and data-plane permissions; they do not reserve or prioritize partition throughput, and a Reader can still consume at full speed if granted the data receiver role. Option D is wrong because Azure DDoS Protection Standard protects against volumetric network attacks on public IPs and has nothing to do with Event Hubs consumer groups or partition fairness.

92
MCQeasy

An application publishes custom events to an Azure Event Grid custom topic. You need to route events dynamically based on the event's 'department' property in the event payload. Which filtering mechanism should you configure on the Event Grid subscription?

A.Event Hubs Capture filters
B.Advanced Filters
C.Subject Begins With/Ends With filters
D.Service Bus Correlation Filters
AnswerB

Advanced Filters evaluate payload properties using operators such as StringIn, NumberGreaterThan and BoolEquals, so the subscription matches on the 'department' value inside the event data. Subject-prefix filtering only inspects the event subject string, which cannot express this payload-based routing condition.

Why this answer

Advanced Filters in Azure Event Grid allow filtering based on any property within the event payload, including custom properties like 'department'. They support operators such as string comparisons, numeric comparisons, and boolean logic, enabling dynamic routing based on event data. This is the correct mechanism because the requirement is to filter on a custom property in the event schema, which Advanced Filters are designed to handle.

Exam trap

AI-200 often tests the confusion between Event Grid filtering mechanisms and similar features in other Azure messaging services, leading candidates to select Service Bus Correlation Filters or Subject filters when the requirement involves custom event properties.

How to eliminate wrong answers

Option A is wrong because Event Hubs Capture filters are not a feature of Event Grid; Event Hubs Capture is a separate service for archiving streaming data to storage, and it does not provide filtering capabilities for Event Grid subscriptions. Option C is wrong because Subject Begins With/Ends With filters only operate on the event's subject field, not on custom properties within the event payload, so they cannot filter based on the 'department' property. Option D is wrong because Service Bus Correlation Filters are used in Azure Service Bus subscriptions to filter messages based on correlation properties, not in Event Grid, and they do not apply to Event Grid event payloads.

93
Multi-Selectmedium

Your enterprise application uses Azure Event Grid. Which TWO event schemas are natively supported when publishing events to an Event Grid custom topic? (Choose two)

Select 2 answers
A.Apache Kafka record batch binary schema
B.AMQP 1.0 binary stream envelope
C.SOAP 1.2 XML messaging schema
D.CloudEvents 1.0 schema
E.Azure Event Grid schema
AnswersD, E

CloudEvents 1.0 is a natively supported schema for Event Grid custom topics, satisfying the stem's requirement for supported publish formats. Event Grid accepts both the proprietary Event Grid schema and CloudEvents 1.0, so publishers can emit interoperable, CNCF-standard events without transformation. This makes CloudEvents 1.0 one of the two valid choices.

Why this answer

Azure Event Grid custom topics natively support two event schemas for publishing: the CloudEvents 1.0 schema (option D) and the proprietary Azure Event Grid schema (option E). CloudEvents 1.0 is the CNCF-standardized, interoperable envelope format that Event Grid accepts directly, while the Azure Event Grid schema is the service's original native format with fields like 'eventType', 'subject', 'data', and 'dataVersion'. Both are selectable via the topic's input schema setting and are the only two schemas Event Grid accepts for custom topic publishing.

Options A, B, and C are incorrect: Apache Kafka record batch binary, AMQP 1.0 binary stream envelopes, and SOAP 1.2 XML are not supported input schemas for Event Grid custom topics, even though Event Grid can deliver to Kafka or use AMQP internally for its own transport.

Exam trap

The trap is confusing Event Grid schemas with Event Hubs or Service Bus protocols (Kafka, AMQP, SOAP); candidates must remember that Event Grid supports exactly two schemas: Event Grid schema and CloudEvents 1.0.

94
MCQhard

You are designing an IoT data ingestion architecture using Azure Event Hubs. Devices occasionally send malformed JSON payloads that cause stream processing jobs to crash. You need to route these invalid messages to a separate error container without stopping the main ingestion stream. What should you implement?

A.Enable Event Hubs Capture with the JSON validation flag set to strict.
B.Set up an Event Grid system topic filter for 'MalformedEvent'.
C.Configure the Service Bus dead-letter queue on the Event Hub producer client.
D.Use Azure Stream Analytics with an error output data stream configured for malformed events.
AnswerD

Azure Stream Analytics supports error handling configurations on data outputs, allowing streaming errors to be redirected to a separate blob storage sink.

Why this answer

Azure Stream Analytics supports an error output data stream that captures malformed or deserialization-failed events, allowing the main query to continue processing valid events while routing bad records to a separate sink (e.g., Blob Storage container). This is the documented pattern for handling malformed JSON without stopping the stream. Configuring the error output to point at an 'error' container satisfies the requirement.

Exam trap

The trap is assuming Event Hubs itself can validate JSON or dead-letter malformed messages; Event Hubs is a dumb pipe, and the routing/validation must be done by the stream processing layer (Stream Analytics error output).

How to eliminate wrong answers

Option A is wrong because Event Hubs Capture has no 'JSON validation flag set to strict' — Capture simply writes raw events to Blob/ADLS in Avro format and does not validate or route malformed payloads. Option B is wrong because Event Grid system topics surface control-plane events (e.g., capture file created), not per-message malformed JSON detection, and there is no 'MalformedEvent' filter. Option C is wrong because Service Bus dead-letter queues apply to Service Bus queues/subscriptions, not Event Hubs producers; Event Hubs has no DLQ concept for producers.

95
MCQeasy

You are configuring Azure Event Grid to send events to an Azure Logic App. Which built-in trigger should you use in your Logic App workflow to receive these events seamlessly?

A.When messages arrive in a Service Bus queue
B.When a resource event occurs (Azure Event Grid trigger)
C.When a blob is added or modified (V2)
D.When an HTTP request is received
AnswerB

The Event Grid trigger subscribes the Logic App to a topic and fires on each published event, using Event Grid's push delivery and built-in validation handshake. This satisfies seamless receipt without polling, unlike HTTP request or recurrence triggers.

Why this answer

The 'When a resource event occurs' trigger is the native Azure Event Grid trigger in Logic Apps, designed specifically to subscribe to Event Grid topics and system topics. It handles the Event Grid subscription handshake, event schema validation, and delivery automatically, so events published to Event Grid flow directly into the workflow without custom parsing. This is the seamless, first-party integration path for Event Grid-to-Logic App event delivery.

Exam trap

AI-200 often tests whether candidates confuse Event Grid's native Logic App trigger with generic HTTP or storage-specific triggers, so watch for options that sound like they receive events but actually poll a different service.

How to eliminate wrong answers

Option A is wrong because the Service Bus queue trigger consumes messages from a Service Bus queue, not Event Grid events, and would require an intermediary to bridge Event Grid to Service Bus. Option C is wrong because the 'When a blob is added or modified (V2)' trigger is an Azure Blob Storage trigger that polls/subscribes to blob storage events, not a generic Event Grid event receiver. Option D is wrong because the HTTP request trigger creates a manual request endpoint and does not automatically handle Event Grid subscription validation or event schema, requiring custom validation code.

96
Multi-Selectmedium

You are architecting an event-driven AI ingestion pipeline using Azure Event Hubs. Which TWO features or capabilities are native to Azure Event Hubs? (Choose two)

Select 2 answers
A.Automatic dead-letter queue routing after max delivery count
B.Apache Kafka protocol endpoint compatibility
C.Event Hubs Capture for automated data archiving into Azure Blob Storage
D.Webhook event schema subscription validation handshakes
E.AMQP 1.0 message session management for FIFO per session ID
AnswersB, C

Event Hubs exposes a Kafka-compatible endpoint on port 9093, so existing Kafka producers and consumers connect without code changes. This native protocol surface satisfies the ingestion requirement by letting Kafka-based AI pipelines publish directly into Event Hubs partitions.

Why this answer

Option B is correct because Azure Event Hubs natively exposes a Kafka-compatible endpoint (port 9093, SASL/PLAIN or SASL/OAUTHBEARER), letting existing Apache Kafka producers and consumers connect without code changes. Option C is correct because Event Hubs Capture is a built-in feature that automatically archives streaming data to Azure Blob Storage or Azure Data Lake Storage in Avro format based on a time or size window, with no custom consumer required. Option A is not native: dead-lettering after a max delivery count is a Service Bus queue/subscription behavior, not an Event Hubs feature (Event Hubs uses consumer offsets and checkpointing).

Option D is not native: webhook subscription validation handshakes belong to Event Grid event subscriptions, not Event Hubs. Option E is not native: AMQP 1.0 sessions with FIFO per session ID are a Service Bus messaging capability; Event Hubs provides partition-based ordering, not AMQP session management.

Exam trap

AI-200 often tests the confusion between Azure Event Hubs and Azure Service Bus features, such as dead-lettering, sessions, and transactions, which are not native to Event Hubs.

97
Multi-Selecthard

You are configuring authentication and authorization across Azure messaging and eventing services. Which THREE statements regarding security features are correct? (Choose three)

Select 3 answers
A.Event Grid custom topics require SQL database credentials for publisher authentication.
B.Shared Access Signature (SAS) tokens can be generated with specific permissions and expiration times.
C.Azure Service Bus and Event Hubs support Microsoft Entra ID RBAC for data plane access.
D.Azure Event Grid webhook subscriptions support Managed Identity authentication for secure target invocation.
E.Azure Service Bus queues require public anonymous access to be enabled for client SDK connections.
AnswersB, C, D

SAS tokens are issued against a namespace, entity or policy with explicitly scoped claims such as Send or Listen, plus a defined expiry. That granular, time-bound credential model satisfies the requirement for delegated, revocable access without exposing primary keys.

Why this answer

Option B is correct because SAS tokens for Service Bus, Event Hubs, and Storage are constructed with a signed resource URI, key name, expiry, and explicit permissions (for example Send, Listen, Manage), allowing least-privilege, time-bound access. Option C is correct because Service Bus and Event Hubs both expose data-plane RBAC roles such as Azure Service Bus Data Owner/Sender/Receiver and Event Hubs Data Owner/Sender/Receiver, letting Microsoft Entra ID identities authenticate without embedding SAS keys. Option D is correct because Event Grid webhook and Azure Function/Service Bus/Event Hubs subscription targets can use a system-assigned or user-assigned managed identity, with the target validating the Entra-issued token, avoiding secrets in the subscription.

Option A is wrong because Event Grid custom topics authenticate publishers with SAS keys or Microsoft Entra ID, not SQL database credentials. Option E is wrong because Service Bus queues are accessed via SAS or Entra ID over AMQP; anonymous public access is not required and should not be enabled.

Exam trap

AI-200 often tests the misconception that Azure messaging services require anonymous public access or database credentials, when in fact they use SAS tokens or Microsoft Entra ID RBAC for secure authentication.

98
MCQhard

You are configuring geo-disaster recovery for an Azure Service Bus Premium namespace containing critical financial transactions. A regional outage occurs. After initiating a failover to the secondary region, what happens to the alias pointing to the namespace?

A.The secondary namespace remains in Read-Only mode until manually unlocked.
B.The alias becomes invalid, and you must deploy a new Service Bus namespace from scratch.
C.Unreplicated messages in the primary queue are automatically migrated in real-time.
D.The alias automatically points to the secondary namespace, and pairing is broken.
AnswerD

Initiating a geo-failover repoints the alias to the secondary namespace automatically, and the existing pairing is severed. This satisfies the stem's requirement for continued routing during a regional outage, since the alias remains the stable connection string endpoint clients use without reconfiguration.

Why this answer

After a geo-disaster recovery failover in Azure Service Bus Premium, the alias automatically points to the secondary namespace and the pairing between primary and secondary is broken. The alias is a stable connection string endpoint that clients use, so applications do not need to change connection strings; however, the former primary becomes unusable until it is re-paired. This is the documented behavior of Service Bus Geo-DR failover.

Exam trap

AI-200 often tests whether candidates believe Geo-DR replicates messages (it does not—only metadata) or that the alias becomes invalid after failover (it automatically redirects to the secondary).

How to eliminate wrong answers

Option A is wrong because the secondary namespace becomes the active namespace after failover and is not left in a read-only locked state; it accepts both reads and writes once failover completes. Option B is wrong because the alias remains valid and automatically redirects to the secondary namespace; you do not need to deploy a new namespace from scratch. Option C is wrong because Service Bus Geo-DR replicates only metadata (queues, topics, subscriptions, filters, and policies), not message data; unreplicated messages in the primary are not migrated in real-time and are effectively lost or stranded in the old primary.

99
MCQeasy

Your application emits custom events to an Azure Event Grid topic. You want to test your webhook endpoint locally during development without deploying your code to Azure. Which tool should you use to receive events directly from Event Grid?

A.Use Azure Bastion to connect your localhost to the Event Grid topic.
B.Deploy the Event Grid Viewer sample web app to an accessible public URL or use ngrok to tunnel your local port.
C.Configure a local SQL Server Express trigger.
D.Attach an Azure Service Bus queue directly as a local debugging breakpoint.
AnswerB

Event Grid requires a publicly reachable HTTPS webhook for delivery, so exposing the local port via ngrok tunnelling or a deployed viewer gives the topic a valid endpoint. This satisfies the constraint of receiving live events without deploying your own code to Azure.

Why this answer

Event Grid delivers events via HTTP POST to a webhook endpoint, so the endpoint must be reachable from the public internet. During local development, you either deploy the Event Grid Viewer sample to a publicly accessible URL or use ngrok to create a public tunnel that forwards to your localhost port. This lets Event Grid push events directly to your local debugging session without deploying your application to Azure.

Exam trap

AI-200 often tests whether candidates confuse network access tools (like Bastion) with event delivery mechanisms, or assume that local debugging requires deploying to Azure.

How to eliminate wrong answers

Option A is wrong because Azure Bastion provides RDP/SSH access to Azure VMs over a private network; it does not create a public webhook endpoint or tunnel Event Grid events to localhost. Option C is wrong because SQL Server Express triggers are database-level constructs and have no relationship to Event Grid event delivery. Option D is wrong because Service Bus queues are message brokers, not debugging breakpoints, and cannot be attached to a local development environment to receive Event Grid events.

100
MCQhard

You are designing an event-driven AI document processing pipeline. Incoming PDF documents are uploaded to Azure Blob Storage, triggering an Event Grid event. The event triggers an Azure Function that downloads the PDF, processes it with Azure AI Document Intelligence, and saves results to Azure Cosmos DB. Under high load, duplicate events are occasionally received by the function, causing duplicate Cosmos DB records. How should you design the Azure Function to handle idempotency?

A.Implement idempotency in the Azure Function by checking if the document record already exists in Cosmos DB or using an upsert operation with a deterministic ID.
B.Set the Event Grid retry count to zero.
C.Deploy an Azure Service Bus queue in front of Blob Storage to serialize all requests into a single partition.
D.Configure Event Grid delivery mode to 'Exactly-Once' in the subscription settings.
AnswerA

Deterministic IDs derived from the document or an existence check before writing prevent duplicate Cosmos DB records when Event Grid redelivers events. Upsert with a stable key makes the write idempotent, satisfying the constraint that repeated processing of the same PDF must not create duplicates.

Why this answer

Idempotency in an at-least-once event pipeline is achieved by making the consumer's write operation idempotent — either by checking for an existing record before insert or by using an upsert with a deterministic ID derived from the event. This ensures duplicate Event Grid deliveries produce the same final state in Cosmos DB without creating duplicate records.

Exam trap

The trap is believing Event Grid offers an 'Exactly-Once' delivery mode or that disabling retries prevents duplicates — Event Grid is at-least-once by design, so idempotency must be implemented in the consumer.

How to eliminate wrong answers

Option B is wrong because setting Event Grid retry count to zero does not prevent duplicate deliveries — Event Grid is inherently at-least-once and duplicates can occur even without retries due to internal redelivery. Option C is wrong because inserting a Service Bus queue does not eliminate duplicates; Service Bus is also at-least-once and adds complexity without solving idempotency. Option D is wrong because Event Grid does not offer an 'Exactly-Once' delivery mode — this is a fictional setting; exactly-once is not a guarantee Event Grid provides.

← PreviousPage 2 of 2 · 100 questions total

Ready to test yourself?

Try a timed practice session using only Event Driven Integration questions.