Microsoft AZ-104: Azure App Service e Computação PaaS — Guia de estudos

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Administrator Associate AZ-104 — 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 computação PaaS do Azure combina hospedagem de aplicativos/web totalmente gerenciada, funções sem servidor (serverless), automação de fluxos de trabalho, contêineres sob demanda e contêineres orquestrados. Como administrador, o sucesso depende do entendimento dos limites de cada serviço, como eles se conectam à rede e se autenticam, e como implantar e escalar de forma confiável. Esta seção aborda o App Service (planos, slots de implantação, rede e autenticação integrada), Azure Functions e Logic Apps (planos, gatilhos, conectores), Azure Container Instances e AKS (agendamento, escalonamento, ferramentas operacionais) e o App Service Environment isolado.

Fundamentos de Computação do App Service e Functions

Os App Service Plans determinam o pool de recursos de computação para Web Apps, API Apps e Function Apps que rodam no plano dedicado. Os Tiers (níveis) têm capacidades e modelos de escalonamento distintos:

Free (F1) e Shared (D1) rodam em infraestrutura compartilhada com cotas e sem SLA. São adequados apenas para experimentos. Recursos como slots de implantação, integração com VNet e autoescala não estão disponíveis.
Basic (B) aloca VMs dedicadas em pequena escala com escalonamento horizontal (scale-out) manual. Não possui autoescala nem slots de implantação.
Standard (S) introduz a autoescala (autoscale), múltiplas instâncias, backups diários e slots de implantação. É o ponto de partida para cargas de trabalho de produção que precisam de preparação (staging).
Premium (Pv2/Pv3) aumenta o desempenho de CPU/memória, I/O e os limites de recursos (mais instâncias, mais slots), e adiciona rede avançada, como integração com Private Endpoint e redundância de zona.
Isolated/Isolated v2 rodam dentro de um App Service Environment com computação dedicada e de locatário único (single-tenant) dentro da sua rede virtual para isolamento e conformidade rigorosos.

O escalonamento se divide em scale-up (mudar o nível de preço/tamanho da VM) e scale-out (mudar o número de instâncias). A autoescala (autoscale) requer o tier Standard ou superior e é orientada por regras do Azure Monitor (CPU, memória via Métricas do App Service ou métricas personalizadas). As operações de escalonamento são por App Service Plan e afetam todos os aplicativos dentro do plano.

Os slots de implantação (deployment slots) fornecem instâncias ativas do aplicativo no mesmo plano para preparar alterações. Os slots existem nos tiers Standard e superiores, com o Standard suportando menos e os Premium/Isolated suportando mais. A troca (swap) orquestra uma promoção sem tempo de inatividade (zero-downtime) ao trocar o conteúdo e a configuração dos slots, respeitando as configurações do slot (configurações de aplicativo e cadeias de conexão fixas - sticky - que permanecem com o slot). A troca com visualização (Swap with preview) aquece o slot de destino e avalia sua saúde antes de concluir. O teste em produção (Testing in production) direciona uma porcentagem do tráfego de produção para um ou mais slots; o roteamento é fixo (sticky) por cliente para manter a afinidade de sessão durante uma rampa de teste.

A rede do App Service oferece conectividade de entrada e saída controlada:

A Integração com VNet Regional (Regional VNet Integration) roteia o tráfego de saída para uma sub-rede delegada em uma rede virtual na mesma região. Ela permite a saída para pontos de extremidade privados, para o ambiente on-premises via VPN/ExpressRoute e para pontos de extremidade de serviço. Não altera o comportamento da entrada pública.
O Ponto de Extremidade Privado (Private Endpoint) publica o aplicativo de forma privada dentro da sua VNet, mapeando o frontend do aplicativo para um IP privado; combine com restrições de acesso para impor a entrada exclusivamente privada fora de um ASE.
As Conexões Híbridas (Hybrid Connections) fornecem conectividade TCP de saída do aplicativo para endpoints específicos de host:porta no ambiente on-premises ou em outras redes via Azure Relay, sem exigir alterações no firewall de entrada. Não é um túnel de VNet de propósito geral e não suporta UDP.
As Restrições de Acesso (Access Restrictions) avaliam regras de permissão/negação (allow/deny) ordenadas para IPs de clientes, tags de serviço e tráfego de rede virtual (via Private Endpoints ou regras de VNet multilocatário). Bloqueie para intervalos específicos, VNets ou front-ends para atender aos requisitos de conformidade.

A Autenticação/Autorização integrada (“Easy Auth”) atua como um front-end para seu aplicativo com um manipulador de autenticação hospedado, desonerando a validação de token sem alterações no código. Os provedores suportados incluem Microsoft Entra ID (Azure AD), Microsoft Account, Google, Facebook, Twitter e OpenID Connect genérico. Você pode forçar o login para todas as solicitações ou permitir que passem para o aplicativo, definir públicos permitidos e restringir a locatários (tenants) específicos. O repositório de tokens (token store) opcional armazena em cache os tokens do provedor e expõe as declarações (claims) através do endpoint /.auth/me e dos cabeçalhos da solicitação. Combine com a identidade gerenciada atribuída pelo sistema (system-assigned managed identity) para chamar serviços do Azure downstream de forma segura.

O Azure Functions oferece computação orientada a eventos em três modelos de hospedagem:

O plano Consumption (Consumo) é serverless com faturamento por execução e por GB-segundo, e com escalonamento horizontal (scale-out) e redução a zero (scale-to-zero) automáticos. Tem partidas a frio (cold starts) e, historicamente, não tinha integração com VNet para alguns gatilhos; capacidades mais recentes são mais amplas, mas cargas de trabalho sensíveis à rede devem verificar o suporte.
O plano Premium elimina a partida a frio com instâncias pré-aquecidas, suporta integração com VNet e Private Endpoints, e escala com base em eventos com controles de instâncias mínimas/máximas.
O plano Dedicated (Dedicado) (App Service Plan) executa as Functions na capacidade do seu App Service Plan; o custo é pelas instâncias reservadas, independentemente do uso, com autoescala opcional no nível do plano. Os gatilhos (triggers) do Functions incluem HTTP, Timer, Storage (Queue/Blob/Table), Service Bus, Event Hubs, Event Grid, Cosmos DB e mais, com associações de entrada/saída (input/output bindings) para conectar serviços declarativamente. O Durable Functions adiciona orquestração com estado (stateful) em um modelo code-first usando funções de orquestrador e de atividade, permitindo padrões como fan-out/fan-in, HTTP assíncrono, interação humana e sagas. O estado é persistido em um provedor de armazenamento (o Azure Storage é comum), garantindo fluxos de trabalho resilientes e que podem ser repetidos.

O custo e o comportamento de escalonamento diferem materialmente entre os modelos App Service Plan e Consumption. O App Service Plan cobra pelo tamanho e pela quantidade de instâncias sempre ativas e escala de acordo com as regras do plano. O modelo Consumption do Functions cobra apenas pelo tempo de execução e memória, com escalonamento automático baseado em concorrência e redução a zero. O plano Premium se situa entre esses dois, combinando capacidade reservada e aquecida com escalonamento de pico (burst).

Contêineres e Kubernetes

O Azure Container Instances (ACI) fornece contêineres sob demanda, cobrados por segundo, sem a necessidade de gerenciar VMs ou orquestradores. A unidade de implantação é um grupo de contêineres: um ou mais contêineres agendados no mesmo host, compartilhando um IP, portas, volumes e ciclo de vida. Defina CPU/memória por contêiner, exponha portas e monte volumes como Azure Files, secrets e emptyDir. As variáveis de ambiente podem ser de texto simples ou seguras (excluídas de logs e superfícies de metadados). As políticas de reinicialização controlam o ciclo de vida: Always (padrão para serviços de longa duração), OnFailure (para trabalhos que devem tentar novamente em caso de saída diferente de zero) e Never (para tarefas de execução única onde você deseja inspecionar o estado de saída sem reinicializações). A rede suporta IPs públicos, IPs privados com injeção de VNet em uma sub-rede delegada e rótulos de nome DNS para endpoints públicos.

O Azure Kubernetes Service (AKS) é um plano de controle do Kubernetes gerenciado com pools de nós provisionados como Virtual Machine Scale Sets. Os pools de nós diferenciam cargas de trabalho do sistema (componentes do kube-system) de cargas de trabalho do usuário, suportam múltiplos tamanhos de VM e podem executar Linux e Windows (o Windows requer pelo menos um pool de sistema Linux). Os pools podem receber “taints” para controlar o agendamento. As atualizações são orquestradas por pool, e maxPods, zonas de disponibilidade e discos de SO efêmeros são configurados na criação do pool. O cluster autoscaler se integra com o agendamento do Kubernetes para modificar a contagem de nós dentro dos limites mínimo/máximo quando pods pendentes não podem ser agendados ou os nós estão subutilizados; ele respeita os Pod Disruption Budgets e só reduz a escala quando é seguro. O Horizontal Pod Autoscaler complementa isso escalando as réplicas dentro de um Deployment com base em métricas.

Noções básicas de kubectl para administração de cluster:

Conecte-se com az aks get-credentials para mesclar o kubeconfig e selecionar o contexto.
Inspecionar recursos: kubectl get nodes/pods/deployments -o wide; kubectl describe para detalhes e eventos.
Diagnosticar e interagir: kubectl logs para stdout/stderr, kubectl exec -it para solução de problemas interativa.
Aplicar o estado desejado: kubectl apply -f manifests.yml; use namespaces para delimitar o escopo dos recursos; kubectl config set-context para alternar namespaces.

Plugins de rede (Azure CNI ou kubenet), identidade (identidade gerenciada vs. service principal) e a integração com RBAC/Entra ID determinam a alocação de IP dos pods, a autenticação e a autorização do cluster. Garanta que a identidade do cluster tenha permissões para load balancers, discos gerenciados e grupos de recursos dos nós.

Integração, Rede e Segurança

O Logic Apps fornece um mecanismo de fluxo de trabalho gerenciado com conectores para centenas de serviços SaaS e do Azure. Um fluxo de trabalho é composto por um gatilho que inicia a execução e ações que realizam as etapas. Os gatilhos incluem solicitações HTTP, Recorrência, mensagens do Service Bus, eventos do Event Grid, eventos do Storage e muitos eventos de SaaS (por exemplo, quando um registro é criado no Dynamics 365). As ações incluem construções de controle (condições, loops, switch), operações de dados (compor, analisar JSON, variáveis) e operações de conector (enviar e-mail, enfileirar mensagem, chamar API). A integração com os serviços do Azure é profunda:

O Service Bus e o Event Grid fornecem mensagens e eventos confiáveis para arquiteturas desacopladas.
O Functions pode ser invocado para etapas de código personalizado (HTTP síncrono ou assíncrono via filas).
A identidade gerenciada protege o acesso ao Key Vault, Storage, SQL e outros recursos do Azure sem o uso de segredos. O Logic Apps Consumption (multilocatário) cobra por execução de ação e uso de conector; o Logic Apps Standard (locatário único) roda no runtime do Functions em um App Service Plan ou plano Premium, suporta desenvolvimento local, integração com VNet, endpoints privados e maior throughput. O Integration Service Environment (ISE) no modo Consumption fornece isolamento de VNet para conectores gerenciados quando necessário.

O App Service Environment (ASE) implementa a camada (tier) Isolated para o App Service. Implantado em sua rede virtual, o ASE fornece unidades de computação e armazenamento dedicadas, de locatário único, com controle de rede. Um ASE externo expõe endpoints de entrada públicos; um ASE com balanceador de carga interno (ILB) publica apenas um VIP privado para acesso estritamente privado. Aplicativos em um ASE usam os níveis de preço (pricing tiers) Isolated/Isolated v2. Você paga tanto uma taxa pelo ambiente quanto os custos por instância de worker. O ASE é escolhido quando os requisitos de conformidade, isolamento de rede ou escala excedem as capacidades do App Service multilocatário. Com o ASE v3, a implantação e a rede são simplificadas, mas a proposta principal permanece: um App Service dedicado, endereçável de forma privada, com sua VNet como perímetro.

A governança de acesso nesses serviços depende do Azure RBAC para ações em recursos, de identidades gerenciadas para autenticação serviço a serviço e do Acesso Condicional (Conditional Access) no plano de identidade. Para controle de entrada no App Service, combine Private Endpoints ou ILB ASE com restrições de acesso e front-ends com WAF habilitado (por exemplo, Application Gateway ou Azure Front Door), conforme necessário. Para controle de saída, use a integração com VNet com NSGs, tabelas de rotas e endpoints privados para serviços de dados.

Operações de Implantação e Escalonamento

Lançamentos confiáveis para o App Service usam slots de implantação para validar a saúde e aquecer caches antes da troca (swap). Marque a configuração que difere por ambiente como “configurações de slot” para que ela não seja movida durante a troca (por exemplo, strings de conexão, feature flags). Use o swap com visualização para executar sondas de saúde ou endpoints de aquecimento específicos da aplicação; se não estiver saudável, aborte a troca. Durante o canary, habilite o roteamento de tráfego para direcionar uma pequena porcentagem com afinidade (sticky) para um slot de preparo (staging) e aumente-a incrementalmente. Configurações de aplicativo específicas do slot podem alternar recursos beta com segurança.

O autoescalonamento para App Service Plans é configurado no recurso do plano usando perfis (mín/máx/padrão baseados em tempo) e regras (limiares de métricas com passo de escalonamento e período de resfriamento). Combine CPU com métricas personalizadas (por exemplo, tamanho da fila) para um escalonamento mais preciso. Para o Functions, o plano Consumption escalona automaticamente; monitore a concorrência e configure o host.json para comportamentos por gatilho (por exemplo, tamanhos de lote e pré-busca para o Service Bus). O plano Premium escalona instâncias pré-aquecidas e instâncias de burst; alinhe a contagem mínima de instâncias com as metas de latência.

Em contêineres, as políticas de reinicialização do ACI devem refletir a intenção: trabalhos em lote (batch jobs) recebem Never ou OnFailure para evitar loops infinitos; serviços usam Always. Use variáveis de ambiente para configuração e o Azure Key Vault para segredos, injetando via Managed Identity e código de inicialização ou montando segredos como volumes quando apropriado. No AKS, habilite o cluster autoscaler com limites de mín/máx sensatos por pool de nós e configure HPAs para Deployments críticos. Reserve uma margem de capacidade (headroom) e defina Pod Disruption Budgets para proteger a disponibilidade durante atualizações e redução de escala (scale-in). Valide atualizações em um pool de nós canary antes de implantar atualizações de cluster ou pool de forma ampla.

Cenário de Problema Prático

A Fabrikam, Inc. executa um portal do cliente e serviços de processamento em segundo plano. Eles precisam modernizar para PaaS, impor acesso de rede privada aos armazenamentos de dados, suportar implantações blue-green e executar um ETL noturno em contêiner sem gerenciar VMs.

Hospedar o portal no App Service Premium com slots de implantação

Crie um App Service Plan no nível Premium v3 para maior desempenho e mais slots, e implante o Web App com um slot de preparo (staging).
Configure as configurações de slot para valores específicos do ambiente e habilite o swap com visualização e verificações de saúde (health checks).
Razão: O Premium oferece autoescalonamento, mais slots, suporte a Private Endpoint e SLA adequado para tráfego de produção. Os slots fornecem lançamentos blue-green seguros e roteamento canary.

Impor entrada privada e saída controlada

Habilite um Private Endpoint para o Web App e defina restrições de acesso para negar a rede pública.
Configure a Integração Regional com VNet (Regional VNet Integration) para uma sub-rede delegada para acesso de saída a armazenamentos de dados privados e on-premises via ExpressRoute.
Razão: O Private Endpoint mais as restrições garantem acesso exclusivamente privado; a Integração com VNet roteia o tráfego de saída através do perímetro da VNet para uma política de firewall consistente.

Implementar processamento em segundo plano com Azure Functions Premium

Implante um Function App em um plano Premium com uma identidade gerenciada atribuída pelo sistema, usando gatilhos do Service Bus e Storage para cargas de trabalho orientadas por fila.
Defina um número mínimo de instâncias pré-aquecidas para eliminar partidas a frio (cold starts) e integre com a mesma VNet.
Razão: O Functions Premium atende aos requisitos de baixa latência e VNet, preservando o escalonamento serverless para cargas de trabalho com picos (bursty).

Orquestrar fluxos de trabalho entre serviços com Logic Apps Standard

Construa fluxos de trabalho para coordenar o onboarding de clientes: acione por uma mensagem do Service Bus, chame o Function App, escreva no Storage e notifique via conector do Microsoft 365.
Use identidade gerenciada para acesso ao Key Vault e Storage e implante no mesmo App Service Plan para aproveitar a integração com VNet e os private endpoints.
Razão: O Logic Apps fornece orquestração visual e resiliente e conectores nativos; o Standard oferece integração com VNet e desempenho de locatário único.

Executar o ETL noturno no Azure Container Instances

Defina um grupo de contêineres com o contêiner de ETL, monte um compartilhamento do Azure Files para dados intermediários, defina variáveis de ambiente seguras e use restartPolicy: Never.
Anexe o grupo à sub-rede delegada da VNet para acesso privado aos bancos de dados.
Razão: O ACI oferece computação por segundo, orientada a tarefas (jobs), sem a sobrecarga de um cluster, e se integra com a VNet para localidade e segurança dos dados.

Preparar para microsserviços em contêineres com AKS

Crie um cluster AKS com um pequeno pool de nós de sistema Linux e um pool de nós de usuário dimensionado para a carga esperada, habilite o cluster autoscaler (limites mín/máx) e integre com o Entra ID e o Azure CNI para IPs no nível do pod.
Use kubectl para implantar um microsserviço canary e defina um HPA com base em CPU e métricas personalizadas.
Razão: O AKS fornece orquestração de nível empresarial quando os serviços se multiplicam; o autoscaler e o HPA alinham a capacidade com a demanda e o kubectl oferece controle operacional padrão.

← Armazenamento do Azure · Todos os domínios · Bancos de Dados do Azure e Serviços de Dados →

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