Microsoft AZ-204: Azure Event-Based and Message Solutions — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Part of the Microsoft Azure Developer Associate AZ-204 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure’s event and messaging portfolio spans four complementary services: Event Grid for reactive eventing, Event Hubs for high-throughput streaming ingestion, Service Bus for enterprise messaging and workflow coordination, and Notification Hubs for mobile push. Mastery requires knowing each service’s core abstractions, delivery and retry semantics, scaling models, and when to prefer one over another in typical application patterns such as pub/sub, command processing, telemetry ingestion, and device or user notifications.

Event Grid: Topics, Subscriptions, Schema, Filtering, and Dead-Lettering

Event Grid is a fully managed, push-based pub/sub fabric for discrete events. Publishers send events to a topic; subscribers register event subscriptions on a topic and receive matching events at supported handlers such as HTTPS webhooks, Azure Functions, Logic Apps, Service Bus, Storage Queues, and Event Hubs. Event Grid defines two publisher models. System topics are Azure-managed topic resources that represent first-party Azure services publishing events within your subscription or resource group (for example, Storage blob created, Key Vault secret rotated, or Resource Manager events). Custom topics are user-created topic endpoints your applications publish to, enabling event-driven patterns across your own services and domains. System topics require no publisher code and simplify wiring Azure resources to reactive handlers; custom topics give you full control over event contracts and lifecycle.

Event Grid events can use the native Event Grid schema or the CloudEvents v1.0 spec. With the Event Grid schema, each event includes id (unique identifier), eventType (the action), subject (hierarchical path that supports filtering), eventTime (UTC), data (payload), dataVersion, metadataVersion, and topic. CloudEvents provides a standardized set of attributes such as id, source, type, time, subject, and data. Choosing CloudEvents eases interop across platforms; Event Grid schema keeps parity with Azure-originated events and rich filtering on subject.

Event subscriptions define routing, delivery options, and filters. Basic filters include event type inclusion and subject prefix/suffix (subjectBeginsWith, subjectEndsWith), which are efficient for hierarchical resource naming. Advanced filters match on fields in the top-level event or within data (for example, numeric range comparisons, string case-insensitive contains, boolean equals, and array contains). You can combine filters for precise fan-out control, minimizing downstream work and egress.

Delivery is push with at-least-once semantics. Event Grid retries with exponential back-off. You can configure maximum retry attempts and event time-to-live; when delivery ultimately fails or the event ages out, Event Grid can dead-letter the event to a Blob Storage container you designate on the subscription. Dead-lettering preserves payloads and metadata for auditing or reprocessing; use a separate process to rehydrate and replay events if needed. Webhook endpoints participate in a validation handshake to prove ownership, and for constrained networks you can prefer managed Azure endpoints (Functions, Service Bus, Storage Queue) that do not need public exposure and can use Azure AD–backed authorization.

Event Hubs: Partitions, Consumer Groups, Throughput, Capture, and Reliable Consumption

Event Hubs ingests high-volume telemetry and log streams with low latency. Data is appended to partitions, which are independent, ordered commit logs. Partitions are chosen at creation time to parallelize throughput; producers assign a partition key to preserve per-key ordering, and the service hashes keys to partitions. Multiple readers can process partitions in parallel; within a partition, ordering is guaranteed.

Consumer groups provide independent views of the stream, allowing different processing applications to maintain their own positions without interfering with each other (for example, a real-time anomaly detector and an archival pipeline). Scaling readers horizontally requires partition ownership balancing; the SDK’s EventProcessorClient coordinates partition assignment and rebalancing across instances.

Throughput Units (TUs) in Standard tier define capacity: each TU entitles ingress and egress bandwidth quotas. Auto-inflate can scale TUs up automatically to meet peaks. Premium uses Processing Units with dedicated compute and predictable latency. Monitor throttling metrics to validate provisioning. Event Hubs supports Kafka protocol on the same endpoint, simplifying lift-and-shift from Kafka clients without running brokers.

Producers can use AMQP or HTTPS. AMQP (including AMQP-over-WebSockets on port 443) provides multiplexed, persistent connections and efficient batching, and is recommended for both send and receive. HTTPS is suitable for simple or sporadic sends but is not supported for receiving; long-polling is not available, and you sacrifice efficiency and flow control. In restricted corporate networks, AMQP-over-WebSockets preserves performance while passing through typical outbound proxies.

Checkpointing and offset management are critical for correctness. Each event has a sequence number and an offset per partition. Receivers advance through the stream, and after successfully processing a batch they checkpoint their position to durable storage—commonly an Azure Blob Storage container via the EventProcessorClient. On restart or failover, the processor resumes from the last checkpoint, achieving at-least-once processing with idempotent handlers. Without checkpoints, consumers start from a default position (latest or earliest) and risk reprocessing or skipping events.

Capture provides server-side archival by automatically writing batched, append-only Avro files to Azure Blob Storage or Azure Data Lake Storage Gen2 on a configurable time or size window. This eliminates custom batchers for cold-path analytics, enabling downstream tools (Spark, Synapse) to consume immutable stream segments with exactly-once semantics relative to the capture pipeline.

Service Bus and Queue Storage: Commands, Workflows, Sessions, and Poison Handling

Service Bus is an enterprise-grade message broker for commands, workflows, and integration scenarios that need rich delivery guarantees. Queues implement point-to-point messaging; one competing consumer receives each message. Topics with subscriptions enable pub/sub: publishers send to a topic, and independent subscriptions receive copies based on rules. Subscription rules can be SQL filters, correlation filters, or boolean true filters that compute per-message inclusion and can add or modify message properties via actions.

Sessions provide ordered, exclusive processing for related messages. Assign a SessionId on messages that belong together (for example, all steps in Order 123). A receiver accepts the session lock and processes messages in arrival order for that session, maintaining optional session state, then releases the session to allow the next consumer to take ownership. This is the preferred pattern for FIFO at scale. Without sessions, ordering is not guaranteed across competing consumers.

Service Bus supports PeekLock and ReceiveAndDelete modes. PeekLock is the default for reliability: a consumer locks a message for the lock duration, processes it, then settles it by Complete. If processing fails, the consumer can Abandon (making it available again), Defer (postpone retrieval until later by sequence number), or Dead-letter (move to the entity’s separate dead-letter subqueue with reason and error description). ReceiveAndDelete trades reliability for throughput by removing the message immediately upon receipt.

Key properties control lifecycle. Time to Live (TTL) can be set at the entity default and overridden per message; expired messages are dead-lettered or dropped based on configuration. Lock duration controls how long a message stays locked for processing; the SDK can auto-renew locks for long work within maximum limits. Max delivery count is configured per queue or subscription; after that many delivery attempts (Abandon or lock loss), the message is automatically moved to the dead-letter queue (DLQ). Operators drain DLQ for diagnostics or reprocessing with corrective logic.

Azure Queue Storage is a simpler, massively scalable queueing service with a REST interface, best for basic decoupling, high fan-out, and cost-sensitive workloads. It provides at-least-once delivery, a visibility timeout to hide messages during processing, and per-message TTL (default 7 days, configurable, including never-expire). Individual messages are limited in size, and features such as sessions, transactions, ordering guarantees, duplicate detection, dead-letter subqueues, and advanced filters are not available. Choose Queue Storage for simple background work and very high throughput at low cost. Choose Service Bus when you need sophisticated routing (topics/subscriptions), FIFO via sessions, scheduled delivery, deferral, transactions across entities, duplicate detection windows, AMQP support, or when integration reliability and governance matter. A common pattern is to fan in lightweight events via Event Grid or Queue Storage and coordinate business-critical commands and state transitions on Service Bus.

Notification Hubs: Push Routing and Platform Credential Management

Notification Hubs is a cross-platform push engine that manages device registrations at scale and routes targeted notifications to Apple (APNs), Android (FCM), Windows (WNS), and other platforms. Applications register devices using tags and tag expressions, enabling precise audience selection (for example, user:42 AND region:emea OR topic:promotions). Templates let you send a single, localized payload that platform-specific renderers expand, reducing server logic and enabling per-device personalization with minimal backend branching. The Installation model streamlines device lifecycle management by encapsulating platform handle, tags, and templates in a single resource per device.

Platform credential management is central to reliable delivery. For APNs, upload certificate-based or token-based credentials (with Key ID, Team ID, and .p8 token) and choose sandbox or production endpoints per hub or namespace to segregate environments. For FCM, configure the appropriate server credentials (for HTTP v1, use a Google service account with OAuth2 scopes). For WNS, register the app to obtain Package SID and client secret. Credentials rotate periodically; schedule rotation and monitor feedback channels for invalid device handles. Notification Hubs uses SAS for hub-level authentication from your app server, while Azure AD roles protect management operations. Use tagging conventions to partition multi-tenant apps and throttle sends with scheduled or batched pushes to meet platform quotas.

Practical Problem Scenario

Starbucks is rolling out a global mobile ordering experience that must notify customers when orders are ready, process barista workflow steps reliably, and analyze equipment telemetry for proactive maintenance.

Wire up event-driven order lifecycle with Event Grid

Create a custom Event Grid topic OrderEvents and publish discrete domain events such as OrderPlaced, PaymentAuthorized, and OrderReady. Use subject paths like /stores/{storeId}/orders/{orderId} to enable prefix filtering by store. Configure subscriptions: one to a Service Bus topic for workflow processing and one to an Azure Function for lightweight enrichment. Event Grid is chosen for low-latency fan-out, schema normalization (CloudEvents), and efficient filtering that avoids unnecessary downstream invocations.

Coordinate barista workflow with Service Bus topics and sessions

Define a Service Bus topic Orders with subscriptions per processing stage (Preparation, Handoff), each with correlation or SQL filters on eventType. Publish commands as messages with SessionId = {orderId} to guarantee per-order FIFO. Consumers use PeekLock with auto lock renewal and Complete on success; on transient failure, Abandon triggers retry; on persistent failure or poison messages, Max delivery count moves them to DLQ for later inspection. TTL on stage-specific messages prevents stale work after store close. Service Bus is chosen for ordered, reliable command handling, rich settlement, and rule-based pub/sub.

Ingest and archive equipment telemetry with Event Hubs

Provision an Event Hub Telemetry with sufficient partitions to parallelize by deviceId and enable auto-inflate TUs to absorb peaks. Device gateways send via AMQP-over-WebSockets to traverse corporate proxies efficiently. Use the EventProcessorClient with Blob Storage checkpointing to run anomaly detection and alerting in near real time. Enable Capture to ADLS Gen2 for immutable Avro archives supporting offline analytics in Synapse. Event Hubs is chosen for sustained, high-throughput ingestion with durable offsets and easy cold-path export.

Target push notifications with Notification Hubs

Register mobile devices using the Installation model, tagging each with user:{userId}, store:{storeId}, and platform tags. Upload APNs token credentials for iOS and FCM service account for Android; separate dev and prod hubs to isolate credentials and feedback. When OrderReady events arrive, the Azure Function sends a single template notification to Notification Hubs addressed to tags user:{userId} AND store:{storeId}. Notification Hubs is chosen for platform-agnostic routing, tag expressions, and centralized credential management at global scale.

Ensure observability and resilience

Configure Event Grid dead-lettering to a Blob container to retain undeliverable events for audit and replay. Monitor Service Bus DLQs and expose an operator workflow to triage and requeue corrected messages. Track Event Hubs consumer lag via metrics to validate checkpointing and scale out processors when backlog grows. This combination provides end-to-end durability: at-least-once delivery with replay paths for exceptional conditions while keeping the happy path fast and cost-efficient.

This architecture cleanly separates concerns: Event Grid drives reactive orchestration, Service Bus guarantees workflow correctness and ordering, Event Hubs handles continuous telemetry at scale, and Notification Hubs delivers precise, platform-specific customer notifications with minimal backend complexity.

← Azure API Management · All domains · Azure Caching →

Practice these questions → · Timed practice on ExamRoll.io →