Selecione máquinas virtuais, lote, Web, contêineres, Kubernetes, eventos e fluxos de trabalho com base nos requisitos da carga.
Tempo de estudo sugerido: 92 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. Comece pela carga, não pelo produto
A Tailwind Traders, varejista global fictícia, precisa migrar projetos e otimizar novas aplicações com orçamento limitado. O arquiteto deve escolher computação rápida, escalável e flexível, pagando apenas pela capacidade justificável.
Escolher um serviço de computação do .
Recomendar soluções com máquinas virtuais, lote, Web, contêineres, Kubernetes, código sem servidor e fluxos.
Especificar componentes conforme requisitos da carga.
Aplicar os conceitos ao domínio de infraestrutura e computação da AZ-305.
O módulo pressupõe conhecimento conceitual de computação do e experiência com máquinas virtuais, contêineres e hospedagem gerenciada.
Resumo do tópico
Registre carga, migração, controle, escala, latência, operação e custo antes de selecionar o serviço.
2. A árvore de decisão gera um candidato, não a arquitetura final
A decisão separa migração de desenvolvimento novo e testa otimização para nuvem, lift-and-shift, controle do sistema operacional, HPC, eventos, Web gerenciada, contêineres, orquestração e integração. Depois, valide limites, região, rede, segurança, confiabilidade e custo.
A árvore é uma hipótese inicial que precisa ser comprovada pelos requisitos não funcionais.
Resumo do tópico
A escolha só é defensável quando o ramo inicial também atende aos atributos de qualidade.
3. Entenda a responsabilidade principal de cada opção
Mapa de serviços.
Serviço
Responsabilidade
Uso típico
com controle do SO convidado.
Rehosting, software empacotado e dependências específicas.
do
Agendamento gerenciado sobre pools de nós.
Trabalhos paralelos, renderização, simulação e HPC.
Plataforma gerenciada.
Aplicativos Web, back-ends móveis, e .
Contêiner ou grupo sem .
Tarefas curtas, automação, build e serviços simples.
Contêineres gerenciados com revisões e escala sem servidor.
Microsserviços, eventos, jobs, Dapr e escala a zero.
Kubernetes gerenciado com acesso à .
Portfólios que exigem primitivas e controle do Kubernetes.
Funções orientadas a eventos.
Código acionado por , filas, temporizadores e eventos.
do
Fluxos de integração visuais.
Conectores, B2B, agendas, aprovações e orquestração.
Resumo do tópico
Associe o serviço à responsabilidade dominante: máquina, trabalho, , contêiner, , evento ou integração.
4. Modelos de hospedagem trocam controle por abstração
Espectro de responsabilidades.
Modelo
Cliente gerencia
Provedor gerencia
Exemplo
Local
Do ao aplicativo.
Nada da pilha local.
privado.
SO, , aplicativo, dados e configuração.
Infraestrutura física e virtualização.
.
Aplicativo, dados, identidades e configuração.
SO, plataforma, patches e grande parte da escala.
.
FaaS/sem servidor
Função ou fluxo e dependências.
Provisionamento e escala por eventos.
e .
Usuários, dados e configuração.
Aplicativo entregue e pilha.
.
Resumo do tópico
Use a abstração mais alta que ainda exponha o controle, a portabilidade e o isolamento necessários.
5. Migração e estilo arquitetural reduzem as alternativas
Lift-and-shift favorece ou contêiner compatível sem redesenho; otimização para nuvem refatora para recursos gerenciados. Avalie COTS, controle de software e SO, cargas interativas, eventos, HPC, microsserviços, operação, suporte, habilidades e manutenção.
Resumo do tópico
Tolerância à mudança, arquitetura e capacidade operacional eliminam opções antes mesmo da comparação de desempenho.
6. oferecem o maior controle do convidado
sustentam desenvolvimento, testes, aplicações, extensão de , novas cargas com requisitos específicos e rehosting. Em troca, a equipe assume configuração e patches do SO, proteção, software, backup, monitoramento, escala e disponibilidade; uma VM isolada não é alta disponibilidade.
Resumo do tópico
Escolha quando controle do SO ou compatibilidade de rehosting justificar a carga operacional.
7. Rede, nome e região precedem a imagem da VM
Planeje endereços, sub-redes, rotas, ,, conectividade privada e híbrida antes das VMs. Use nomes consistentes. A região altera latência, residência, legislação, preço, cota, séries, zonas e capacidade; cota aprovada não garante capacidade física.
A recomendação inclui todos os recursos de suporte e o ciclo de vida.
Resumo do tópico
Rede, nomenclatura, região, cota e capacidade são entradas de arquitetura.
8. Dimensione a família pela característica da carga
Famílias de tamanho.
Classe
Ênfase
Exemplos
Uso geral
CPU e memória equilibradas.
Dev/teste, bancos pequenos e servidores Web.
Otimizada para computação
Mais CPU por memória.
Aplicações, appliances e lote.
Otimizada para memória
Mais memória por CPU.
Bancos relacionais, e análise em memória.
Otimizada para armazenamento
Alto throughput e IOPS.
Bancos e data warehouses.
GPU
Aceleração gráfica.
Renderização, vídeo, treino e inferência.
HPC
CPU e interconexão rápidas.
Ciência, engenharia e HPC acoplado.
Meça vCPU, RAM, IOPS, throughput de disco e rede, aceleradores e disponibilidade; séries variam por região.
Resumo do tópico
Escolha a família por medições, faça benchmark e confirme disponibilidade regional.
9. O custo da VM inclui computação, discos, licenças e apoio
Preço de computação varia por tamanho, SO, região e compra. Desligar dentro do SO não basta: desaloque para liberar computação faturável. Discos gerenciados, snapshots, , backup, , licenças e saída de dados são cobrados separadamente e podem continuar.
Selecione tipo, tamanho, desempenho, redundância e criptografia dos discos. Use imagem Windows ou Linux de 64 bits compatível, do Marketplace ou governada internamente, e avalie Benefício Híbrido do .
Resumo do tópico
Calcule a solução completa e separe faturamento de computação do faturamento de armazenamento.
10. Produção exige disponibilidade, escala, segurança e operação
Use zonas, múltiplas instâncias e balanceamento conforme o .
Use para uma frota horizontal.
Aplique ,, menor privilégio, inicialização segura, vTPM e .
Automatize imagens, configuração e patches; monitore e teste backup e recuperação.
Separe disco do SO e dados quando melhorar recuperação, segurança ou desempenho.
Resumo do tópico
Uma solução de VM em produção é uma frota automatizada, protegida, observável e recuperável.
11. O do agenda trabalho paralelo e HPC
O do cria pools de nós Windows ou Linux, instala aplicações, prepara dados, agenda trabalhos e tarefas, detecta falhas, reenfileira e dimensiona. Atende paralelismo independente e HPC acoplado, como Monte Carlo, renderização e imagens, normalmente atrás de um serviço cliente.
Resumo do tópico
Use quando o problema central for agendar e escalar tarefas, não servir uma aplicação interativa.
12. Pools, nós, trabalhos e tarefas formam o modelo de execução
O fluxo carrega dados e aplicação no do , cria ou reutiliza um pool, executa trabalhos divididos em tarefas, monitora e grava saídas duráveis. O pool pode combinar nós dedicados ou Spot e usar fórmula de dimensionamento automático.
Separe a aplicação de negócio da plataforma de computação em lote.
Resumo do tópico
Modele entrada, pool, nós, trabalhos nomeados, tarefas, tentativas, monitoramento e saída.
13. Eficiência do depende da estratégia
Reutilize ou selecione pools dinamicamente para tarefas curtas.
Evite um pool universal que acople trabalhos diferentes.
Considere nós descartáveis; use múltiplos nós, idempotência, checkpoint e nova tentativa.
Use tamanhos isolados quando a conformidade exigir.
Nomeie trabalhos e agrupe tarefas de forma eficiente; evite muitos trabalhos minúsculos.
Compare nós dedicados e Spot, escala, localidade dos dados, inicialização e tarefas em contêiner.
Resumo do tópico
Ganhos paralelos dependem de tarefas tolerantes a falhas, pools adequados e baixo custo de inicialização e dados.
14. O hospeda aplicações gerenciadas
O hospeda Web, back-ends móveis, e tarefas em segundo plano no Windows ou Linux, com .NET, Java, Node.js, Python, PHP ou contêiner personalizado. Oferece , balanceamento, escala, implantação e recursos de disponibilidade sem gestão do SO.
Resumo do tópico
Use o quando a carga for e a abstração da plataforma for vantajosa.
15. O plano do é o limite de custo e computação
O plano define região, SO, tamanho, instâncias e camada. Aplicativos, ,, backups e diagnósticos compartilham CPU e memória; escalar o plano afeta todos. Free/Shared servem a desenvolvimento, camadas dedicadas adicionam recursos e Isolated adiciona isolamento de rede. Separe cargas com escala, risco ou ciclo de vida incompatíveis.
Resumo do tópico
Trate o plano como limite compartilhado e isole cargas com perfis diferentes.
16. permitem releases validados com pouco downtime
Integre GitHub, ou Git. Em camadas elegíveis, implante no slot de teste, valide, aqueça e troque com produção. Marque configurações específicas como sticky, separe identidades e segredos e planeje .
reduzem risco quando configuração, identidade, dados e reversão são planejados.
Resumo do tópico
Governe como ambientes de release, não como simples cópias do aplicativo.
17. Web, , e identidade cobrem cenários distintos
Web: Windows, Linux, runtime ou contêiner.
: /, linguagem livre e /.
: programas e scripts contínuos, agendados ou acionados.
:, Google, Facebook e X com pouco ou nenhum código.
Custo: distribua aplicações entre planos segundo escala, rede, recursos e isolamento.
Resumo do tópico
A plataforma simplifica recursos Web, mas plano, identidade, rede e isolamento continuam sendo decisões.
18. Instâncias de Contêiner executam contêineres sem
oferecem inicialização rápida, cobrança por segundo, CPU e memória explícitas, Linux e Windows e montagem de . Servem a tarefas simples, automação, builds e workers; não substituem uma plataforma completa de orquestração.
Resumo do tópico
Use ACI para execução simples e isolada quando um não agrega valor.
19. O grupo é o limite de agendamento e compartilhamento
Contêineres de um grupo ficam no mesmo host e compartilham ciclo de vida, rede local, recursos e volumes. Isso viabiliza de conteúdo, , monitoramento ou front-end/back-end fortemente acoplados.
Agrupe apenas componentes que precisam ser co-localizados.
Resumo do tópico
Serviços com escala independente precisam de limites diferentes do grupo ACI.
20. Segurança começa por imagem confiável e observabilidade
Use ou registro privado controlado.
Digitalize, assine e bloqueie imagens vulneráveis; reduza o conjunto de produção.
Use identidades gerenciadas e menor privilégio.
Restrinja rede e monitore arquivos, tráfego, consumo, e saúde.
Inclua volumes, segredos, reinício e proveniência no modelo de ameaça.
Resumo do tópico
Velocidade de inicialização não substitui governança de imagem, identidade, rede, dados e runtime.
21. O oferece Kubernetes gerenciado com acesso direto à
Kubernetes automatiza implantação, escala, atualização e recuperação. O gerencia o plano de controle, preservando e primitivas. A equipe ainda projeta pools, upgrades, identidade, políticas, rede, entrada, armazenamento, observabilidade e confiabilidade.
Kubernetes gerenciado ainda precisa de modelo operacional.
Resumo do tópico
Use quando controle e extensibilidade do Kubernetes justificarem habilidades e operação de .
22. Camadas e infraestrutura como código definem suporte
oferece Free, Standard e Premium: Free sem do plano de controle para dev/teste; Standard com para produção; Premium com suporte de longo prazo. Nós são cobrados em todas. Versione /, rede, , políticas, monitoramento, pools, upgrades e complementos.
Resumo do tópico
Escolha a camada pelo e suporte e torne o integralmente reproduzível.
23. Operar envolve identidade, escala, upgrades, armazenamento e rede
Decisões de .
Área
Decisão
Identidade
,,, política e acesso ao registro.
Monitoramento
,, métricas, alertas e telemetria.
Escala
HPA para pods e autoscaler de para nós.
Upgrades
Cordão, drenagem, janelas e orçamentos de interrupção.
Volumes persistentes estáticos ou dinâmicos e recuperação.
Rede e entrada
Modelo de rede, privado, saída, balanceamento e /ingress.
Imagens
Registro público ou privado governado.
Resumo do tópico
A recomendação de deve atribuir responsabilidade por todo o ciclo de vida da plataforma.
24. Compare ACI, Aplicativos de Contêiner e pela orquestração
Ponto de partida.
Necessidade
Escolha
Uma tarefa ou grupo simples
.
Microsserviços sem servidor, revisões, jobs, Dapr e escala a zero
.
Kubernetes, operadores, malha e agendamento detalhado
.
Menor esforço operacional
ACI ou Aplicativos de Contêiner.
Múltiplas cargas e controles Kubernetes
, com limites e governança explícitos.
Resumo do tópico
Use a plataforma mais simples que satisfaça orquestração, segurança, rede e controle de .
25. executa código orientado a eventos
reage a , filas, temporizadores, armazenamento e outros eventos. Gatilhos e vínculos reduzem integração; planos sem servidor escalam com eventos. Uma função pode processar uma , gravar no e emitir uma notificação.
Projete concorrência, idempotência, saída, repetição e mensagens problemáticas.
Resumo do tópico
Use Functions para código discreto orientado a eventos com limites claros de execução e falha.
26. Plano, duração e Durable Functions moldam a execução
Consumption e Flex Consumption são sem servidor; Premium, Dedicated e outras opções variam em aquecimento, rede, escala e custo. é dependente do plano e configurável, portanto números fixos antigos não devem orientar o design. Divida operações longas; Durable Functions mantém estado, checkpoints e reinícios em padrões como encadeamento e fan-out/fan-in.
Resumo do tópico
Escolha o plano por escala, cold start, duração, rede e custo; use Durable Functions quando o estado atravessar execuções.
27. Limites do aplicativo de funções controlam escala e impacto
Separe funções com memória, throughput, implantação, segurança ou escala diferentes.
Trate falhas, duplicidade, , repetição e dead-letter.
Use ,, correlação, , métricas, rastreamentos e alertas.
Para alto volume, avalie conta de armazenamento exclusiva por aplicativo.
Use e segredos externos.
Resumo do tópico
O aplicativo de funções é limite de implantação, configuração, escala, armazenamento, identidade e falha.
28. orquestram fluxos de integração
do , parte dos Serviços de Integração do , conectam nuvem, local, híbrido, legado e B2B por gatilhos, ações, controles e conectores. Exemplos: notificar pelo , rotear pedidos, mover SFTP/FTP para do e transformar sinais em alertas.
O valor aparece quando vários sistemas precisam ser coordenados.
Resumo do tópico
Use quando conectores e visibilidade de orquestração superarem a necessidade de codificar cada etapa.
29. Functions é code-first; é design-first
Comparação.
Dimensão
Desenvolvimento
Código e extensão Durable Functions.
Designer ou arquivos de fluxo.
Conectividade
Gatilhos, vínculos e código customizado.
Conectores, conectores customizados e Enterprise Integration Pack.
Uso
Algoritmos e manipuladores de eventos.
Sistemas, aprovações, agendas e B2B.
Monitoramento
e .
Histórico de execução e do .
Composição
Pode chamar um aplicativo lógico.
Pode chamar uma função.
Os serviços são complementares.
Resumo do tópico
Coloque computação customizada em Functions e orquestração entre sistemas em .
30. O design do fluxo inclui conectores, desempenho, controle e hospedagem
Integração: uma aplicação isolada pode não precisar de fluxo.
Desempenho: há escala e paralelismo, mas não latência determinística em tempo real.
Controle: condições, Booleanos, switches, loops, escopos, repetição e compensação.
Conectores: valide conectores prontos; para /, crie conector customizado ou primeiro a .
Limites: regras complexas ou código de baixa latência podem pertencer a Functions.
Hospedagem: Consumption é multilocatário, por execução e um fluxo por recurso; Standard é locatário único, múltiplos fluxos, capacidade dedicada e rede avançada.
Resumo do tópico
Valide conectores, latência, controle, erros, observabilidade, rede e modelo de hospedagem.
31. Aplique os requisitos à avaliação do módulo
Avaliação Tailwind Traders.
Requisito
Resposta
Motivo
Atualizar estoque e notificar imediatamente a partir de serviço C#.
Refatoração para ações orientadas a eventos.
Migrar servidores relacionais em VMs.
VM otimizada para memória
Bancos relacionais tendem a exigir mais memória por CPU.
Processar fotos por poucos segundos e gravar em Blobs.
Inicialização rápida e cobrança por segundo.
Resumo do tópico
As respostas são Functions, VM otimizada para memória e ACI devido a gatilho, perfil de recurso e duração.
32. Consolide a decisão e consulte orientações atuais
Documente alternativas rejeitadas e evidências.
Uma resposta forte da AZ-305 identifica o formato da carga, escolhe um candidato e o comprova contra escala, disponibilidade, segurança, rede, implantação, observabilidade, recuperação, custo, região e habilidades.
