Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame AZ-204 avalia. Leia de cima a baixo ou pule para uma seção.
Precisa de um plano do App Service para uma aplicação web de produção com domínios personalizados/SSL, autoscale e slots de implantação.
Use o nível de plano Standard (S1) do App Service ou superior.
Por quê: Standard é o nível mínimo que suporta todas as funcionalidades chave de produção: domínios personalizados com SSL, autoscale e slots de implantação. O nível Basic não possui autoscale e slots.
Realizar uma implantação sem tempo de inatividade para um App Service e manter as configurações de produção (como strings de conexão) no slot de produção.
Use slots de implantação. Marque as configurações específicas de produção como "configurações de slot de implantação" (sticky). Realize uma operação de swap para implantar.
Por quê: A operação de swap "aquece" o slot de staging antes de redirecionar o tráfego. As configurações sticky não se movem com o código durante um swap, evitando que as configurações de staging entrem em produção.
Um App Service precisa se conectar a um recurso on-premises (ex: SQL Server) sem uma VPN ou ExpressRoute.
Use App Service Hybrid Connections. Instale o Hybrid Connection Manager (HCM) on-premises.
Por quê: Hybrid Connections fornecem um túnel TCP seguro para recursos on-premises sem exigir portas de firewall de entrada, uma VPN ou integração de VNet. O HCM inicia a conexão de saída.
Uma Azure Function no plano Consumption experience atrasos de cold start, causando latência.
Migre para o plano Functions Premium e configure um mínimo de uma instância pré-aquecida.
Por quê: O plano Premium elimina cold starts mantendo um número especificado de instâncias sempre prontas. É mais econômico do que um plano Dedicated completo para este fim.
Uma Azure Function no plano Consumption está a exceder o tempo limite porque leva mais de 10 minutos para ser executada.
Migre a função para um plano Premium ou Dedicated (App Service).
Por quê: O plano Consumption tem um tempo limite máximo de 10 minutos. Os planos Premium e Dedicated suportam tempos de execução muito mais longos (até 60 minutos ou ilimitado).
Processar um grande número de itens independentes em paralelo e esperar que todos sejam concluídos antes de prosseguir.
Implemente o padrão Fan-out/Fan-in do Durable Functions. O orquestrador chama várias funções de atividade concorrentemente e usa `Task.WhenAll` (ou equivalente) para aguardar a conclusão.
Por quê: Este padrão é projetado para execução paralela, que é muito mais eficiente do que o processamento sequencial (Function Chaining) para tarefas independentes.
Um workflow de longa duração deve aguardar um evento externo, como aprovação humana, com um tempo limite.
Use o padrão Human Interaction do Durable Functions. Combine `waitForExternalEvent` com um `createTimer`. Use `Task.WhenAny` para prosseguir quando o evento chega ou o timer expira.
Por quê: Este padrão permite que as orquestrações pausem indefinidamente sem consumir computação, aguardando um gatilho externo, enquanto também gerem tempos limite de forma elegante.
Uma aplicação contentorizada precisa escalar para zero instâncias quando não há tráfego para minimizar custos.
Use Azure Container Apps com uma regra de escalonamento baseada em KEDA (ex: requisições HTTP ou tamanho da fila).
Por quê: Container Apps com scalers KEDA podem escalar para zero réplicas quando ociosas e escalar sob demanda, o que é ideal para workloads orientadas a eventos ou intermitentes. O escalonamento de CPU/memória não pode escalar para zero.
Um microsserviço de backend no Azure Container Apps deve ser acessível apenas por outras aplicações de container dentro do mesmo ambiente, não da internet pública.
Ative o ingresso na aplicação de container de backend e defina a visibilidade do tráfego como `internal`.
Por quê: O ingresso interno restringe o acesso ao ambiente do Container Apps. Outras aplicações no ambiente podem descobrir e chamar o serviço usando seu FQDN interno.
Precisa executar um único container para uma tarefa simples, um teste ou um trabalho em lote sem orquestração.
Use Azure Container Instances (ACI).
Por quê: ACI é a maneira mais rápida e simples de executar um único container sem gerenciar qualquer infraestrutura subjacente. Use Container Apps ou AKS para orquestrar aplicações multi-container.
Precisa construir e enviar uma imagem Docker para o Azure Container Registry (ACR) a partir de um Dockerfile local, mas o Docker não está instalado localmente.
Use o comando `az acr build`.
Por quê: `az acr build` descarrega o processo de construção para o ACR Tasks na cloud. Ele envia o contexto de construção para o Azure, constrói a imagem e a armazena diretamente no registry.
Projetar um container Cosmos DB com consultas frequentes filtrando por uma propriedade específica (ex: `region`).
Selecione a propriedade de maior cardinalidade e mais frequentemente consultada como a chave de partição (ex: `/region`).
Por quê: Consultas que incluem a chave de partição na cláusula `WHERE` são direcionadas a uma única partição lógica, evitando consultas fan-out entre partições dispendiosas e minimizando o consumo de RU.
Uma aplicação distribuída globalmente exige que as leituras sempre retornem a escrita mais recentemente confirmada.
Configure o nível de consistência da conta Cosmos DB para Strong.
Por quê: A consistência Strong oferece uma garantia de linearizabilidade, assegurando que as leituras estão sempre atualizadas. Outros níveis (Session, Bounded Staleness, Eventual) trocam consistência por menor latência e maior disponibilidade.
Precisa processar todos os documentos novos ou atualizados em um container Cosmos DB em tempo real para atualizar uma view materializada.
Use uma Azure Function com um trigger Cosmos DB, que aproveita o processador de change feed.
Por quê: O change feed fornece um log persistente de alterações. O trigger Cosmos DB com o processador de change feed automatiza o gerenciamento de estado e o balanceamento de carga em várias instâncias de função.
Precisa realizar uma operação atômica em múltiplos documentos dentro da mesma partição lógica (ex: criar dois e atualizar um).
Use a API `TransactionalBatch` no Cosmos DB SDK. Todas as operações devem ter como alvo a mesma chave de partição.
Por quê: TransactionalBatch garante que todas as operações no lote são bem-sucedidas ou falham como uma única unidade atômica, prevenindo atualizações parciais. É mais eficiente do que um stored procedure para operações em lote do lado do cliente.
Um workload do Cosmos DB é imprevisível, com picos e quedas significativas no tráfego.
Configure o throughput provisionado de autoscale no banco de dados ou container.
Por quê: Autoscale escala automaticamente as RU/s com base no uso, garantindo desempenho durante picos e economia de custos durante quedas. Ele escala entre 10% e 100% das RU/s máximas configuradas.
Os dados são acessados frequentemente no início, depois infrequentemente, e finalmente arquivados para retenção a longo prazo.
Use uma combinação de níveis de acesso Hot, Cool e Archive. Automatize as transições com uma política de Lifecycle Management.
Por quê: Alinhar o nível de acesso com o padrão de acesso otimiza o custo. Hot é para acesso frequente, Cool para acesso infrequente e Archive para armazenamento de longo prazo e baixo custo. As políticas de Lifecycle Management automatizam isso.
Evitar que múltiplos processos modifiquem o mesmo blob simultaneamente.
Implemente leases de blob. Um processo adquire um bloqueio de escrita exclusivo (lease) em um blob antes de modificá-lo.
Por quê: Leases fornecem controle de concorrência pessimista. Uma vez que um lease é adquirido, nenhum outro cliente pode escrever no blob até que o lease seja liberado ou expire.
Armazenar logs de auditoria no Blob Storage e garantir que não podem ser modificados ou excluídos por um período de retenção fixo (ex: 7 anos).
Configure uma política de retenção baseada em tempo no container de blob. Para retenções indefinidas, use um legal hold.
Por quê: Políticas de armazenamento imutável impõem o estado WORM (Write-Once, Read-Many), o que é essencial para conformidade. Uma vez bloqueada, uma política baseada em tempo não pode ser encurtada.
Precisa categorizar blobs com atributos chave-valor e consultá-los em toda uma conta de armazenamento sem listar todos os blobs.
Use Blob Index Tags.
Por quê: As index tags são indexadas pelo serviço de armazenamento e podem ser usadas em consultas de filtragem do lado do servidor (`Find Blobs by Tags`). Metadados não são indexados e só podem ser filtrados do lado do cliente após a listagem.
Autenticar usuários de forma segura em uma Single-Page Application (SPA) e adquirir tokens para uma API de backend.
Use o fluxo Authorization Code com PKCE (Proof Key for Code Exchange).
Por quê: Esta é a melhor prática de segurança atual para clientes públicos. Evita expor tokens na URL (ao contrário do fluxo Implicit obsoleto) e não requer um client secret.
Um serviço de fundo ou daemon precisa chamar uma API protegida (como Microsoft Graph) sem um usuário autenticado.
Use o fluxo Client Credentials com permissões de Application.
Por quê: Este fluxo autentica a própria aplicação usando um client secret ou certificado. As permissões de Application concedem acesso em toda a organização, sujeitas ao consentimento do administrador.
Uma API web de camada intermediária precisa chamar uma API downstream enquanto preserva a identidade do usuário original autenticado.
Implemente o fluxo On-Behalf-Of (OBO).
Por quê: A API de camada intermediária troca o token de acesso do usuário por um novo token com escopo para a API downstream. Isso delega a identidade do usuário de forma segura.
Uma aplicação que usa MSAL precisa adquirir tokens de forma eficiente, minimizando as solicitações ao usuário.
Sempre chame `AcquireTokenSilent()` primeiro. Se falhar com uma `MsalUiRequiredException`, recorra a um método interativo como `AcquireTokenInteractive()`.
Por quê: `AcquireTokenSilent()` verifica o cache em busca de um token válido ou usa um refresh token para obter um novo sem interação do usuário. Isso é fundamental para uma boa experiência do usuário.
Um recurso Azure (ex: App Service, Function) precisa acessar outro recurso Azure (ex: Key Vault, SQL Database) sem armazenar credenciais em código ou configuração.
Ative uma managed identity (atribuída ao sistema ou atribuída ao usuário) no recurso de origem e conceda a ela permissões RBAC no recurso de destino.
Por quê: Managed identity fornece uma identidade no Microsoft Entra ID para o recurso. O Azure gerencia o ciclo de vida das credenciais, eliminando a necessidade de os desenvolvedores lidarem com segredos.
Múltiplos recursos Azure precisam compartilhar a mesma identidade e permissões para acessar outros serviços.
Crie uma única managed identity atribuída ao usuário e atribua-a a todos os recursos necessários.
Por quê: Uma managed identity atribuída ao usuário tem um ciclo de vida independente de qualquer recurso, tornando-a reutilizável. Uma managed identity atribuída ao sistema está ligada a um único recurso e é excluída quando o recurso é.
Precisa conceder acesso a segredos do Key Vault usando grupos do Azure AD com permissões granulares no nível de segredo individual.
Use o modelo de permissão Azure RBAC para Key Vault. Atribua roles como `Key Vault Secrets User` aos principals.
Por quê: RBAC permite atribuições de roles no vault, ou no escopo de chave/segredo/certificado individual, fornecendo mais granularidade do que as políticas de acesso, que se aplicam a todos os objetos de um tipo no vault.
Uma aplicação precisa absorver mudanças de configuração do Azure App Configuration sem reiniciar.
Use o provedor/SDK do App Configuration e configure-o para atualizar monitorizando uma chave sentinel.
Por quê: O SDK pode verificar periodicamente uma chave sentinel em busca de alterações. Ao atualizar as configurações da aplicação, você também atualiza a chave sentinel, o que aciona todos os clientes para atualizar sua configuração.
Precisa ativar uma nova funcionalidade para um grupo específico de usuários (ex: beta testers) e uma percentagem do público geral.
Use um feature flag do Azure App Configuration com um filtro de Targeting.
Por quê: O filtro de Targeting suporta lançamentos complexos, permitindo definir públicos com base em usuários e grupos com percentagens específicas, além de uma percentagem de lançamento padrão para todos os outros.
Precisa gerar um token seguro de curta duração para conceder a um cliente acesso a um blob específico.
Crie uma SAS de delegação de usuário.
Por quê: Uma SAS de delegação de usuário é assinada com credenciais do Microsoft Entra ID, não com a chave da conta de armazenamento. Isso é mais seguro porque evita distribuir a chave da conta e o acesso pode ser revogado através de políticas do Entra ID.
Resolver um problema de desempenho em uma aplicação de microsserviços visualizando dependências e identificando qual serviço downstream está causando alta latência.
Use a funcionalidade Application Map no Application Insights.
Por quê: Application Map descobre e exibe automaticamente uma visão topológica da sua aplicação distribuída, mostrando métricas de saúde e desempenho para cada componente e as chamadas entre eles.
Rastrear uma única requisição de usuário à medida que ela flui por múltiplos microsserviços.
Use a visão de detalhes de transação End-to-End no Application Insights. Toda a telemetria é correlacionada por um `operation_Id` compartilhado.
Por quê: Os SDKs do Application Insights propagam automaticamente os cabeçalhos W3C Trace Context, permitindo que toda a telemetria para uma única operação seja correlacionada com o mesmo `operation_Id`, permitindo uma visão unificada.
Diagnosticar um problema de produção: desempenho lento intermitente versus uma exceção intermitente.
Para desempenho lento, use Application Insights Profiler. Para exceções, use Snapshot Debugger.
Por quê: Profiler captura rastreamentos de tempo no nível do método para requisições lentas ("hot paths"). Snapshot Debugger captura a pilha de chamadas e variáveis locais no momento em que uma exceção é lançada.
Reduzir o volume de dados e o custo do Application Insights de uma aplicação de alto tráfego, mantendo dados estatisticamente válidos.
Ative o adaptive sampling na configuração do SDK da aplicação.
Por quê: Adaptive sampling ajusta automaticamente a taxa de amostragem para permanecer dentro de um volume de dados alvo, amostrando mais agressivamente durante alto tráfego e menos durante baixo tráfego, preservando telemetria importante.
Monitorizar continuamente a disponibilidade de um endpoint de aplicação web a partir de múltiplas localizações geográficas.
Configure um teste de disponibilidade padrão (teste de ping de URL) no Application Insights.
Por quê: Os testes de disponibilidade enviam requisições para o seu endpoint de datacenters Azure em todo o mundo, fornecendo monitoramento proativo de uptime e capacidade de resposta e acionando alertas em caso de falha.
Crie um alerta que dispara quando uma métrica de desempenho (ex: tempo médio de resposta) excede um limite específico por um período definido.
Crie uma regra de alerta de métrica do Azure Monitor. Defina o recurso e a métrica, configure um limite estático, tipo de agregação e período de avaliação. Link para um grupo de ação.
Por quê: Alertas de métrica fornecem monitoramento de baixa latência e com estado de dados de métricas quase em tempo real, o que é ideal para alertas baseados em desempenho.
Controlar o uso da API limitando a frequência de chamadas (ex: 100 chamadas/min) versus o total de chamadas em um período mais longo (ex: 10.000 chamadas/mês).
Use a política `rate-limit` para frequência de chamadas. Use a política `quota` para o volume total de chamadas.
Por quê: `rate-limit` limita picos de curto prazo e retorna HTTP 429. `quota` impõe um limite de uso por um período mais longo (ex: um período de cobrança) e retorna HTTP 403 quando excedido.
Armazenar em cache as respostas da API no API Management para reduzir a carga do backend, com a chave de cache variando por um cabeçalho de requisição.
Use uma política `<cache-lookup vary-by-header="..." />` na seção de entrada e uma política `<cache-store duration="..." />` na seção de saída.
Por quê: Esta combinação de políticas em duas partes permite o armazenamento em cache de respostas. `cache-lookup` verifica um item em cache, e `cache-store` salva a resposta. Os atributos `vary-by` garantem entradas de cache únicas para diferentes variações de requisição.
Gerenciar alterações em uma API. Uma alteração breaking é necessária vs. uma alteração non-breaking precisa ser testada.
Use Versions para alterações breaking (ex: /v1, /v2). Use Revisions para alterações non-breaking e rollouts seguros e faseados.
Por quê: O versionamento permite que múltiplas versões de API estejam ativas simultaneamente. Revisions permitem que você modifique uma API offline, teste-a e depois a torne a revisão "atual" sem tempo de inatividade.
Notificar múltiplos serviços downstream independentes quando um evento ocorre em um serviço Azure (ex: blob criado, grupo de recursos criado).
Use Azure Event Grid. Crie um tópico de sistema para o recurso Azure e event subscriptions para cada handler downstream.
Por quê: Event Grid é um serviço pub/sub totalmente gerenciado e baseado em push que desacopla publicadores de eventos de assinantes, permitindo arquiteturas reativas e orientadas a eventos.
Ingerir um fluxo de alto volume de telemetria ou dados de eventos (milhões de eventos por segundo) de muitos dispositivos.
Use Azure Event Hubs.
Por quê: Event Hubs é uma plataforma de streaming de dados massivamente escalável projetada para ingestão de alto throughput. Ele usa um modelo de consumidor particionado para processamento paralelo.
Garantir que eventos da mesma origem (ex: um dispositivo IoT específico) são processados em ordem pelo mesmo consumidor.
Envie eventos para Event Hubs com uma chave de partição definida para o identificador da origem (ex: ID do dispositivo).
Por quê: Event Hubs roteia todas as mensagens com a mesma chave de partição para a mesma partição. Dentro de uma partição, a ordem das mensagens é mantida.
Processar uma sequência de mensagens relacionadas em ordem estrita First-In, First-Out (FIFO).
Use sessões do Azure Service Bus. Envie todas as mensagens relacionadas com o mesmo `SessionId`.
Por quê: Sessões fornecem um fluxo concorrente e ordenado de mensagens. Um receptor ciente de sessão bloqueia a sessão, garantindo que as mensagens são processadas sequencialmente por um único consumidor.
Um único publicador envia mensagens para um tópico, mas múltiplos assinantes querem apenas um subconjunto dessas mensagens com base nas propriedades da mensagem.
Use um tópico do Service Bus com múltiplas assinaturas. Aplique filtros SQL ou filtros de Correlation a cada assinatura.
Por quê: Este é o padrão canônico publish-subscribe com roteamento baseado em conteúdo. Cada assinatura recebe uma cópia da mensagem se ela corresponder à sua regra de filtro.
Uma mensagem não pode ser processada com sucesso após múltiplas tentativas e deve ser separada para inspeção posterior.
Deixe a mensagem falhar o processamento até que sua contagem máxima de entregas seja excedida. Ela será automaticamente movida para a Dead-Letter Queue (DLQ).
Por quê: A DLQ é uma sub-fila embutida para mensagens poison. Isso evita que uma mensagem com falha bloqueie a fila principal e permite análise e reprocessamento offline.
Escolha um serviço de mensagens para: comandos empresariais, eventos reativos ou telemetria de alto volume.
Service Bus para comandos (pedidos, transações). Event Grid para eventos reativos (blob criado, recurso alterado). Event Hubs para telemetria (dados IoT, clickstreams).
Por quê: Service Bus oferece recursos ricos como ordenação, transações e dead-lettering. Event Grid é para roteamento de eventos leve e baseado em push. Event Hubs é para streaming de dados de alto throughput.