O domínio de design de computação no exame AZ-305 Solutions Architect Expert é repleto de questões que não podem ser respondidas apenas memorizando serviços. A resposta correta muda conforme a combinação de requisitos: "migrar sem alterar código", "eliminar a sobrecarga de gerenciar Kubernetes" ou "processar eventos sem servidores". Este guia destila padrões de 49 questões reais do AZ-305 para mapear os critérios de seleção de cada serviço e expor as armadilhas de resposta mais comuns.
---
VM e Virtual Machine Scale Sets (VMSS)
O sinal decisivo para escolher uma VM é a dependência legacy. Quando aparecem componentes em nível de runtime do SO Windows — componentes COM, COM+ ou ActiveX — a migração para PaaS não é possível. Quando requisitos de alta disponibilidade aparecem junto a isso, a escolha é entre Availability Sets e Availability Zones.
Availability Sets: Distribui VMs entre domínios de falha (até 3) e domínios de atualização (até 20) dentro do mesmo datacenter. SLA de 99,95%, sem custo adicional. Availability Zones: Implanta VMs em datacenters fisicamente separados dentro de uma região. SLA de 99,99%, protege contra a falha completa de um datacenter.
A seleção da série de VM também aparece no exame. Para ambientes de desenvolvimento e testes com picos irregulares, Bsv2 (burstable) — o modelo de acumulação de crédito de CPU mantém os custos significativamente mais baixos. Para cargas de trabalho que precisam de alta proporção de memória, como SQL Server, Ev5 (otimizado para memória) — inclui rede acelerada SR-IOV por padrão e também reduz os custos de licenciamento do SQL Server. Quando é necessário isolamento de hardware de nível de conformidade, combine Azure Dedicated Host com VMSS e Availability Zones.
O VMSS escala automaticamente VMs idênticas para cima e para baixo com base em métricas como utilização de CPU, suportando até 1.000 instâncias no plano padrão.
---
App Service e cargas de trabalho web
Existem três sinais de seleção para o App Service: migrar sem alterações de código, delegar o gerenciamento do SO ao Azure e necessidade de escalonamento automático. Quando as três palavras-chave aparecem juntas, a resposta é quase sempre App Service. Ele suporta nativamente runtimes de Java, Python, .NET e Node.js e fornece armazenamento temporário local ( no Windows, no Linux), então até aplicações locais que usam arquivos temporários podem ser migradas sem modificações de código.
Para implantações multirregião, lembre-se de que um App Service Plan está vinculado a uma região específica do Azure. Para implantar de forma independente na Europa, América do Norte e APAC, são necessários Plans separados por região. Para ambientes regulados que precisam de isolamento completo com uma sub-rede de VNet dedicada, considere App Service Environment (ASE v3) — mas observe que mesmo um ambiente vazio incorre em uma taxa base de mais de USD 1.000 por mês.
O swap de Deployment Slots é sobre a troca instantânea sem downtime. Após validar um slot de staging em um ambiente idêntico ao de produção, o swap traz instâncias pré-aquecidas para receber tráfego em segundos. Esse recurso está disponível apenas no nível Standard e acima. Para implantações canary progressivas, ajuste o percentual de tráfego do slot ou use o Traffic Manager.
---
Serverless: Functions e Logic Apps
Escolher um plano de hospedagem do Azure Functions é um tema recorrente no AZ-305.
Plano Consumption: Cobrança por quantidade de execuções vezes duração, com 1 milhão de execuções gratuitas por mês. Sem custo durante períodos de inatividade. No entanto, o tempo máximo de execução é de 10 minutos, ocorrem cold starts e a integração com VNet não é suportada. Plano Premium: Instâncias pré-aquecidas eliminam cold starts. O tempo de execução pode ser configurado como ilimitado. Suporta integração com VNet. Quando você vê os três — sem cold starts, execuções acima de 10 minutos, integração com VNet — a resposta é Premium. Plano Dedicated: Executa sobre um App Service Plan. Existe sobrecarga de gerenciamento de servidores, mas os recursos do Plan existente podem ser compartilhados.
Os níveis de autorização do trigger HTTP também são avaliados. permite que qualquer pessoa chame sem uma chave, tornando-o adequado para APIs de dados públicos. requer uma chave de função e requer a chave mestra. O array restringe quais métodos HTTP são permitidos; métodos não listados recebem automaticamente uma resposta 405.
---
Cargas de trabalho de contêiner: Container Apps e AKS
Container Apps vs AKS
O critério-chave é o nível de controle do Kubernetes necessário. Se o requisito é "executar contêineres sem gerenciar Kubernetes e minimizar a sobrecarga operacional", escolha Azure Container Apps. Se é necessário controle direto do Kubernetes, escolha AKS.
O Container Apps fornece escalonamento automático baseado em KEDA e integração com Dapr nativamente, com pools de nós, kubectl e atualizações de cluster completamente abstraídos. O AKS é usado para cenários avançados que requerem uma malha de serviços Istio, políticas de rede ou runtimes personalizados.
Vários tópicos avançados de AKS aparecem frequentemente no exame.
KEDA: Uma ferramenta de escalonamento automático nativa do Kubernetes que suporta mais de 50 escaladores, incluindo Azure Queue Storage, Event Hubs e Service Bus. A capacidade-chave é o scale to zero — quando não há mensagens em uma fila, os pods escalam para zero. O HPA sozinho requer pelo menos um pod, mas o KEDA permite zero. Virtual Node + ACI: Usado quando o AKS precisa expandir instantaneamente sem provisionar VMs. Conectar o ACI como um nó virtual inicia contêineres em dezenas de segundos. Suporta apenas contêineres Linux. Malha de serviços Istio: A escolha certa quando você precisa de implantação canary (ponderação de tráfego), roteamento baseado em cabeçalho e criptografia mTLS entre serviços, tudo ao mesmo tempo. Dapr: A State Management API fornece uma interface unificada para Redis, Cosmos DB e Azure Table Storage. A Pub/Sub API abstrai brokers de mensagens. Trocar um arquivo de configuração YAML permite mudar o armazenamento ou broker sem tocar no código. ACR Geo-replication: Suportado apenas no ACR de nível Premium. Automatiza a replicação de imagens para clusters AKS multirregião e garante que cada região extraia imagens de sua réplica mais próxima.
!Container Apps vs AKS
Tabela comparativa de serviços
| Serviço | Modelo de custo | Escalonamento | Complexidade operacional | Sinal de seleção principal | |---------|----------------|--------------|--------------------------|----------------------------| | VM | Horas de instância | Manual ou VMSS | Alta | Legacy COM/ActiveX, isolamento de hardware | | VMSS | Horas de instância | Automático (métricas) | Média | Escalonamento automático de VMs idênticas | | App Service | Horas de plano | Automático (quantidade de instâncias) | Baixa | Lift-and-shift de aplicações web sem alterações de código | | Container Apps | Tempo de execução + requisições | KEDA automático (incl. 0) | Baixa | Executar contêineres sem gestão de K8s | | AKS | Horas de VM de nó | HPA/KEDA/Cluster Autoscaler | Alta | Controle direto de K8s, malha de serviços | | Functions (Consumption) | Execuções x duração | Automático (serverless) | Muito baixa | Eventos irregulares, execuções curtas | | Functions (Premium) | Instâncias mínimas + uso | Automático (pré-aquecido) | Baixa | Sem cold starts, integração com VNet |
---
Critérios de seleção que confundem no exame
Processamento paralelo em grande escala
Para cargas de trabalho que processam milhares de tarefas independentes em paralelo — renderização 3D, análise genômica, simulação financeira — Azure Batch é a resposta. Ele tem filas de tarefas, agendamento e escalonamento automático de pools de VM integrados, e volta a zero quando o trabalho termina. Se você precisa integrar com agendadores de jobs HPC de terceiros (PBS Pro, Slurm, LSF), escolha Azure CycleCloud. Para tipos de nó do Batch, use Spot VMs para cargas de trabalho de desenvolvimento tolerantes a interrupção (até 90% de economia) e Dedicated VMs para produção de longa duração.
Ferramentas de migração
Azure Migrate: Uma plataforma integrada para descobrir, avaliar e migrar cargas de trabalho locais para o Azure. Um dispositivo VMware coleta dados de desempenho de VM sem agentes e calcula o SKU adequado e o custo estimado. Azure Resource Mover: Usado para mover recursos existentes entre assinaturas ou regiões dentro do Azure. Não confunda com migração de ambientes locais. Azure DMS (modo online): Sincroniza continuamente SQL Server com Azure SQL Managed Instance via CDC, limitando o downtime do corte a minutos. Combinação DMA + DMS: Avalie previamente a compatibilidade do esquema SQL com DMA, depois realize a migração real dos dados com DMS. Azure Data Factory: Usado para migrações entre fontes de dados heterogêneas, como SQL Server para Cosmos DB (NoSQL). O DMS é apenas para migrações de relacional para relacional.
Microsserviços híbridos
Quando o requisito é uma plataforma de microsserviços operando simultaneamente em ambientes locais e no Azure com latência ultra-baixa, Azure Service Fabric é a resposta. Você pode implantar o mesmo cluster em datacenters locais e na nuvem Azure, processando milhões de instâncias com latência em milissegundos.
---
Dicas práticas de aplicação
Classificar por padrão de carga de trabalho é a abordagem mais rápida. Necessidade de acesso em nível de SO → VM. Aplicação web PaaS → App Service. Contêineres mas quer evitar a gestão de K8s → Container Apps. Controle completo de K8s → AKS. Eventos curtos e irregulares → Functions.
Lembre-se também dos padrões de otimização de custo. CPU médio baixo com picos irregulares → Bsv2 burstable. Batch tolerante a interrupção → Spot VM (até 90% de economia). HPC irregular → Azure Batch. Custo zero quando não há eventos → Functions Consumption.
A alta disponibilidade não pode ser