Microsoft AZ-204: Azure App Service e Web Apps — 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 App Service é uma plataforma de hospedagem baseada em HTTP totalmente gerenciada para aplicações web, APIs REST e serviços de backend, suportando cargas de trabalho de código e contêineres em Windows e Linux. Ele oferece recursos de primeira classe para escalabilidade, fluxos de trabalho de implantação, autenticação, isolamento de rede, processamento em segundo plano e configuração segura. O domínio do serviço envolve a compreensão dos planos do App Service e sua escalabilidade, slots de implantação e gerenciamento de tráfego, caminhos de integração de CI/CD, Easy Auth, domínios personalizados e TLS, WebJobs, App Service Environment (ASE) e padrões de configuração segura com o Key Vault.

Planos, escalabilidade e slots de implantação

Um plano do App Service define os recursos de computação que hospedam suas aplicações. Todas as aplicações em um plano compartilham o mesmo pool de VMs e a mesma configuração de escalabilidade.

Níveis de preço (Pricing tiers):
- Gratuito (F1)/Compartilhado (D1): Apenas para desenvolvimento e testes. Sem SLA. Sem TLS personalizado. Sem slots de implantação.
- Básico (B1–B3): VMs dedicadas, escalabilidade horizontal manual (manual scale out). Sem autoescalabilidade (autoscale). Recursos limitados.
- Standard (S1–S3): Adiciona autoescalabilidade (autoscale) e slots de implantação. Linha de base para produção.
- Premium v2/v3 (P1v2/P1v3+): Computação mais nova, armazenamento mais rápido, recursos de rede aprimorados, redundância de zona (em SKUs suportados) e maior escalabilidade. Ideal para produção empresarial e alta taxa de transferência (throughput).
- Isolado (I1v2+) em um ASE: Dedicado à rede virtual de um cliente com isolamento de rede e escalabilidade massiva.
Scale up vs scale out:
- Scale up (escalabilidade vertical) move o plano para um SKU superior para obter mais CPU, memória, discos mais rápidos ou capacidades avançadas (ex: Premium v3 para melhor desempenho e recursos).
- Scale out (escalabilidade horizontal) aumenta o número de instâncias para distribuir a carga horizontalmente. Os níveis Standard e superiores suportam autoescalabilidade (autoscale) com regras baseadas em métricas como CPU, memória (Linux), tamanho da fila HTTP, requisições, métricas personalizadas ou agendamentos. O nível Básico suporta apenas scale out manual. A escalabilidade se aplica a todas as aplicações dentro de um plano.
Slots de implantação e troca de slots (slot swaps):
- Os níveis Standard e superiores suportam múltiplos slots (por exemplo, homologação/staging e produção). Os slots são executados no mesmo plano, cada um com seu próprio nome de host e configuração.
- A troca (swap) move o conteúdo e o estado de tempo de execução de um slot de origem para um slot de destino com tempo de inatividade quase zero, aquecendo o destino antes da transição do tráfego. Use applicationInitialization (Windows) ou verificações de saúde (health checks) para garantir a prontidão antes da troca. A troca com visualização (swap with preview) permite a validação antes de finalizar.
- Marque as entradas de configuração como configurações de slot (slot settings) para mantê-las fixas (sticky) ao slot durante as trocas (ex: strings de conexão de banco de dados, segredos e endpoints de diagnóstico). As configurações não marcadas se movem com o código durante a troca.
Roteamento de tráfego com slots:
- Roteie uma porcentagem do tráfego ao vivo para um slot de não produção para testes canário (canary testing). Cookies fixam os usuários a um slot após a atribuição para preservar a consistência da sessão.

Implantação e CI/CD: GitHub, Azure DevOps e registros de contêiner

O Deployment Center integra fluxos comuns de CI/CD:

GitHub Actions:
- O App Service pode gerar um workflow usando o build do Oryx ou a implantação de contêiner. Em um push para um branch, o Actions compila e implanta no slot selecionado. Suporte para builds de matriz (matrix builds), ambientes e segredos. Para contêineres Linux, o workflow pode compilar e enviar para o ACR ou Docker Hub, e então acionar uma implantação do web app.
Azure DevOps:
- Pipelines (YAML ou clássico) entregam estágios de build e release, aprovações, verificações de ambiente e portões de múltiplos estágios (multistage gating). Use tarefas como: Azure Web App, Azure Web App for Container ou AzureCLI para implantações habilitadas para ARM/Bicep. Grupos de variáveis e segredos apoiados pelo Key Vault centralizam a configuração.
Registros de contêiner:
- O App Service for Containers busca imagens do ACR, Docker Hub ou registros privados. Configure a implantação contínua via webhooks do ACR para a aplicação; um novo push de imagem aciona um pull e uma reinicialização. Fixe por tag ou digest. Para segurança em produção, use digests de imagem e slots canário antes de promover.
Mecânicas de implantação adicionais:
- O Kudu suporta push baseado em Git, Zip Deploy e Run From Package para builds reproduzíveis. O arquivo .deployment e scripts personalizados podem coordenar os passos de build antes que o site sirva tráfego. Para uma higiene de release de nível empresarial, combine slots com CI/CD para validar as verificações de saúde (health checks) e o aquecimento (warm-up) antes da troca (swap).

Segurança, identidade, domínios e TLS

A autenticação/autorização do App Service (Easy Auth) delega a identidade para a plataforma sem exigir middleware em seu código.

Provedores:
- Microsoft Entra ID (plataforma de identidade da Microsoft), Google, Facebook, GitHub e Twitter, além de qualquer provedor compatível com OpenID Connect, incluindo o Entra ID B2C. Configure IDs/segredos de cliente, emissor (issuer) e públicos/escopos de token permitidos. Escolha a ação de login (permitir anônimos vs. exigir autenticação).
Repositório de tokens (token store) e cabeçalhos:
- Habilite o repositório de tokens para armazenar em cache os tokens de acesso/atualização (access/refresh tokens) obtidos durante o fluxo de login, recuperáveis via /.auth/me e atualizados via /.auth/refresh. O App Service injeta as claims do usuário nos cabeçalhos da requisição (por exemplo, X-MS-CLIENT-PRINCIPAL em Base64) para que a aplicação possa derivar a identidade sem dependências de SDK. Use o endpoint de logout da plataforma para limpar as sessões.
Domínios personalizados:
- Mapeie registros CNAME (recomendado) ou A/ALIAS para o nome de host padrão da aplicação. Verifique a propriedade do domínio com registros TXT, se necessário. Vincule o nome de host personalizado no App Service.
Certificados SSL/TLS:
- Imponha o uso de HTTPS Only e defina a versão mínima do TLS. Vincule certificados via SNI (vários certificados por IP) ou SSL baseado em IP (IP dedicado). Faça o upload de certificados privados (PFX) para um controle de certificado de nível de produção. O App Service Managed Certificate fornece um certificado gratuito, de renovação automática e validado por domínio para nomes de host não curinga (non-wildcard); ele não pode ser exportado e requer um nível de serviço compatível. Use a integração com o Key Vault para gerenciar e rotacionar automaticamente certificados privados em escala.
Certificados de cliente (mTLS):
- Opcionalmente, exija certificados de cliente de entrada e passe-os para a aplicação para validação. Combine com um Web Application Firewall e proxies reversos (por exemplo, Application Gateway) para TLS de ponta a ponta (end-to-end).

Processamento em segundo plano e ambientes isolados

WebJobs e ASE abordam cenários de processamento em segundo plano e isolamento de rede.

WebJobs:
- WebJobs Contínuos rodam perpetuamente em cada instância do aplicativo web, adequados para processamento de filas ou loops de eventos. Exigem a configuração Always On (plano Standard e superior) para mantê-los em execução. A escala acompanha o número de instâncias do plano de aplicativo; aplique o comportamento de singleton no código se desejar apenas um worker ativo.
- WebJobs Disparados rodam sob demanda ou em um agendamento (CRON via settings.job). Ideal para trabalhos em lote, ETL ou manutenção periódica.
- O SDK do WebJobs fornece gatilhos e associações (triggers and bindings) para Azure Storage Queues, filas/tópicos do Service Bus, Blobs e Timers com métodos de função declarativos e checkpointing automático. Um WebJob disparado por fila reage imediatamente a novas mensagens, escala com as instâncias do aplicativo e usa o tratamento de poison queue (fila de mensagens suspeitas) para isolamento de falhas. Logs e dashboards são acessíveis no Kudu.
App Service Environment (ASE):
- O ASEv3 hospeda planos do App Service dentro da sua VNet com SKUs Isolated v2, fornecendo computação dedicada, isolamento do plano de dados e IPs privados. Escolha um ASE Externo para entrada de tráfego público ou um Internal Load Balancer (ILB) ASE para manter todo o tráfego de entrada privado dentro da VNet. Integre com DNS privado, firewalls e NVA/WAF conforme necessário.
- O ASE permite controle de saída granular, inspeção de rede e alinhamento com requisitos de conformidade. Ele suporta hospedagem em larga escala com limites de rede previsíveis e é cobrado separadamente das instâncias do plano.

Configuração, cadeias de conexão e referências do Key Vault

A configuração do aplicativo é injetada em tempo de execução e pode ser específica do slot.

Configurações do aplicativo (App settings):
- Pares de chave-valor disponíveis para o aplicativo como variáveis de ambiente. Marque como “slot settings” (configurações de slot) para manter valores distintos por slot. Utilize o caminho de Verificação de integridade (Health check) para remover instâncias não íntegras da rotação durante as implantações. Alterações disparam reinicializações do aplicativo, a menos que configurado com padrões de recarregamento dinâmico em seu framework.
Cadeias de conexão (Connection strings):
- Gerenciadas separadamente e expostas como variáveis de ambiente; aplicativos .NET também recebem configurações específicas do provedor. Os tipos incluem SQLAzure, SQLServer, MySQL, PostgreSQL e Custom. Marque como “slot settings” quando apropriado para evitar a troca de segredos.
Referências do Key Vault:
- Referencie segredos diretamente nas Configurações do Aplicativo e Cadeias de Conexão usando a sintaxe especial @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/<version>) ou URIs sem versão para captar rotações automaticamente. Atribua uma identidade gerenciada atribuída pelo sistema ou pelo usuário ao aplicativo e, em seguida, conceda a ela permissões para obter segredos (Get secret) no cofre (via RBAC ou política de acesso). A plataforma resolve e atualiza os valores sem expor os segredos na configuração do App Service. Para usar certificados TLS do Key Vault, importe-os como certificados ou use referências de certificado suportadas pela plataforma.

Aprofundamento em slots de implantação e excelência operacional

Use um slot de preparo (staging) como o alvo do CI/CD. Após a implantação:

Execute pings de aquecimento e verificações de integridade para preparar o JIT, caches e conexões de banco de dados.
Valide as diferenças de configuração usando as configurações de slot para isolar segredos e endpoints de produção.
Realize a troca com visualização (swap with preview) para testar o slot de preparo no hostname de produção antes de finalizar. Se surgirem erros, cancele a troca para reverter instantaneamente.
Para entrega progressiva, use o roteamento de tráfego para direcionar uma pequena porcentagem para o slot canário (canary) e monitore as métricas e logs do App Insights. Aumente gradualmente e, em seguida, conclua a troca quando os SLOs se mantiverem.

Cenário de Problema Prático

A Starbucks está lançando uma nova plataforma de pedidos web que deve lidar com picos durante promoções, integrar-se com logins sociais, proteger APIs internas e processar fluxos de trabalho de pedidos em segundo plano de forma confiável.

Escolha o plano Premium v3 do App Service com dois slots de implantação (preparo, produção)

Por quê: O Premium v3 oferece CPUs e SSDs mais rápidos para carregamentos de página de baixa latência e maior throughput, além de slots e autoscale. Os slots permitem trocas sem tempo de inatividade (zero-downtime) e reversão rápida (rollback) sob picos de tráfego promocional.

Implemente CI/CD com GitHub Actions para implantar no slot de preparo (staging)

Por quê: O GitHub Actions oferece automação nativa do repositório. A implantação no slot de preparo permite aquecimento e validação antes que o tráfego do cliente seja afetado. O fluxo de trabalho (workflow) usa o Oryx para compilar e implantar em cada push para a branch main, garantindo builds consistentes.

Habilite o Easy Auth com os provedores Microsoft Entra ID e Google; habilite o Token Store

Por quê: O Easy Auth delega os fluxos OAuth/OIDC, reduzindo a superfície de código de segurança personalizado. Múltiplos provedores suportam as preferências de login do consumidor. O Token Store simplifica as chamadas para APIs downstream (por exemplo, um microsserviço de perfil de fidelidade) usando tokens em cache expostos através dos endpoints /.auth.

Configure domínios personalizados e TLS

Por quê: Vincule order.starbucks.com via CNAME, imponha o uso de HTTPS (HTTPS Only) e defina o TLS 1.2 como mínimo para conformidade. Use um Certificado Gerenciado do App Service para o slot de preparo para reduzir a sobrecarga de gerenciamento e carregue um PFX da CA corporativa para o ambiente de produção para satisfazer a política de marca e de certificados.

Use o SDK do WebJobs com um gatilho de Fila do Azure Storage (Azure Storage Queue) para o processamento de pedidos

Por quê: Um WebJob contínuo processa as mensagens à medida que chegam, desacoplando o checkout do processamento do pedido e suavizando os picos. Com o Always On e o scale-out baseado no plano, o throughput aumenta automaticamente com instâncias adicionais. O tratamento de poison queue isola mensagens inválidas sem interromper o pipeline.

Proteja segredos de saída com referências do Key Vault e uma identidade gerenciada atribuída pelo sistema

Por quê: Os segredos nunca residem na configuração do App Service. A identidade tem acesso de privilégio mínimo ao Key Vault, e URIs de segredo sem versão permitem uma rotação transparente.

Proteja APIs internas com recursos de rede (networking)

Por quê: Posicione os microsserviços internos atrás de um endpoint privado; o aplicativo web público os chama através da Integração com VNet (VNet Integration) (Premium v3) para um backend protegido. Se um isolamento mais rigoroso for necessário no futuro, migre a camada web para um ILB ASE para tornar todo o tráfego de entrada (ingress) privado, mantendo as capacidades do App Service.

Estratégia de lançamento com canary e troca (swap)

Por quê: Roteie 5% do tráfego para o slot de preparo (staging) para validação em tempo real durante uma promoção. Monitore a latência, os orçamentos de erro e a conversão no checkout através do Application Insights. Se estiver saudável, realize uma troca com visualização (swap with preview); caso contrário, cancele e investigue, preservando a experiência do cliente.

Todos os domínios · Azure Functions e Computação sem servidor →

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