Microsoft AZ-204: Azure Functions e Computação sem servidor — 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 Azure Functions é um serviço de computação serverless otimizado para cargas de trabalho orientadas a eventos e de curta duração. Ele abstrai a infraestrutura para que você se concentre no código que responde a eventos de endpoints HTTP, filas, blobs, feeds de alteração de dados e serviços de streaming. Você seleciona um plano de hospedagem que rege o escalonamento, a precificação e o comportamento de cold start; vincula seu código a gatilhos e fontes de dados com associações declarativas; e, opcionalmente, compõe fluxos de trabalho confiáveis e de longa duração usando o Durable Functions. Configuração robusta, implantação repetível e observabilidade profunda com o Application Insights completam a plataforma para sistemas de nível de produção.

Planos de Hospedagem, Escalonamento e Cold Starts

A seleção de um plano de hospedagem determina as características de execução e o custo.

• Plano Consumption:

  • Escalonamento e precificação: Pague por execução e consumo de recursos. A plataforma escalona horizontalmente (scales out) de forma automática com base em eventos. O número de instâncias é reduzido a zero quando ocioso.
  • Limites de execução: O tempo limite (timeout) da função é configurável em até 10 minutos para funções não HTTP; funções HTTP têm tempos limite práticos mais curtos devido à conectividade do cliente.
  • Cold start: Ocorrem cold starts após períodos de ociosidade ou scale-out, quando novas instâncias são inicializadas. O tempo de inicialização depende da linguagem, das dependências e do tamanho da aplicação.
  • Rede/recursos: Suporta redes públicas por padrão. Conjunto de recursos limitado em comparação com o plano Premium (por exemplo, sem integração com VNET). Deployment slots não estão disponíveis.

• Plano Premium:

  • Escalonamento e precificação: Escalona com base em eventos, mas mantém instâncias “pré-aquecidas” (pre-warmed) para eliminar cold starts. A cobrança é feita por segundos de núcleo (core seconds) e memória alocada para instâncias ativas e pré-aquecidas.
  • Limites de execução: Duração de execução praticamente ilimitada (sujeita às restrições do cliente HTTP). Recomendado para cargas de trabalho sensíveis à latência ou mais pesadas.
  • Mitigação de cold start: Instâncias pré-aquecidas mantêm o runtime ativo. Você controla o número de instâncias pré-aquecidas por plano, proporcionando latência previsível sob picos de carga (burst).
  • Rede/recursos: Suporte para integração com VNET, private endpoints, tamanhos de instância maiores e deployment slots.

• Plano Dedicated (App Service):

  • Escalonamento e precificação: Executa em instâncias provisionadas do App Service com regras manuais ou de autoscale. Você paga pelo plano do App Service subjacente, independentemente do uso.
  • Limites de execução: Sem tempo limite (timeout) imposto pela plataforma para execução em segundo plano (background). Ideal quando você já tem capacidade ociosa no App Service ou precisa de desempenho consistente.
  • Mitigação de cold start: Habilite o Always On para manter a aplicação carregada. Não há escalonamento para zero; as instâncias permanecem ativas (warm).

Escolha o plano Consumption para cargas de trabalho esporádicas com custo otimizado, o Premium para necessidades de baixa latência e VNET, e o Dedicated ao consolidar com a capacidade existente do App Service ou quando for necessário controle total. Para latência ultrabaixa, o plano Premium com instâncias pré-aquecidas ou o Dedicated com Always On reduzem os cold starts. Minimize ainda mais o impacto do cold start reduzindo dependências, usando a opção run-from-package e inicializando clientes de forma tardia (lazily).

Gatilhos e Associações

As funções são ativadas por gatilhos e interagem com dados por meio de associações (bindings). Gatilhos definem como e quando uma função é executada. Associações conectam-se declarativamente a serviços externos para entrada/saída (input/output) sem a necessidade de código SDK imperativo.

Gatilhos comuns:

• Gatilho HTTP: Expõe endpoints para APIs no estilo REST ou webhooks. Os níveis de autorização incluem Anonymous, Function e Admin, aplicados por meio de chaves ou autenticação da plataforma. Considere a idempotência e os timeouts para tarefas de longa duração; descarregue para uma fila ou para o Durable Functions quando necessário.
• Gatilho de Temporizador: Agendamentos baseados em CRON são executados em uma única instância por aplicativo (por temporizador). Use expressões NCRONTAB com configuração de fuso horário. Ideal para trabalhos de manutenção, polling e limpeza.
• Gatilho do Azure Storage Queue: Responde a mensagens em uma fila. Suporta o manuseio de mensagens “poison” (envenenadas) com uma fila -poison após um limiar na contagem de remoções da fila (dequeue). Configure o tamanho do lote (batch size), o timeout de visibilidade e a concorrência via host.json.
• Gatilho do Azure Blob Storage: Reage a eventos de criação/atualização de blobs usando uma combinação de polling e notificações do Event Grid. Use padrões de caminho (path patterns) para definir o escopo de contêineres e prefixos. Entenda a consistência eventual e o comportamento de novas tentativas (retry) para uploads de blobs grandes.
• Gatilho do Azure Event Hubs: Consome fluxos de eventos de alta vazão (high-throughput) com checkpointing. Configure a concorrência por partição, o tamanho do lote e o prefetch para otimizar a vazão. Adequado para telemetria e processamento de streams com a ordem preservada por partição.
• Gatilho do Azure Service Bus: Suporta filas (queue) ou assinaturas de tópicos (topic subscription). Configure os comportamentos de maxConcurrentCalls, prefetch e auto-complete. As filas de mensagens mortas (dead-letter queues) capturam mensagens que excedem as tentativas de entrega para inspeção posterior.
• Gatilho do Azure Cosmos DB: Escuta o feed de alterações (change feed) para inserções e atualizações. Escala com o número de partições físicas; garanta o provisionamento de RUs suficientes. Use a coleção de concessões (leases collection) para coordenar o scale-out entre as instâncias.

Associações (Bindings):

• Associações de entrada (Input bindings): Fornecem dados para a função, ex: conteúdo de um blob, entidade de uma tabela, documentos do Cosmos DB ou metadados de uma mensagem de fila. Em .NET, atributos (ex: [BlobInput]) ou o function.json definem a associação; em outras linguagens, a configuração é declarativa.
• Associações de saída (Output bindings): Gravam dados sem SDKs, ex: enfileirar uma mensagem, criar um blob, enviar para o Event Hub/Service Bus ou gravar no Cosmos DB. As funções podem ter múltiplas associações de saída ou retornar uma única saída a partir da assinatura da função.
• Expressões de associação (Binding expressions): Parametrizam detalhes de conexão e caminhos usando placeholders, ex: {queueTrigger}, {rand-guid} e configurações de aplicativo baseadas no ambiente. As propriedades de conexão referenciam nomes de configurações do aplicativo, permitindo a rotação e o gerenciamento de segredos. Prefira conexões baseadas em identidade com identidade gerenciada (managed identity) onde houver suporte para evitar embutir segredos.
• Concorrência e lotes (Concurrency and batch): Controle a concorrência e os tamanhos dos lotes no host.json por extensão (queues, serviceBus, eventHub) para ajustar a vazão e o uso de memória. Valide o tratamento de mensagens “poison”/“dead-letter” para garantir que as falhas sejam expostas.

Projete gatilhos e associações para idempotência, contrapressão (backpressure) e isolamento de falhas. Para fontes com entrega do tipo “pelo menos uma vez” (at-least-once) (filas, Event Hubs, Service Bus), escreva funções que sejam idempotentes e resilientes a novas tentativas (retries).

Durable Functions: Padrões de Orquestração Confiáveis

O Durable Functions estende o Azure Functions com orquestração stateful (com estado) e confiável para fluxos de trabalho (workflows) de longa duração, usando um framework de tarefas duráveis.

Tipos de função:

• Funções de Orquestrador: Descrevem a lógica do workflow em código usando construções determinísticas. Os orquestradores reproduzem o estado ao receber eventos e devem evitar APIs não determinísticas (DateTime.Now, números aleatórios, chamadas de rede) sem os auxiliares apropriados. Use as APIs do cliente de orquestração do Durable para iniciar, consultar e gerenciar instâncias.
• Funções de Atividade: Executam unidades de trabalho discretas, como chamar APIs externas, realizar operações intensivas de CPU ou tarefas de I/O. As atividades permitem novas tentativas (são retryable) e são escaláveis de forma independente.
• Funções de Entidade: Fornecem entidades duráveis e endereçáveis com estado pequeno e consistente e operações (ex: contadores, estado de um dispositivo). As entidades processam operações serializadas com consistência de thread único (single-threaded).

Padrões:

• Encadeamento de Funções: Sequencia atividades em uma ordem definida (A → B → C), passando os resultados para a próxima. Útil para pipelines com dependências.
• Fan-out/fan-in: Inicia múltiplas atividades em paralelo e agrega os resultados. Os orquestradores coordenam com uma semântica semelhante ao Task.WhenAll. Use isso para o processamento paralelo de tarefas independentes.
• Interação Humana (eventos externos): Aguarda por uma entrada externa (ex: aprovação) usando WaitForExternalEvent com timeouts e escalonamento. Combine com temporizadores duráveis para implementar SLAs e lógica de compensação.
• APIs HTTP Assíncronas: Inicia orquestrações e retorna um 202 Accepted com URLs de status/consulta. Os clientes fazem polling nos endpoints de status expostos pela associação do cliente Durable para obter o resultado ou o estado final.
• Monitor: Checkpoints recorrentes que são executados em um agendamento, ex: fazer polling em um endpoint até que uma condição seja atendida, usando temporizadores duráveis para evitar reter recursos de computação.
• Agregador/Entidade: Armazena um estado pequeno junto à lógica usando funções de entidade para coordenação refinada sem um workflow completo.

O Durable Functions garante a execução “pelo menos uma vez” (at-least-once) das atividades e a progressão “exatamente uma vez” (exactly-once) do estado do orquestrador. Elas persistem o estado no armazenamento (o padrão é o Azure Storage); garanta que a conta de armazenamento atenda às necessidades de vazão (throughput) e confiabilidade. Use políticas de retry personalizadas para falhas transitórias e dispare eventos para interação externa. Para processos muito longos, as orquestrações duráveis podem ser executadas por dias ou meses com durabilidade integrada.

Configuração, Implantação e Observabilidade

A configuração do Function App é feita em camadas e ciente do ambiente.

• host.json: Controla o comportamento do runtime e das extensões. Configure o logging (amostragem, níveis de log), functionTimeout, configurações de extensão (tamanhos de lote, concorrência, prefetch) e a versão do esquema JSON. Mantenha o host.json no controle de versão.
• local.settings.json: Configurações de desenvolvimento local, incluindo connection strings e configurações do aplicativo. Não é implantado no Azure. Trate os segredos de forma apropriada; exclua-os de repositórios públicos e use user-secrets ou injeção de ambiente para o desenvolvimento local.
• Application settings: Armazenadas na configuração do Function App (App Service). As configurações críticas incluem AzureWebJobsStorage (para a conta de armazenamento usada por gatilhos, logs e checkpoints), connection strings específicas de extensões e qualquer configuração personalizada. Marque os segredos como configurações de slot para evitar que sejam trocados (swapped). Use referências do Key Vault com identidade gerenciada para evitar o armazenamento de segredos em texto plano.

Opções de implantação:

• Zip Deploy: Faça o upload de um ZIP com seus artefatos de build para o aplicativo. Rápido e simples para CI/CD. Use

undefined

ou a API zipdeploy. Ele grava os arquivos no diretório de conteúdo.

• Run-From-Package: Defina

undefined

para a URL de um pacote (ou 1 para o mais recente). O runtime monta o pacote como somente leitura, melhorando o cold start e eliminando problemas de bloqueio de arquivos durante a implantação. Armazene o pacote no Blob Storage com uma SAS URL para rollbacks reprodutíveis.

• Deployment slots: Slots de stage (homologação) e produção permitem trocas (swaps) sem tempo de inatividade (zero-downtime) com aquecimento (warmup). Os slots são suportados nos planos Premium e Dedicated. Configure configurações específicas do slot (flag de slot setting) para segredos e endpoints para evitar vazamento entre ambientes. Use o warmup preSwap para validar extensões e bindings antes que o tráfego seja movido.

Monitoramento com o Application Insights:

• Logs de invocação: Cada invocação de função emite telemetria estruturada, incluindo Requests, Traces, Exceptions e Dependencies. Use

undefined

(ou equivalente) para logs estruturados. IDs de operação e correlação conectam a atividade e as dependências entre os serviços.

• Live Metrics: Visão em tempo real de throughput, falhas e latência sem amostragem. Útil para observar implantações, escalonamento e hot paths. Filtre pelo nome da função para isolar problemas.
• Falhas e confiabilidade: Inspecione Exceptions, Requests com falha e falhas de dependência. Configure alertas sobre taxa de falha, anomalias no

undefined

ou crescimento da fila DLQ/poison. Para gatilhos de Storage Queue, monitore a fila

undefined

; para Service Bus/Event Hubs, monitore a saúde da dead-letter e do checkpoint. Ajuste as políticas de repetição (retry) e backoff no host.json para reduzir o impacto de erros transitórios.

• Rastreamento distribuído (Distributed tracing): Habilite os cabeçalhos de rastreamento W3C para propagar a correlação através de HTTP e mensagens. Para Durable Functions, o framework vincula a telemetria de orquestração e atividade, auxiliando no diagnóstico de ponta a ponta. Ajuste a amostragem para equilibrar custo e fidelidade.

Opere as funções com automação de implantação (GitHub Actions/Azure Pipelines), health probes para endpoints HTTP e ajustes cientes do auto-scaling. Mantenha os pacotes enxutos, armazene clientes em cache (ex: HttpClient, cliente do Service Bus) como singletons estáticos e valide se as configurações de conexão dos bindings são resolvidas na inicialização para evitar falhas em tempo de execução.

Cenário de Problema Prático

A Contoso Retail lança um serviço de promoções que aplica descontos em tempo real quando os clientes adicionam itens ao carrinho. O backend deve responder a um tráfego de alta variação com baixa latência, chamar uma API de precificação de terceiros e atualizar um documento de carrinho no Cosmos DB. A equipe de operações deseja implantações sem tempo de inatividade (zero-downtime) e visibilidade profunda das falhas.

1. Escolha o plano de hospedagem e estruture o aplicativo

• Use um plano Azure Functions Premium com duas instâncias pré-aquecidas e integração com VNET. O plano Premium elimina cold starts para interações de carrinho sensíveis à latência e protege o tráfego de saída para a API de terceiros através de um NAT ou firewall na VNET.
• Crie um único Function App com uma função acionada por HTTP para o endpoint do carrinho e um orquestrador de Durable Functions para coordenar a obtenção de descontos e a atualização do carrinho.

2. Implemente a orquestração com Durable Functions para confiabilidade e paralelismo

• Função orquestradora: Encadear etapas para validar a entrada, fazer fan-out para buscar descontos para cada item do carrinho em paralelo por meio de funções de atividade e, em seguida, fazer fan-in para agregar o melhor preço. A orquestração com Durable Functions garante um fluxo de controle determinístico e resiliência a reinicializações.
• Funções de atividade: Uma atividade chama a API de terceiros com políticas de repetição (retry); outra atualiza o carrinho no Cosmos DB por meio de um output binding. As atividades encapsulam a E/S externa e podem ser repetidas independentemente, sem duplicar a lógica do orquestrador.

3. Configure gatilhos e bindings para simplicidade

• Gatilho HTTP com autenticação de Função (Function auth) para aceitar requisições assinadas do frontend web. Retorne 202 com uma URL de status para carrinhos de longa duração, ou 200 para caminhos rápidos.
• Output binding do Cosmos DB na atividade para fazer o upsert do documento do carrinho. As expressões de binding usam o

undefined

do payload HTTP para direcionar à chave de partição correta.

• Use identidade gerenciada e conexões baseadas em identidade para o Cosmos DB e referências do Key Vault, removendo segredos das configurações do aplicativo.

4. Otimize a configuração e a implantação

• O

undefined

define o

undefined

como ilimitado (Premium) e configura timeouts de HTTP amigáveis para service mesh. Os níveis de log são ajustados para Information em produção e a amostragem (Samples) é definida para 20% para controlar os custos.

• Use run-from-package com pacotes armazenados em um contêiner Blob versionado. Implante via CI com

undefined

e faça o swap de um slot de stage para produção para lançamentos sem tempo de inatividade. Marque as connection strings e os endpoints de API como configurações de slot para evitar vazamento entre ambientes.

5. Monitore e opere

• Habilite o Application Insights e o Live Metrics para observar o throughput e a latência durante os lançamentos. Configure alertas para HTTP 5xx, taxa de falha de dependência para a API de precificação e aumentos em orquestrações falhas de Durable Functions.
• Use o rastreamento distribuído para correlacionar a requisição HTTP com a orquestração do Durable e as dependências de atividade, acelerando a análise de causa raiz para problemas intermitentes de terceiros.

Por que essas escolhas:

• O plano Premium com instâncias pré-aquecidas garante latência consistentemente baixa e suporta integração com VNET para saída segura (egress).
• O Durable Functions fornece encadeamento confiável e fan-out/fan-in com gerenciamento automático de estado e repetição (retry) para chamadas de API externas.
• Os bindings reduzem o código repetitivo (boilerplate) e impõem um acesso a dados consistente e declarativo ao Cosmos DB.
• O Run-from-package e os slots entregam implantações repetíveis e atômicas sem problemas de bloqueio de arquivo ou tempo de inatividade.
• O Application Insights oferece observabilidade em tempo real, correlação e alertas alinhados com os SLAs operacionais.

← Azure App Service e Web Apps · Todos os domínios · Azure Storage e Blob Storage →

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

Navegar Microsoft →