Microsoft AZ-204: Soluções do Azure Baseadas em Eventos e Mensagens — Guia de estudos

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

Faz parte do Microsoft Azure Developer Associate AZ-204 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O portfólio de eventos e mensagens do Azure abrange quatro serviços complementares: Event Grid para eventos reativos, Event Hubs para ingestão de streaming de alta taxa de transferência, Service Bus para mensagens corporativas e coordenação de fluxos de trabalho, e Notification Hubs para notificações push para dispositivos móveis. A maestria exige o conhecimento das abstrações principais de cada serviço, semântica de entrega e de nova tentativa, modelos de escalonamento e quando preferir um em detrimento do outro em padrões de aplicação típicos como pub/sub, processamento de comandos, ingestão de telemetria e notificações de dispositivo ou usuário.

Event Grid: Tópicos, Assinaturas, Esquema, Filtragem e Dead-Lettering

O Event Grid é uma estrutura pub/sub totalmente gerenciada e baseada em push para eventos discretos. Publicadores (publishers) enviam eventos para um tópico; assinantes (subscribers) registram assinaturas de eventos em um tópico e recebem os eventos correspondentes em manipuladores (handlers) suportados, como webhooks HTTPS, Azure Functions, Logic Apps, Service Bus, Storage Queues e Event Hubs. O Event Grid define dois modelos de publicador. Tópicos do sistema (System topics) são recursos de tópico gerenciados pelo Azure que representam serviços primários do Azure publicando eventos dentro da sua assinatura ou grupo de recursos (por exemplo, blob de armazenamento criado, segredo do Key Vault rotacionado ou eventos do Resource Manager). Tópicos personalizados (Custom topics) são endpoints de tópico criados pelo usuário para os quais suas aplicações publicam, permitindo padrões orientados a eventos em seus próprios serviços e domínios. Tópicos do sistema não exigem código de publicador e simplificam a conexão de recursos do Azure a manipuladores reativos; tópicos personalizados dão a você controle total sobre os contratos e o ciclo de vida dos eventos.

Os eventos do Event Grid podem usar o esquema nativo do Event Grid ou a especificação CloudEvents v1.0. Com o esquema do Event Grid, cada evento inclui id (identificador único), eventType (a ação), subject (caminho hierárquico que suporta filtragem), eventTime (UTC), data (carga útil), dataVersion, metadataVersion e topic. O CloudEvents fornece um conjunto padronizado de atributos como id, source, type, time, subject e data. A escolha do CloudEvents facilita a interoperabilidade entre plataformas; o esquema do Event Grid mantém paridade com eventos originados no Azure e oferece filtragem rica no subject.

As assinaturas de eventos definem roteamento, opções de entrega e filtros. Filtros básicos incluem a inclusão do tipo de evento e prefixo/sufixo do assunto (subjectBeginsWith, subjectEndsWith), que são eficientes para nomes de recursos hierárquicos. Filtros avançados correspondem a campos no evento de nível superior ou dentro dos dados (data) (por exemplo, comparações de intervalo numérico, ‘contém’ de string sem distinção entre maiúsculas e minúsculas, ‘igual a’ booleano e ‘contém’ de array). Você pode combinar filtros para um controle preciso de fan-out, minimizando o trabalho downstream e a saída de dados (egress).

A entrega é por push com semântica “pelo menos uma vez” (at-least-once). O Event Grid faz novas tentativas com back-off exponencial. Você pode configurar o número máximo de tentativas e o tempo de vida do evento (time-to-live); quando a entrega falha definitivamente ou o evento expira, o Event Grid pode enviar o evento para uma fila de mensagens mortas (dead-letter) em um contêiner do Blob Storage que você designar na assinatura. O dead-lettering preserva as cargas úteis e os metadados para auditoria ou reprocessamento; use um processo separado para reidratar e reproduzir os eventos, se necessário. Endpoints de webhook participam de um handshake de validação para provar a propriedade e, para redes com restrições, você pode preferir endpoints gerenciados do Azure (Functions, Service Bus, Storage Queue) que não precisam de exposição pública e podem usar autorização baseada no Azure AD.

Event Hubs: Partições, Grupos de Consumidores, Throughput, Capture e Consumo Confiável

O Event Hubs ingere streams de telemetria e logs de alto volume com baixa latência. Os dados são anexados a partições, que são logs de commit independentes e ordenados. As partições são escolhidas no momento da criação para paralelizar o throughput; os produtores atribuem uma chave de partição (partition key) para preservar a ordem por chave, e o serviço aplica um hash nas chaves para distribuí-las entre as partições. Vários leitores podem processar partições em paralelo; dentro de uma partição, a ordenação é garantida.

Grupos de consumidores (consumer groups) fornecem visualizações independentes do stream, permitindo que diferentes aplicações de processamento mantenham suas próprias posições sem interferir umas com as outras (por exemplo, um detector de anomalias em tempo real e um pipeline de arquivamento). A escalabilidade horizontal dos leitores exige o balanceamento da posse das partições; o EventProcessorClient do SDK coordena a atribuição e o rebalanceamento de partições entre as instâncias.

As Unidades de Throughput (TUs) na camada Standard definem a capacidade: cada TU concede cotas de largura de banda de entrada (ingress) e saída (egress). O Auto-inflate pode escalar as TUs automaticamente para atender aos picos de demanda. A camada Premium usa Unidades de Processamento (Processing Units) com computação dedicada e latência previsível. Monitore as métricas de throttling (limitação) para validar o provisionamento. O Event Hubs suporta o protocolo Kafka no mesmo endpoint, simplificando a migração (lift-and-shift) de clientes Kafka sem a necessidade de executar brokers.

Os produtores podem usar AMQP ou HTTPS. O AMQP (incluindo AMQP-over-WebSockets na porta 443) oferece conexões multiplexadas e persistentes e envio em lote (batching) eficiente, sendo recomendado tanto para envio quanto para recebimento. O HTTPS é adequado para envios simples ou esporádicos, mas não é suportado para recebimento; o long-polling não está disponível, e você sacrifica a eficiência e o controle de fluxo. Em redes corporativas restritas, o AMQP-over-WebSockets preserva o desempenho ao passar por proxies de saída típicos.

O checkpointing e o gerenciamento de offset são críticos para a corretude do processamento. Cada evento possui um número de sequência (sequence number) e um offset por partição. Os receptores avançam pelo stream e, após processar um lote com sucesso, fazem o checkpoint de sua posição em um armazenamento durável — geralmente um contêiner do Azure Blob Storage por meio do EventProcessorClient. Em caso de reinicialização ou failover, o processador retoma a partir do último checkpoint, alcançando um processamento do tipo “pelo menos uma vez” (at-least-once) com handlers idempotentes. Sem checkpoints, os consumidores iniciam a partir de uma posição padrão (a mais recente ou a mais antiga) e correm o risco de reprocessar ou pular eventos.

O Capture oferece arquivamento do lado do servidor, gravando automaticamente arquivos Avro em lote e de acréscimo (append-only) no Azure Blob Storage ou no Azure Data Lake Storage Gen2, com base em uma janela de tempo ou tamanho configurável. Isso elimina a necessidade de agrupadores (batchers) personalizados para análise de dados frios (cold-path), permitindo que ferramentas downstream (Spark, Synapse) consumam segmentos de stream imutáveis com semântica “exatamente uma vez” (exactly-once) em relação ao pipeline de captura.

Service Bus e Queue Storage: Comandos, Workflows, Sessões e Tratamento de Mensagens Suspeitas (Poison Handling)

O Service Bus é um message broker de nível empresarial para comandos, workflows e cenários de integração que precisam de garantias de entrega robustas. As filas (Queues) implementam mensagens ponto a ponto; um consumidor concorrente recebe cada mensagem. Tópicos (Topics) com assinaturas (subscriptions) habilitam o padrão pub/sub: publicadores (publishers) enviam para um tópico, e assinaturas independentes recebem cópias com base em regras. As regras de assinatura podem ser filtros SQL, filtros de correlação ou filtros booleanos verdadeiros que computam a inclusão por mensagem e podem adicionar ou modificar propriedades da mensagem por meio de ações.

As sessões (Sessions) fornecem processamento ordenado e exclusivo para mensagens relacionadas. Atribua um SessionId em mensagens que pertencem umas às outras (por exemplo, todas as etapas do Pedido 123). Um receptor aceita o bloqueio da sessão e processa as mensagens na ordem de chegada para essa sessão, mantendo um estado de sessão opcional, e então libera a sessão para permitir que o próximo consumidor assuma a posse. Este é o padrão preferido para FIFO em escala. Sem sessões, a ordenação não é garantida entre consumidores concorrentes.

O Service Bus suporta os modos PeekLock e ReceiveAndDelete. PeekLock é o padrão para confiabilidade: um consumidor bloqueia uma mensagem pela duração do bloqueio, a processa e então a liquida com Complete. Se o processamento falhar, o consumidor pode usar Abandon (tornando-a disponível novamente), Defer (adiando a recuperação para mais tarde pelo número de sequência) ou Dead-letter (movendo-a para a subfila de mensagens mortas separada da entidade com o motivo e a descrição do erro). ReceiveAndDelete troca confiabilidade por taxa de transferência (throughput), removendo a mensagem imediatamente após o recebimento.

Propriedades-chave controlam o ciclo de vida. O Time to Live (TTL) pode ser definido como padrão na entidade e sobrescrito por mensagem; mensagens expiradas são movidas para a dead-letter ou descartadas com base na configuração. A duração do bloqueio (Lock duration) controla por quanto tempo uma mensagem permanece bloqueada para processamento; o SDK pode renovar automaticamente os bloqueios para trabalhos longos dentro dos limites máximos. A contagem máxima de entregas (Max delivery count) é configurada por fila ou assinatura; após esse número de tentativas de entrega (por Abandon ou perda de bloqueio), a mensagem é movida automaticamente para a fila de mensagens mortas (dead-letter queue, DLQ). Os operadores esvaziam a DLQ para diagnóstico ou reprocessamento com lógica corretiva.

O Azure Queue Storage é um serviço de enfileiramento mais simples e massivamente escalável com uma interface REST, ideal para desacoplamento básico, alto fan-out e cargas de trabalho sensíveis ao custo. Ele fornece entrega pelo menos uma vez (at-least-once), um tempo limite de visibilidade (visibility timeout) para ocultar mensagens durante o processamento e TTL por mensagem (padrão de 7 dias, configurável, incluindo nunca expirar). As mensagens individuais são limitadas em tamanho, e recursos como sessões, transações, garantias de ordenação, detecção de duplicatas, subfilas de mensagens mortas e filtros avançados não estão disponíveis. Escolha o Queue Storage para trabalho simples em segundo plano e altíssima taxa de transferência a baixo custo. Escolha o Service Bus quando precisar de roteamento sofisticado (tópicos/assinaturas), FIFO via sessões, entrega agendada, adiamento (deferral), transações entre entidades, janelas de detecção de duplicatas, suporte a AMQP, ou quando a confiabilidade e a governança da integração forem importantes. Um padrão comum é fazer o fan-in de eventos leves via Event Grid ou Queue Storage e coordenar comandos críticos de negócios e transições de estado no Service Bus.

Notification Hubs: Roteamento de Push e Gerenciamento de Credenciais da Plataforma

O Notification Hubs é um mecanismo de push multiplataforma que gerencia registros de dispositivos em grande escala e roteia notificações direcionadas para Apple (APNs), Android (FCM), Windows (WNS) e outras plataformas. As aplicações registram dispositivos usando tags e expressões de tag, permitindo uma seleção precisa de público (por exemplo, user:42 AND region:emea OR topic:promotions). Os modelos (templates) permitem que você envie uma única carga útil localizada que os renderizadores específicos da plataforma expandem, reduzindo a lógica do servidor e permitindo a personalização por dispositivo com o mínimo de ramificações no backend. O modelo de Instalação (Installation model) simplifica o gerenciamento do ciclo de vida do dispositivo, encapsulando o identificador da plataforma (platform handle), tags e modelos em um único recurso por dispositivo.

O gerenciamento de credenciais da plataforma é fundamental para uma entrega confiável. Para o APNs, faça o upload de credenciais baseadas em certificado ou em token (com Key ID, Team ID e token .p8) e escolha endpoints de sandbox ou produção por hub ou namespace para separar os ambientes. Para o FCM, configure as credenciais de servidor apropriadas (para HTTP v1, use uma conta de serviço do Google com escopos OAuth2). Para o WNS, registre o aplicativo para obter o Package SID e o client secret. As credenciais são rotacionadas periodicamente; agende a rotação e monitore os canais de feedback para identificadores de dispositivo inválidos. O Notification Hubs usa SAS para autenticação no nível do hub a partir do seu servidor de aplicação, enquanto as funções do Azure AD protegem as operações de gerenciamento. Use convenções de tags para particionar aplicativos multilocatários (multi-tenant) e limitar os envios com pushes agendados ou em lote para atender às cotas da plataforma.

Cenário de Problema Prático

A Starbucks está implementando uma experiência global de pedidos por celular que deve notificar os clientes quando os pedidos estiverem prontos, processar as etapas do fluxo de trabalho do barista de forma confiável e analisar a telemetria dos equipamentos para manutenção proativa.

1. Conectar o ciclo de vida de pedidos orientado a eventos com o Event Grid

• Crie um tópico personalizado do Event Grid chamado OrderEvents e publique eventos de domínio discretos, como OrderPlaced, PaymentAuthorized e OrderReady. Use caminhos de assunto (subject paths) como /stores/{storeId}/orders/{orderId} para permitir a filtragem por prefixo por loja. Configure as assinaturas: uma para um tópico do Service Bus para processamento do fluxo de trabalho e uma para uma Azure Function para enriquecimento leve. O Event Grid é escolhido pela distribuição fan-out de baixa latência, normalização de esquema (CloudEvents) e filtragem eficiente que evita invocações desnecessárias downstream.

2. Coordenar o fluxo de trabalho do barista com tópicos e sessões do Service Bus

• Defina um tópico do Service Bus chamado Orders com assinaturas por estágio de processamento (Preparation, Handoff), cada uma com filtros de correlação ou SQL em eventType. Publique comandos como mensagens com SessionId = {orderId} para garantir o FIFO por pedido. Os consumidores usam PeekLock com renovação automática de bloqueio (auto lock renewal) e Complete em caso de sucesso; em caso de falha transitória, Abandon aciona uma nova tentativa; em caso de falha persistente ou mensagens maliciosas (poison messages), a contagem máxima de entrega (Max delivery count) as move para a DLQ para inspeção posterior. O TTL em mensagens específicas de estágio evita trabalho obsoleto após o fechamento da loja. O Service Bus é escolhido pelo tratamento de comandos ordenado e confiável, recursos avançados de liquidação (rich settlement) e pub/sub baseado em regras.

3. Ingerir e arquivar telemetria de equipamentos com o Event Hubs

• Provisione um Event Hub chamado Telemetry com partições suficientes para paralelizar por deviceId e habilite TUs de inflação automática (auto-inflate) para absorver picos. Os gateways de dispositivo enviam via AMQP-over-WebSockets para atravessar proxies corporativos de forma eficiente. Use o EventProcessorClient com checkpointing no Blob Storage para executar detecção de anomalias e alertas quase em tempo real. Habilite a Captura (Capture) para o ADLS Gen2 para arquivos Avro imutáveis que suportam análises offline no Synapse. O Event Hubs é escolhido pela ingestão sustentada e de alta taxa de transferência (throughput), com offsets duráveis e exportação fácil para o caminho frio (cold-path).

4. Direcionar notificações push com o Notification Hubs

• Registre dispositivos móveis usando o modelo de Instalação (Installation model), marcando cada um com as tags user:{userId}, store:{storeId} e tags de plataforma. Faça o upload das credenciais de token do APNs para iOS e da conta de serviço do FCM para Android; separe os hubs de desenvolvimento e produção para isolar credenciais e feedback. Quando os eventos OrderReady chegam, a Azure Function envia uma única notificação de modelo para o Notification Hubs endereçada às tags user:{userId} AND store:{storeId}. O Notification Hubs é escolhido pelo roteamento agnóstico de plataforma, expressões de tag e gerenciamento centralizado de credenciais em escala global.

5. Garantir observabilidade e resiliência

• Configure o dead-lettering do Event Grid para um contêiner de Blob para reter eventos não entregues para auditoria e repetição (replay). Monitore as DLQs do Service Bus e exponha um fluxo de trabalho de operador para triar e reenfileirar mensagens corrigidas. Acompanhe o atraso do consumidor (consumer lag) do Event Hubs por meio de métricas para validar o checkpointing e escalar horizontalmente os processadores quando o backlog crescer. Essa combinação fornece durabilidade de ponta a ponta: entrega do tipo “pelo menos uma vez” (at-least-once) com caminhos de repetição (replay) para condições excepcionais, mantendo o caminho feliz (happy path) rápido e com custo-benefício.

Essa arquitetura separa claramente as responsabilidades: o Event Grid impulsiona a orquestração reativa, o Service Bus garante a correção e a ordenação do fluxo de trabalho, o Event Hubs lida com telemetria contínua em grande escala e o Notification Hubs entrega notificações precisas e específicas da plataforma para os clientes com complexidade mínima no backend.

← Azure API Management · Todos os domínios · Cache →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →