Microsoft AZ-204: Azure Event-gebaseerde en Berichtenoplossingen — Studiegids

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

Onderdeel van de Microsoft Azure Developer Associate AZ-204 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Het portfolio van Azure voor events en messaging omvat vier complementaire services: Event Grid voor reactieve eventing, Event Hubs voor streaming-ingestie met hoge doorvoersnelheid, Service Bus voor enterprise messaging en workflowcoördinatie, en Notification Hubs voor mobiele pushnotificaties. Om dit te beheersen, moet u kennis hebben van de kernabstracties, leverings- en retry-semantiek, schaalmodellen van elke service, en wanneer u de ene boven de andere moet verkiezen in typische applicatiepatronen zoals pub/sub, commandoverwerking, telemetrie-ingestie en apparaat- of gebruikersnotificaties.

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

Event Grid is een volledig beheerde, push-gebaseerde pub/sub-fabric voor discrete events. Publishers sturen events naar een topic; subscribers registreren event-abonnementen op een topic en ontvangen overeenkomende events bij ondersteunde handlers zoals HTTPS-webhooks, Azure Functions, Logic Apps, Service Bus, Storage Queues en Event Hubs. Event Grid definieert twee publisher-modellen. Systeemtopics zijn door Azure beheerde topic-resources die first-party Azure-services vertegenwoordigen die events publiceren binnen uw abonnement of resourcegroep (bijvoorbeeld Storage-blob aangemaakt, Key Vault-geheim geroteerd of Resource Manager-events). Aangepaste topics zijn door de gebruiker gemaakte topic-eindpunten waar uw applicaties naar publiceren, wat event-driven patronen mogelijk maakt voor uw eigen services en domeinen. Systeemtopics vereisen geen publisher-code en vereenvoudigen het koppelen van Azure-resources aan reactieve handlers; aangepaste topics geven u volledige controle over event-contracten en de levenscyclus.

Event Grid-events kunnen het native Event Grid-schema of de CloudEvents v1.0-specificatie gebruiken. Met het Event Grid-schema bevat elk event id (unieke identifier), eventType (de actie), subject (hiërarchisch pad dat filtering ondersteunt), eventTime (UTC), data (payload), dataVersion, metadataVersion en topic. CloudEvents biedt een gestandaardiseerde set attributen zoals id, source, type, time, subject en data. De keuze voor CloudEvents vergemakkelijkt de interoperabiliteit tussen platforms; het Event Grid-schema behoudt pariteit met events die afkomstig zijn van Azure en biedt uitgebreide filtering op subject.

Event-abonnementen definiëren routering, leveringsopties en filters. Basisfilters omvatten het opnemen van event-types en prefix/suffix voor het onderwerp (subjectBeginsWith, subjectEndsWith), wat efficiënt is voor hiërarchische resourcenamen. Geavanceerde filters matchen op velden in het top-level event of binnen de data (bijvoorbeeld numerieke bereikvergelijkingen, hoofdletterongevoelige ‘contains’ voor strings, booleaanse ’equals’ en ‘contains’ voor arrays). U kunt filters combineren voor nauwkeurige fan-out-controle, waardoor downstream werk en egress worden geminimaliseerd.

Levering is push-gebaseerd met ‘at-least-once’-semantiek. Event Grid probeert het opnieuw met exponentiële back-off. U kunt het maximale aantal nieuwe pogingen en de time-to-live van een event configureren; wanneer de levering uiteindelijk mislukt of het event veroudert, kan Event Grid het event ‘dead-letteren’ naar een Blob Storage-container die u op het abonnement aanwijst. Dead-lettering behoudt payloads en metadata voor auditing of herverwerking; gebruik een apart proces om events indien nodig opnieuw te hydrateren en af te spelen. Webhook-eindpunten nemen deel aan een validatie-handshake om eigendom te bewijzen, en voor netwerken met beperkingen kunt u de voorkeur geven aan beheerde Azure-eindpunten (Functions, Service Bus, Storage Queue) die geen publieke blootstelling nodig hebben en autorisatie ondersteund door Azure AD kunnen gebruiken.

Event Hubs: Partities, Consumergroepen, Doorvoer, Capture en Betrouwbare Consumptie

Event Hubs verwerkt telemetrie- en logstreams met een hoog volume en lage latentie. Data wordt toegevoegd aan partities, die onafhankelijke, geordende commit-logs zijn. Partities worden bij het aanmaken gekozen om de doorvoer te parallelliseren; producers wijzen een partitiesleutel toe om de volgorde per sleutel te behouden, en de service hasht de sleutels naar partities. Meerdere readers kunnen partities parallel verwerken; binnen een partitie is de volgorde gegarandeerd.

Consumergroepen bieden onafhankelijke weergaven van de stream, waardoor verschillende verwerkingsapplicaties hun eigen posities kunnen bijhouden zonder elkaar te storen (bijvoorbeeld een real-time anomaliedetector en een archiveringspipeline). Horizontaal schalen van readers vereist het balanceren van het partitie-eigendom; de EventProcessorClient van de SDK coördineert de toewijzing en herbalancering van partities over verschillende instanties.

Throughput Units (TU’s) in de Standard-laag definiëren de capaciteit: elke TU geeft recht op quota voor ingress- en egress-bandbreedte. Auto-inflate kan TU’s automatisch opschalen om pieken op te vangen. Premium gebruikt Processing Units met dedicated compute en voorspelbare latentie. Monitor throttling-metrics om de provisioning te valideren. Event Hubs ondersteunt het Kafka-protocol op hetzelfde eindpunt, wat een ’lift-and-shift’ van Kafka-clients vereenvoudigt zonder dat er brokers hoeven te worden beheerd.

Producers kunnen AMQP of HTTPS gebruiken. AMQP (inclusief AMQP-over-WebSockets op poort 443) biedt gemultiplexte, persistente verbindingen en efficiënte batchverwerking, en wordt aanbevolen voor zowel verzenden als ontvangen. HTTPS is geschikt voor eenvoudige of sporadische verzendingen, maar wordt niet ondersteund voor ontvangst; long-polling is niet beschikbaar, en je levert in op efficiëntie en flow control. In beperkte bedrijfsnetwerken behoudt AMQP-over-WebSockets de prestaties terwijl het door typische uitgaande proxy’s gaat.

Checkpointing en offsetbeheer zijn cruciaal voor correctheid. Elk event heeft een volgnummer en een offset per partitie. Receivers doorlopen de stream en na het succesvol verwerken van een batch ‘checkpointen’ ze hun positie naar duurzame opslag - meestal een Azure Blob Storage-container via de EventProcessorClient. Bij een herstart of failover hervat de processor vanaf het laatste checkpoint, wat ‘at-least-once’ verwerking met idempotente handlers mogelijk maakt. Zonder checkpoints starten consumers vanaf een standaardpositie (nieuwste of oudste) en lopen ze het risico events opnieuw te verwerken of over te slaan.

Capture zorgt voor server-side archivering door automatisch gebundelde, ‘append-only’ Avro-bestanden weg te schrijven naar Azure Blob Storage of Azure Data Lake Storage Gen2 binnen een configureerbaar tijd- of groottesvenster. Dit elimineert de noodzaak voor op maat gemaakte batchers voor ‘cold-path’-analyses, waardoor downstream tools (Spark, Synapse) onveranderlijke streamsegmenten kunnen consumeren met ’exactly-once’-semantiek ten opzichte van de capture-pipeline.

Service Bus en Queue Storage: Commands, Workflows, Sessies en Poison Handling

Service Bus is een message broker van enterprise-kwaliteit voor commands, workflows en integratiescenario’s die uitgebreide aflevergaranties vereisen. Queues implementeren point-to-point messaging; één concurrerende consumer ontvangt elk bericht. Topics met subscriptions maken pub/sub mogelijk: publishers sturen naar een topic, en onafhankelijke subscriptions ontvangen kopieën op basis van regels. Subscription-regels kunnen SQL-filters, correlatiefilters of booleaanse ’true’-filters zijn die per bericht de opname bepalen en berichteigenschappen kunnen toevoegen of wijzigen via acties.

Sessies bieden geordende, exclusieve verwerking voor gerelateerde berichten. Wijs een SessionId toe aan berichten die bij elkaar horen (bijvoorbeeld alle stappen in Bestelling 123). Een ontvanger accepteert de sessie-lock en verwerkt berichten in volgorde van binnenkomst voor die sessie, onderhoudt optionele sessiestatus, en geeft vervolgens de sessie vrij zodat de volgende consumer het eigendom kan overnemen. Dit is het voorkeurspatroon voor FIFO op grote schaal. Zonder sessies is de volgorde niet gegarandeerd tussen concurrerende consumers.

Service Bus ondersteunt de modi PeekLock en ReceiveAndDelete. PeekLock is de standaard voor betrouwbaarheid: een consumer vergrendelt een bericht voor de duur van de lock, verwerkt het en handelt het vervolgens af met Complete. Als de verwerking mislukt, kan de consumer het bericht Abandon (weer beschikbaar maken), Defer (ophalen uitstellen tot later via het sequencenummer), of Dead-letter (verplaatsen naar de aparte dead-letter subqueue van de entiteit met een reden en foutbeschrijving). ReceiveAndDelete ruilt betrouwbaarheid in voor doorvoersnelheid door het bericht onmiddellijk na ontvangst te verwijderen.

Belangrijke eigenschappen beheren de levenscyclus. Time to Live (TTL) kan als standaard voor de entiteit worden ingesteld en per bericht worden overschreven; verlopen berichten worden naar de dead-letter queue verplaatst of verwijderd, afhankelijk van de configuratie. De lock-duur bepaalt hoe lang een bericht vergrendeld blijft voor verwerking; de SDK kan locks automatisch verlengen voor langdurig werk binnen de maximale limieten. Max delivery count wordt per queue of subscription geconfigureerd; na dat aantal afleverpogingen (Abandon of verlies van de lock) wordt het bericht automatisch verplaatst naar de dead-letter queue (DLQ). Operators verwerken de DLQ voor diagnostiek of herverwerking met corrigerende logica.

Azure Queue Storage is een eenvoudigere, massaal schaalbare queueing-service met een REST-interface, het meest geschikt voor basisontkoppeling, hoge fan-out en kostengevoelige workloads. Het biedt at-least-once delivery, een visibility timeout om berichten te verbergen tijdens de verwerking, en een TTL per bericht (standaard 7 dagen, configureerbaar, inclusief nooit-verlopen). Individuele berichten zijn beperkt in grootte, en functies zoals sessies, transacties, volgordegaranties, duplicatendetectie, dead-letter subqueues en geavanceerde filters zijn niet beschikbaar. Kies Queue Storage voor eenvoudig achtergrondwerk en een zeer hoge doorvoersnelheid tegen lage kosten. Kies Service Bus wanneer u geavanceerde routering (topics/subscriptions), FIFO via sessies, geplande aflevering, uitstel, transacties over entiteiten heen, duplicatendetectie-vensters, AMQP-ondersteuning nodig heeft, of wanneer de betrouwbaarheid en het beheer van de integratie van belang zijn. Een veelgebruikt patroon is het ‘fan-in’ verzamelen van lichtgewicht events via Event Grid of Queue Storage en het coördineren van bedrijfskritische commands en statustransities op Service Bus.

Notification Hubs: Push-routering en beheer van platformreferenties

Notification Hubs is een cross-platform push-engine die apparaatregistraties op schaal beheert en gerichte meldingen routeert naar Apple (APNs), Android (FCM), Windows (WNS) en andere platforms. Applicaties registreren apparaten met behulp van tags en tag-expressies, wat een precieze doelgroepselectie mogelijk maakt (bijvoorbeeld user:42 AND region:emea OR topic:promotions). Met sjablonen kunt u een enkele, gelokaliseerde payload versturen die door platformspecifieke renderers wordt uitgewerkt. Dit vermindert de serverlogica en maakt personalisatie per apparaat mogelijk met minimale vertakkingen in de backend. Het Installation-model stroomlijnt het beheer van de levenscyclus van apparaten door de platform-handle, tags en sjablonen in één enkele resource per apparaat te encapsuleren.

Het beheer van platformreferenties is cruciaal voor een betrouwbare bezorging. Voor APNs uploadt u certificaat- of token-gebaseerde referenties (met Key ID, Team ID en een .p8-token) en kiest u sandbox- of productie-eindpunten per hub of namespace om omgevingen te scheiden. Voor FCM configureert u de juiste serverreferenties (gebruik voor HTTP v1 een Google-serviceaccount met OAuth2-scopes). Voor WNS registreert u de app om een Package SID en client secret te verkrijgen. Referenties verlopen periodiek; plan de rotatie en monitor feedbackkanalen voor ongeldige apparaat-handles. Notification Hubs gebruikt SAS voor authenticatie op hub-niveau vanaf uw app-server, terwijl Azure AD-rollen beheeroperaties beschermen. Gebruik tag-conventies om multi-tenant apps te partitioneren en beperk het aantal verzendingen met geplande of gebundelde pushes om aan platformquota’s te voldoen.

Praktijkscenario

Starbucks rolt een wereldwijde mobiele bestelervaring uit die klanten moet informeren wanneer bestellingen klaar zijn, de workflowstappen van barista’s betrouwbaar moet verwerken en de telemetrie van apparatuur moet analyseren voor proactief onderhoud.

Een event-driven order-levenscyclus opzetten met Event Grid

Creëer een custom Event Grid-topic OrderEvents en publiceer discrete domein-events zoals OrderPlaced, PaymentAuthorized en OrderReady. Gebruik subject-paden zoals /stores/{storeId}/orders/{orderId} om prefix-filtering per winkel mogelijk te maken. Configureer subscriptions: één naar een Service Bus-topic voor workflowverwerking en één naar een Azure Function voor lichtgewicht verrijking. Er wordt gekozen voor Event Grid vanwege de low-latency fan-out, schemanormalisatie (CloudEvents) en efficiënte filtering die onnodige downstream-aanroepen voorkomt.

De workflow van de barista coördineren met Service Bus-topics en -sessies

Definieer een Service Bus-topic Orders met subscriptions per verwerkingsfase (Preparation, Handoff), elk met correlatie- of SQL-filters op eventType. Publiceer commando’s als berichten met SessionId = {orderId} om FIFO per bestelling te garanderen. Consumers gebruiken PeekLock met automatische lock-vernieuwing en Complete bij succes; bij een tijdelijke fout activeert Abandon een nieuwe poging; bij een persistente fout of ‘poison messages’ verplaatst Max delivery count ze naar de DLQ voor latere inspectie. Een TTL op fasespecifieke berichten voorkomt verouderd werk na sluitingstijd van de winkel. Er wordt gekozen voor Service Bus vanwege de geordende, betrouwbare commando-afhandeling, uitgebreide settlement-opties en op regels gebaseerde pub/sub.

Telemetrie van apparatuur inlezen en archiveren met Event Hubs

Provisioneer een Event Hub Telemetry met voldoende partities om te parallelliseren op deviceId en schakel auto-inflate TU’s in om pieken op te vangen. Apparaat-gateways verzenden via AMQP-over-WebSockets om efficiënt door bedrijfs-proxy’s te navigeren. Gebruik de EventProcessorClient met Blob Storage-checkpointing om anomaliedetectie en alarmering in nagenoeg real-time uit te voeren. Schakel Capture naar ADLS Gen2 in voor onveranderlijke Avro-archieven die offline analyses in Synapse ondersteunen. Er wordt gekozen voor Event Hubs vanwege de duurzame, high-throughput inname met persistente offsets en eenvoudige cold-path export.

Gerichte pushmeldingen versturen met Notification Hubs

Registreer mobiele apparaten met behulp van het Installation-model en tag elk apparaat met user:{userId}, store:{storeId} en platform-tags. Upload APNs-tokenreferenties voor iOS en een FCM-serviceaccount voor Android; scheid dev- en prod-hubs om referenties en feedback te isoleren. Wanneer OrderReady-events binnenkomen, stuurt de Azure Function een enkele sjabloonmelding naar Notification Hubs, geadresseerd aan de tags user:{userId} AND store:{storeId}. Er wordt gekozen voor Notification Hubs vanwege de platform-agnostische routering, tag-expressies en het gecentraliseerde beheer van referenties op wereldwijde schaal.

Zorgdragen voor observability en veerkracht

Configureer Event Grid dead-lettering naar een Blob-container om onbestelbare events te bewaren voor audit en replay. Monitor Service Bus DLQ’s en stel een operator-workflow beschikbaar om gecorrigeerde berichten te beoordelen en opnieuw in de wachtrij te plaatsen. Volg de consumer lag van Event Hubs via metrics om de checkpointing te valideren en processors op te schalen wanneer de achterstand groeit. Deze combinatie biedt end-to-end duurzaamheid: at-least-once delivery met replay-paden voor uitzonderlijke omstandigheden, terwijl het ‘happy path’ snel en kostenefficiënt blijft.

Deze architectuur scheidt de verantwoordelijkheden duidelijk: Event Grid stuurt de reactieve orkestratie aan, Service Bus garandeert de correctheid en volgorde van de workflow, Event Hubs verwerkt continue telemetrie op schaal, en Notification Hubs levert precieze, platformspecifieke klantmeldingen met minimale complexiteit in de backend.

← Azure API Management · Alle domeinen · Azure Caching →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →