Microsoft AZ-900: Conceitos de Nuvem — Guia de estudos

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure AZ-900 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

A computação em nuvem entrega recursos de TI medidos pela internet com provisionamento rápido, alcance global e resiliência integrada. A migração da infraestrutura on-premises para o Azure muda tanto as escolhas de tecnologia quanto os modelos operacionais: o planejamento de capacidade dá lugar ao escalonamento elástico, as despesas de capital se transformam em despesas operacionais, e a manutenção de hardware se torna uma responsabilidade da plataforma. Entender esses conceitos é essencial para selecionar os serviços corretos, arquitetar para a disponibilidade e controlar os custos.

Características principais da nuvem: escalabilidade, elasticidade, agilidade e resiliência

Escalabilidade é a capacidade de uma carga de trabalho (workload) de lidar com o aumento da demanda adicionando recursos. No Azure, isso assume duas formas: escalonamento vertical (scale up), escolhendo tamanhos de VM maiores ou planos do App Service superiores, e escalonamento horizontal (scale out), adicionando mais instâncias por meio de Virtual Machine Scale Sets (VMSS), pools de nós do Azure Kubernetes Service (AKS) ou o autoescalonamento do App Service. O escalonamento na direção oposta reduz a capacidade e o custo quando a demanda diminui. Projetar camadas sem estado (stateless) e externalizar o estado (por exemplo, para o Azure Cache for Redis ou o Azure SQL Database) torna o escalonamento horizontal previsível e rápido. Elasticidade é o escalonamento automatizado e orientado por políticas que alinha continuamente a capacidade à carga. Regras de autoescalonamento do Azure Monitor, o autoscaler de cluster do AKS e opções serverless como o Azure Functions ou os planos Consumo/Elastic Premium expandem e contraem recursos quase em tempo real. Arquiteturas elásticas minimizam a capacidade ociosa e são adequadas para cargas de trabalho com picos ou sazonais, alinhando os gastos precisamente com o uso. Agilidade é a velocidade com que as equipes entregam mudanças. A implantação de recursos do Azure por meio de templates Bicep ou ARM, pipelines do GitHub Actions ou do Azure DevOps, e abstrações de recursos como o App Service ou o AKS permitem liberações frequentes e de baixo risco. O provisionamento de autoatendimento (self-service) por meio de RBAC e barreiras de proteção de políticas (policy guardrails) reduz os tempos de espera, mantendo a governança. A agilidade é um produto tanto da plataforma quanto das práticas organizacionais; quanto mais a plataforma abstrai o trabalho pesado indiferenciado, mais rápido as equipes podem se mover. Tolerância a falhas e recuperação de desastres abordam diferentes escopos de falha. A tolerância a falhas mitiga falhas de componentes e de datacenters dentro de uma região usando Conjuntos de Disponibilidade (Availability Sets) (distribuindo VMs entre domínios de falha/atualização), Zonas de Disponibilidade (Availability Zones) (datacenters fisicamente separados dentro de uma região), balanceadores de carga e caminhos de dados redundantes. A recuperação de desastres prepara para interrupções em nível de região com replicação entre regiões (armazenamento GRS/RA-GRS, georreplicação ativa do Azure SQL, gravações multirregionais do Cosmos DB) e ferramentas de recuperação como o Azure Site Recovery. Defina metas claras de RTO/RPO e teste o failover para garantir que o design atenda aos objetivos de continuidade de negócios.

Modelos de serviço e responsabilidade compartilhada

Os modelos de serviço em nuvem determinam o que você gerencia versus o que o Azure gerencia. A Infraestrutura como Serviço (IaaS) expõe os blocos de construção brutos de computação, armazenamento e rede. Você controla o SO convidado, o runtime e os aplicativos — ideal quando você precisa de imagens personalizadas, middleware especializado ou controle total. A Plataforma como Serviço (PaaS) abstrai o SO e grande parte do middleware, fornecendo runtimes gerenciados, bancos de dados e serviços de integração para que as equipes possam focar no código e nos dados. O Software como Serviço (SaaS) entrega aplicativos completos consumidos via navegador ou API com configuração mínima e sem obrigações de hospedagem do aplicativo. O modelo de responsabilidade compartilhada esclarece os limites operacionais. Em IaaS, o Azure gerencia o datacenter físico, os hosts e o hypervisor; você lida com a aplicação de patches no SO, hardening, atualizações de aplicativos, identidade e acesso, e governança de dados. Em PaaS, o Azure também gerencia o SO e o middleware da plataforma; você gerencia o código do aplicativo, a configuração e os dados. Em SaaS, o Azure (ou o provedor de SaaS) opera a pilha (stack) inteira; você gerencia usuários, acesso, classificação de dados e configuração de uso. Em todos os modelos, os clientes mantêm a responsabilidade por identidade, permissões, segurança de endpoint e políticas de proteção de dados. Selecionar o modelo correto afeta as metas de disponibilidade e o custo. Implantar máquinas virtuais do Azure é uma tarefa de IaaS; APIs web no Azure App Service ou contêineres no AKS refletem PaaS; Microsoft 365 e Dynamics 365 são SaaS. Prefira PaaS e SaaS sempre que possível para acelerar a entrega e reduzir a carga operacional, reservando IaaS para cargas de trabalho que exigem controle no nível do SO ou dependências legadas.

• IaaS
  • Serviços típicos do Azure: Azure Virtual Machines, VM Scale Sets, Azure Disks, Virtual Network
  • O que você gerencia: SO convidado, patches, runtime, aplicativos, dados, backups, AV/EDR
  • Quando escolher: Controle total do SO, middleware personalizado, lift-and-shift
• PaaS
  • Serviços típicos do Azure: Azure App Service, Azure SQL Database/Managed Instance, AKS, Azure Functions, Azure Integration Services
  • O que você gerencia: Código/configuração, esquema, dados, identidade e acesso
  • Quando escolher: Entrega mais rápida, escalonamento/alta disponibilidade (HA) integrados, operações reduzidas
• SaaS
  • Serviços típicos do Azure: Microsoft 365, Dynamics 365, Power BI, Azure DevOps Services
  • O que você gerencia: Usuários, funções, uso/configuração de dados
  • Quando escolher: Aplicativos completos com gerenciamento mínimo

Modelos de implantação e escopo de escala

A nuvem pública implanta cargas de trabalho em datacenters de propriedade da Microsoft, compartilhados entre vários locatários com isolamento lógico. Ela oferece o catálogo mais amplo, alcance global, provisionamento rápido e um modelo puramente pay-as-you-go (pagamento conforme o uso). A nuvem privada dedica infraestrutura a uma única organização, muitas vezes por razões regulatórias ou de soberania de dados, e pode ser executada em pilhas validadas pelo Azure, como o Azure Stack Hub ou o Azure Stack HCI. A nuvem híbrida conecta o ambiente on-premises e o Azure com identidade, política e rede consistentes, permitindo migrações em fases e localidade de dados, ao mesmo tempo em que aproveita a elasticidade da nuvem onde faz sentido. O escalonamento global versus local diz respeito ao escopo da disponibilidade e das melhorias de desempenho. O escalonamento local mantém o tráfego dentro de uma região, usando Zonas de Disponibilidade, VM Scale Sets, Application Gateway e Azure Load Balancer para adicionar instâncias e isolar falhas de datacenter. O escalonamento global distribui o tráfego entre regiões usando o Azure Front Door (balanceamento de carga global moderno, anycast, camada 7 com WAF), o Azure Traffic Manager (balanceamento de carga baseado em DNS) e serviços de dados com replicação geográfica, como a replicação geográfica do Azure SQL ou a distribuição multirregional do Cosmos DB. Arquiteturas multirregionais ativo/ativo melhoram a latência e a resiliência, mas exigem um planejamento cuidadoso da consistência de dados e dos custos. A escolha de um modelo de implantação geralmente começa com restrições de conformidade e conectividade e evolui com o ciclo de vida da aplicação. Novas aplicações web greenfield frequentemente são implementadas em PaaS de nuvem pública para obter velocidade e escalabilidade. Sistemas complexos de linha de negócio com dependências podem começar de forma híbrida — mantendo certos serviços on-premises enquanto front-ends e camadas sem estado (stateless) são movidos para o Azure — antes de completar a transição à medida que as dependências são modernizadas.

• Pública
  • Propriedade/Localização: Regiões de propriedade da Microsoft
  • Acesso típico: Internet/VPN/ExpressRoute
  • Casos de uso: Escalonamento elástico, alcance global, inovação rápida
  • Exemplos do Azure: A maioria dos serviços do Azure, Azure Front Door, Azure App Service
• Privada
  • Propriedade/Localização: Infraestrutura dedicada ao cliente (on-prem ou hospedada)
  • Acesso típico: Redes privadas
  • Casos de uso: Soberania, cargas de trabalho isoladas, conformidade rigorosa
  • Exemplos do Azure: Azure Stack Hub, Azure Stack HCI, AKS on HCI
• Híbrida
  • Propriedade/Localização: Misto de on-prem e Azure
  • Acesso típico: VPN site a site ou ExpressRoute
  • Casos de uso: Migração em fases, localidade de dados, integração de legado
  • Exemplos do Azure: Azure VPN Gateway, ExpressRoute, Azure Arc

Modelos de custo: CapEx vs. OpEx, preço por consumo, pay-as-you-go e capacidade reservada

A aquisição on-premises é tipicamente uma despesa de capital (CapEx): grandes compras iniciais de servidores, armazenamento e rede, depreciadas ao longo de anos. O Azure inverte esse modelo para uma despesa operacional (OpEx): os serviços são medidos e cobrados com base no consumo real — segundos de CPU, GB-mês, transações — deslocando o gasto para o momento em que o valor é realizado. Esse preço baseado no consumo reduz o superprovisionamento e vincula o custo aos padrões de uso. O modelo pay-as-you-go maximiza a flexibilidade: inicie e pare recursos à vontade, sem compromisso de prazo. Para cargas de trabalho constantes, o Azure oferece descontos baseados em reserva, como Reserved Virtual Machine Instances, capacidade reservada do Azure SQL Database, reservas de RU/s do Cosmos DB e capacidade reservada do Storage. Compromissos de um ou três anos podem gerar economias significativas, ao mesmo tempo em que opcionalmente permitem flexibilidade no tamanho da instância e escopo compartilhado entre assinaturas. Opções complementares incluem os Azure Savings Plans for Compute, que aplicam taxas de desconto a serviços de computação elegíveis, e as Spot VMs para cargas de trabalho interrompíveis, em lote, com grandes descontos. Uma governança de custos eficaz combina o modelo comercial certo com controles de engenharia. O Auto-scale reduz a capacidade ociosa; as camadas serverless eliminam a infraestrutura quando ociosa; o Azure Hybrid Benefit aplica licenças existentes do Windows Server e do SQL Server; o preço de Dev/Test reduz os gastos de não produção. O Azure Cost Management + Billing fornece orçamentos, detecção de anomalias e alocação de custos para otimizar continuamente.

• Pay-as-you-go
  • Compromisso: Nenhum
  • Desconto típico vs. PAYG: 0%
  • Flexibilidade: Flexibilidade máxima; inicie/pare a qualquer momento
  • Ideal para: Cargas de trabalho imprevisíveis ou de curta duração
• Reserved VM Instances / Capacidade reservada
  • Compromisso: 1 ano ou 3 anos
  • Desconto típico vs. PAYG: Até ~72% (com Azure Hybrid Benefit)
  • Flexibilidade: O escopo pode ser compartilhado; troca permitida; taxas de cancelamento antecipado
  • Ideal para: Computação constante 24x7, bancos de dados, Cosmos DB
• Savings Plan for Compute
  • Compromisso: Compromisso de gasto de 1 ano ou 3 anos
  • Desconto típico vs. PAYG: Até ~65%
  • Flexibilidade: Aplica-se a VMs, AKS, Functions Premium, App Service
  • Ideal para: Cargas de trabalho de computação mistas com tipos de instância variáveis
• Spot VMs
  • Compromisso: Nenhum (dependente da capacidade)
  • Desconto típico vs. PAYG: Até ~90%
  • Flexibilidade: Pode ser despejado; sem SLA
  • Ideal para: Trabalhos em lote, stateless, CI, renderização

Problema Prático: PeakGear Retail: escalabilidade sazonal com controle de custos e resiliência

Cenário: A PeakGear Retail opera um site de e-commerce com picos de tráfego previsíveis no final do mês e em feriados. A empresa quer migrar de VMs on-premises para o Azure, reduzir despesas de capital, manter uma meta de disponibilidade de 99,99% para a camada web e implementar um plano de recuperação de desastres com um RTO de quatro horas e um RPO de 15 minutos. A identidade deve se integrar com os usuários existentes via Microsoft Entra ID.

Desafio: Projetar uma arquitetura e um modelo de custos no Azure que ofereça escalabilidade elástica para picos de tráfego, tolerância a falhas em nível de zona, recuperação de desastres entre regiões e simplicidade operacional, minimizando os custos durante os períodos de baixa demanda.

Abordagem Recomendada:

1. Implantar a API web e a vitrine (storefront) no Azure App Service (PaaS) usando planos Premium v3 para obter escalonamento automático (autoscale) integrado, aplicação de patches gerenciada da plataforma e opções de redundância de zona.
2. Posicionar duas ou mais instâncias do App Service atrás do Azure Front Door Standard/Premium para entrada global via anycast, terminação SSL, WAF e roteamento baseado em caminho (path-based routing); habilitar sondas de integridade (health probes) e afinidade de sessão (session affinity) conforme necessário.
3. Usar o Azure SQL Database Business Critical com redundância de zona na região primária; configurar a replicação geográfica ativa (active geo-replication) para uma região secundária pareada, visando um RPO de 15 minutos.
4. Armazenar conteúdo estático no Azure Storage com RA-GRS; usar o Azure CDN from Microsoft na frente para descarregar a largura de banda e melhorar a latência.
5. Implementar regras de escalonamento automático (autoscale) baseadas em CPU, requisições e profundidade da fila para escalar horizontalmente (scale out) durante os picos e reduzir (scale in) durante os períodos de calmaria; para trabalhos em segundo plano (background jobs), usar os planos Azure Functions Consumption ou Elastic Premium.
6. Alcançar 99,99% de disponibilidade da camada web habilitando a redundância de zona (multi-zone) para o plano do App Service ou distribuindo instâncias entre Zonas de Disponibilidade (Availability Zones) onde houver suporte.
7. Adotar o modelo pay-as-you-go inicialmente para ter flexibilidade; para a capacidade de base estável identificada após 30 dias, adquirir uma Reserved Instance de 1 ano para os planos do App Service (via Savings Plan for Compute, que cobre o App Service) e capacidade reservada para o SQL Database para reduzir o custo de execução (run-rate cost).
8. Integrar o Microsoft Entra ID para acesso de usuários e administradores; aplicar o princípio do menor privilégio (least privilege) com funções internas (built-in roles) e acesso condicional (conditional access); proteger segredos no Azure Key Vault, referenciado pelo App Service e pelos pipelines de implantação.
9. Definir e testar runbooks de DR: fazer o failover do SQL para a região secundária, atualizar as prioridades de origem do Front Door para ativar a região secundária e validar a saúde da aplicação dentro de um RTO de quatro horas.
10. Implementar o Azure Monitor e o Log Analytics para centralizar métricas, rastreamentos (traces) e logs; configurar alertas e dashboards; definir orçamentos e alertas de anomalia no Azure Cost Management para otimizar continuamente os gastos.

Justificativa da Arquitetura Azure: Os serviços de PaaS (App Service e Azure SQL Database) maximizam a agilidade e transferem a manutenção do SO e da plataforma sob o modelo de responsabilidade compartilhada, ao mesmo tempo que permitem o escalonamento automático (autoscale) para elasticidade. A implantação com redundância de zona e a replicação multirregional fornecem tolerância a falhas dentro de uma região e recuperação de desastres entre regiões que atendem ao RPO/RTO declarados. O Front Door fornece ingresso global, roteamento baseado em saúde (health-based routing) e proteção WAF. Começar com o modelo pay-as-you-go preserva a flexibilidade durante a migração; comprometer-se com capacidade reservada ou um Savings Plan para a linha de base medida reduz o custo do uso estável, enquanto o escalonamento automático (autoscale) reduz os gastos durante os períodos de baixa demanda. O Microsoft Entra ID centraliza a identidade e o controle de acesso, e o Azure Monitor com o Cost Management mantém a visibilidade operacional e financeira.

Todos os domínios · Arquitetura e Infraestrutura Global do Azure →

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

Navegar Microsoft →