Microsoft AZ-900: Arquitetura e Infraestrutura Global do Azure — 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 arquitetura global do Azure foi projetada para fornecer serviços de nuvem resilientes, de alto desempenho e em conformidade em grande escala. Compreender a disposição física de geografias, regiões e zonas de disponibilidade, juntamente com a hierarquia lógica de grupos de gerenciamento, assinaturas, grupos de recursos e recursos, é fundamental para um design e uma governança confiáveis. O plano de controle fornecido pelo Azure Resource Manager, combinado com modelos declarativos, permite implantações consistentes e repetíveis que se alinham às políticas organizacionais e aos requisitos de segurança. As decisões de design neste domínio influenciam diretamente as metas de disponibilidade, as obrigações de residência de dados e a experiência do usuário em todo o mundo. Selecionar o modelo de redundância correto, calcular SLAs compostos e escolher serviços de roteamento global como Azure Front Door, Traffic Manager e Azure CDN são essenciais para atingir as metas de continuidade de negócios, conformidade e desempenho.

Geografias, Regiões, Zonas de Disponibilidade e Pares de Regiões

As geografias do Azure são conjuntos definidos de regiões que preservam a residência de dados e os limites de conformidade. Exemplos incluem Estados Unidos, Europa, Reino Unido, Austrália e Canadá, bem como nuvens soberanas com modelos distintos de conformidade e conectividade. Cargas de trabalho que devem permanecer dentro de uma determinada jurisdição devem ser implantadas em regiões que pertencem à geografia de destino para garantir o alinhamento regulatório e a residência de dados. Uma região é um conjunto de datacenters implantados dentro de um perímetro definido por latência e conectados por meio de uma rede dedicada de baixa latência. Nem todos os serviços ou recursos estão disponíveis em todas as regiões, portanto, a capacidade e a disponibilidade de recursos devem ser validadas no início do planejamento. Regiões que suportam Zonas de Disponibilidade fornecem três ou mais zonas de datacenter fisicamente separadas com energia, refrigeração e rede independentes. Serviços com redundância de zona (ZRS) e a arquitetura entre zonas protegem contra falhas no nível do datacenter, mantendo o acesso de baixa latência dentro da região. Cada região do Azure é pareada com outra região dentro da mesma geografia para formar um par de regiões (por exemplo, North Europe com West Europe, East US com West US). Os pares de regiões permitem a recuperação priorizada durante interrupções amplas, atualizações de plataforma escalonadas e a replicação de dados para determinados serviços. As opções de redundância geográfica do Azure Storage (GRS/GZRS) replicam dados de forma assíncrona para a região pareada; quando o acesso de leitura ao secundário é necessário, use RA-GRS ou RA-GZRS para permitir leituras do endpoint secundário durante uma interrupção ou um failover planejado. Para cargas de trabalho de missão crítica que exigem alta disponibilidade na região e recuperação de desastres entre regiões, combine a redundância de zona com a replicação de par de regiões. Equilibrar latência, resiliência e conformidade leva a um padrão comum: implantar cargas de trabalho ativas entre zonas em uma região primária e proteger contra desastres regionais replicando dados e fornecendo caminhos de failover para a região pareada. Valide regularmente os runbooks de failover e o comportamento do DNS ou do roteamento de front-end para garantir que os objetivos de recuperação sejam atendidos.

• Geografia
  • Escopo: Limite multirregional
  • Benefício Principal: Residência de dados e conformidade
  • Uso Típico: Alinhamento regulatório (ex: dados da UE)
• Região
  • Escopo: Área metropolitana única
  • Benefício Principal: Acesso de baixa latência aos serviços
  • Uso Típico: Local de implantação principal
• Zona de Disponibilidade
  • Escopo: Datacenters distintos dentro de uma região
  • Benefício Principal: Isolamento de falhas no nível do datacenter
  • Uso Típico: Alta disponibilidade na região
• Par de Regiões
  • Escopo: Duas regiões na mesma geografia
  • Benefício Principal: Recuperação e atualizações coordenadas
  • Uso Típico: Recuperação de desastres entre regiões

Organização e Governança de Recursos: Management Groups, Subscriptions, Resource Groups e Resources

A hierarquia de gerenciamento do Azure permite o controle de políticas, acesso e custos em escala. Os management groups ficam acima das subscriptions e permitem que você aplique o Azure Policy e o controle de acesso baseado em função (RBAC) de forma centralizada, com a herança sendo propagada para management groups e subscriptions filhos. Essa é a estrutura correta para segmentar por divisões da empresa, camadas de ambiente (produção, não produção) ou limites regulatórios, mantendo proteções (guardrails) uniformes. As subscriptions são o limite administrativo, de faturamento e de cota. Elas são adequadas para isolar custos e acesso para unidades de negócio, ambientes ou aplicações. Use um design de subscription consistente para separar produção de não produção e para impor limites e orçamentos. Para organizações com múltiplas divisões e administração descentralizada, atribua a cada divisão uma ou mais subscriptions e coloque-as sob management groups específicos da divisão para uma herança limpa de políticas e RBAC. Os resource groups são contêineres lógicos para recursos que compartilham um ciclo de vida. Eles permitem implantações atômicas, tagueamento consistente e operações de ciclo de vida como exclusão ou bloqueio. Agrupe recursos que são implantados, atualizados e desativados juntos, como uma camada web e seus componentes de monitoramento. Use tags para orientar o estorno/demonstração de custos (chargeback/showback), propriedade, ambiente e atributos de conformidade entre recursos e grupos. Bloqueios (Locks) (ReadOnly, CanNotDelete) adicionam proteção contra exclusão acidental no escopo do recurso ou do grupo. Os resources são as instâncias de serviço implantadas (VMs, planos do App Service, contas de armazenamento). Os escopos do RBAC (management group, subscription, resource group, resource) permitem conceder acesso de privilégio mínimo precisamente onde for necessário. Para implantações com múltiplas divisões, mantenha um único tenant do Microsoft Entra ID, a menos que haja um forte requisito de conformidade ou autonomia para múltiplos tenants; subscriptions e management groups geralmente fornecem separação suficiente com muito menos sobrecarga administrativa.

• Management Group
  • Propósito Principal: Governança em toda a organização
  • Controles Aplicados: RBAC, Policy, Blueprints (via Policy + templates)
  • Padrões Comuns: Segmentação por divisão/regulatória
• Subscription
  • Propósito Principal: Limite de faturamento e cota
  • Controles Aplicados: Orçamentos, RBAC, Policy
  • Padrões Comuns: Isolamento por unidade de negócio (BU) ou por ambiente
• Resource Group
  • Propósito Principal: Limite de ciclo de vida
  • Controles Aplicados: Locks, Tags, RBAC
  • Padrões Comuns: Por aplicação ou unidade de carga de trabalho (workload)
• Resource
  • Propósito Principal: Instância de serviço
  • Controles Aplicados: RBAC em nível de instância, Tags
  • Padrões Comuns: Componentes de serviço individuais

Azure Resource Manager e Templates

O Azure Resource Manager (ARM) é o plano de controle para implantar, atualizar e excluir recursos do Azure por meio de uma API consistente e um modelo baseado em função. O ARM fornece operações idempotentes, gerenciamento de dependências, tagueamento e aplicação de políticas no momento da implantação, permitindo que a governança da plataforma seja incorporada em cada mudança. Templates ARM declarativos descrevem o estado desejado do seu ambiente em JSON e suportam parâmetros, variáveis, condições e templates vinculados modulares. Eles permitem implantações repetíveis e versionadas entre ambientes e subscriptions. Para uma experiência de autoria simplificada, o Bicep oferece uma sintaxe concisa que transpila para templates ARM, mantendo o mesmo mecanismo de implantação e benefícios. Armazene os templates em controle de versão, empacote-os como ’template specs’ para compartilhamento e integre-os em pipelines de CI/CD para garantir mudanças de infraestrutura auditáveis e sem desvios (drift-free). Valores sensíveis, como senhas de administrador ou strings de conexão, nunca devem ser embutidos nos templates. Use parâmetros secureString/secureObject com referências ao Key Vault para que o ARM recupere os segredos no momento da implantação, sem expô-los em logs. Combine templates com identidades gerenciadas (managed identities) para eliminar credenciais fixas (hardcoded) na automação. Essa abordagem reduz o risco enquanto preserva a automação completa para implantações em larga escala e com múltiplas subscriptions.

• Implantações idempotentes
  • Suporte ARM/Template: Sim
  • Resultado: Mudanças seguras e repetíveis
• Aplicação de políticas na implantação
  • Suporte ARM/Template: Sim
  • Resultado: Proteções (Guardrails) incorporadas aos pipelines
• Composição modular
  • Suporte ARM/Template: Módulos vinculados / Módulos Bicep
  • Resultado: Reutilização e padronização
• Manuseio de segredos
  • Suporte ARM/Template: Referências ao Key Vault
  • Resultado: Sem segredos no código ou nos logs

Disponibilidade, SLAs, SLAs Compostos e Ciclo de Vida do Serviço

O Azure publica contratos de nível de serviço (SLAs) com garantia financeira para serviços em disponibilidade geral (GA). Para máquinas virtuais, a disponibilidade depende da topologia de implantação: uma única VM com armazenamento Premium SSD tem um SLA de 99,9%; duas ou mais VMs em um conjunto de disponibilidade (availability set) têm um SLA de 99,95%; e duas ou mais VMs implantadas em zonas de disponibilidade (availability zones) alcançam um SLA de 99,99%. Serviços de plataforma (por exemplo, Azure SQL Database ou App Service) têm seus próprios SLAs, que podem variar por camada (tier) ou opção de redundância. Alinhe a arquitetura ao SLA alvo selecionando o modelo de redundância e as camadas de serviço apropriadas. Quando uma solução depende de múltiplos serviços, o SLA composto é o produto dos SLAs individuais se todos os componentes forem necessários para o funcionamento do aplicativo. Por exemplo, se um aplicativo web (99,95%) depende de um banco de dados (99,99%), a disponibilidade composta é de aproximadamente 0,9995 × 0,9999 = 99,94%. Aumentar a redundância em qualquer camada — como implantar entre zonas, adicionar múltiplas instâncias atrás de um balanceador de carga ou usar armazenamentos de dados georredundantes — melhora a disponibilidade efetiva. Por outro lado, adicionar dependências em série diminui o SLA composto e deve ser justificado por um claro valor funcional. O status do ciclo de vida do serviço afeta as garantias de confiabilidade. Recursos em pré-visualização pública (public preview) são oferecidos para coletar feedback e podem ser limitados a certas regiões ou ter lacunas de funcionalidades; eles normalmente não possuem um SLA e não são recomendados para caminhos críticos de produção. Recursos em GA (disponibilidade geral) estão prontos para produção e são cobertos por um SLA. Roadmaps e cronogramas de lançamento por região devem ser acompanhados para evitar a dependência inadvertida de recursos em pré-visualização em projetos de produção, especialmente em ambientes sensíveis à conformidade (compliance). Metas de recuperação de desastres, como RPO e RTO, complementam os SLAs e orientam as escolhas de design, como replicação entre zonas ou entre regiões, frequência de backup e orquestração de failover. Valide os procedimentos de failover regularmente para garantir que o desempenho de recuperação medido esteja alinhado com os objetivos de negócio e que as dependências de DNS, certificados e identidade também se recuperem conforme o esperado.

• VM Única (Premium SSD)
  • SLA Indicativo: 99,9%
  • Observações: Usar para cargas de trabalho não críticas ou aplicativos tolerantes
• 2+ VMs em um Conjunto de Disponibilidade
  • SLA Indicativo: 99,95%
  • Observações: Protege contra falhas de rack/domínio de falha
• 2+ VMs entre Zonas de Disponibilidade
  • SLA Indicativo: 99,99%
  • Observações: Protege contra falhas no nível do datacenter
• Recurso em Public Preview
  • SLA Indicativo: Sem SLA financeiro
  • Observações: Avaliar; evitar em caminhos críticos
• Recurso em GA (dependente da camada do serviço)
  • SLA Indicativo: Com garantia de SLA
  • Observações: Verificar SLAs específicos da camada e da região

Roteamento Global e Entrega de Conteúdo: Azure Front Door, Traffic Manager e Azure CDN

A experiência do usuário global depende de roteamento inteligente, proximidade do conteúdo e failover rápido. O Azure Front Door é um proxy reverso global de Camada 7 com anycast, que inclui Web Application Firewall (WAF), terminação TLS, roteamento baseado em URL/caminho, afinidade de sessão e sondas de saúde (health probes) a partir da borda. Ele acelera conteúdo dinâmico por meio de split-TCP e otimizações de protocolo, e fornece failover quase instantâneo entre as origens. O Front Door é ideal para aplicativos web e APIs multirregionais ativos-ativos ou ativos-passivos, onde você precisa tanto de desempenho quanto de segurança centralizada na borda. O Azure Traffic Manager é um serviço de distribuição de tráfego baseado em DNS que direciona os clientes para o melhor endpoint usando políticas como prioridade, ponderada, desempenho (latência), geográfica, sub-rede ou multivalor. Por operar no nível do DNS, ele suporta endpoints não-HTTP (por exemplo, serviços TCP) e cenários híbridos, mas a velocidade de failover é limitada pelo TTL do DNS e pelo cache do cliente. O Traffic Manager não atua como proxy para o tráfego nem acelera o conteúdo; ele simplesmente responde às consultas DNS com o endpoint escolhido. A Azure CDN armazena em cache conteúdo estático em pontos de presença na borda para reduzir a latência e desafogar as origens. É bem adequado para grandes ativos estáticos como imagens, vídeos, scripts e downloads. Embora a CDN reduza as viagens de ida e volta (round trips) para conteúdo cacheável, ela não é um balanceador de carga global ciente da saúde para origens dinâmicas; combine-a com o Front Door ou o Traffic Manager para failover entre múltiplas origens ou para lógica de roteamento dinâmico. Muitas arquiteturas posicionam a CDN para cache de ativos estáticos e o Front Door para tráfego dinâmico e segurança na frente da mesma aplicação.

• Azure Front Door (Std/Prm)
  • Camada/Mecanismo: Proxy anycast de Camada 7
  • Casos de Uso Principais: Balanceamento de carga global, segurança de borda, aceleração
  • Métodos de Roteamento: Prioridade, ponderado; regras baseadas em caminho/host
  • Sondas de Saúde: Sondas dos POPs de borda
  • Velocidade de Failover: Segundos (quase instantâneo)
  • Aceleração Dinâmica: Sim
  • Cache Estático: Sim (baseado em regras)
  • WAF Disponível: Sim (integrado)
  • Padrão Típico: Front Door na frente de aplicativos web/APIs multirregionais
• Azure Traffic Manager
  • Camada/Mecanismo: Política baseada em DNS
  • Casos de Uso Principais: Roteamento DNS entre regiões; endpoints não-HTTP
  • Métodos de Roteamento: Prioridade, ponderado, desempenho, geográfico, sub-rede, multivalor
  • Sondas de Saúde: Sondas de endpoint globais
  • Velocidade de Failover: Limitada pelo TTL (dezenas de segundos a minutos)
  • Aceleração Dinâmica: Não
  • Cache Estático: Não
  • WAF Disponível: N/A
  • Padrão Típico: Direcionamento DNS para serviços HTTP e não-HTTP
• Azure CDN
  • Camada/Mecanismo: Rede de cache de borda
  • Casos de Uso Principais: Desafogamento de conteúdo estático e redução de latência
  • Métodos de Roteamento: N/A (regras de cache)
  • Sondas de Saúde: N/A (failover opcional de grupo de origem)
  • Velocidade de Failover: N/A (baseado em cache)
  • Aceleração Dinâmica: Não (além do cache)
  • Cache Estático: Sim
  • WAF Disponível: Via Front Door Premium ou WAF separado
  • Padrão Típico: CDN para ativos + Front Door/Traffic Manager para as origens

Problema Prático: Projetando uma Plataforma Web Altamente Disponível, em Conformidade e com Desempenho Global para a IronPeak Manufacturing

Cenário: A IronPeak Manufacturing opera na Europa e na América do Norte e está consolidando seus portais de clientes e parceiros no Azure. A plataforma deve atender a 99,99% de disponibilidade para a camada web, manter os dados de clientes da UE dentro da UE, fornecer failover rápido entre regiões e entregar carregamentos de página rápidos em todo o mundo. A equipe deseja implantações totalmente automatizadas sem segredos em texto plano no código ou nos logs.

Desafio: Alcançar alta disponibilidade na região e recuperação de desastres entre regiões com residência de dados na UE, aceleração global e failover para tráfego dinâmico, e implantações repetíveis e seguras entre assinaturas (subscriptions).

Abordagem Recomendada:

1. Selecione a geografia da Europa e implante a carga de trabalho (workload) primária em uma região com Zonas de Disponibilidade (Availability Zones) (por exemplo, West Europe) usando duas ou mais instâncias de VM scale set ou instâncias do App Service distribuídas entre as zonas.
2. Habilite a recuperação de desastres entre regiões para a região pareada (North Europe) usando a replicação nativa dos serviços: use RA-GZRS para o Storage e georreplicação para bancos de dados onde disponível; configure runbooks de failover automatizado.
3. Posicione o Azure Front Door Standard/Premium na frente da aplicação para terminação HTTPS global, WAF, sondas de integridade (health probes) de borda, failover baseado em prioridade entre West Europe (primária) e North Europe (secundária), e regras para roteamento baseado em caminho (path-based routing).
4. Faça o cache de ativos estáticos (imagens, scripts, downloads) usando a Azure CDN integrada com as mesmas origens para reduzir a latência e descarregar o tráfego; valide as regras de cache e os TTLs.
5. Defina grupos de gerenciamento (management groups) para as divisões da UE e da América do Norte (NA); coloque as assinaturas (subscriptions) de produção e não produção sob cada um, aplicando o Azure Policy para residência de dados, marcação (tagging) e locais permitidos.
6. Implemente templates ARM/Bicep armazenados em controle de versão e publicados como especificações de template (template specs); parametrize regiões, SKUs e escalonamento; referencie segredos do Azure Key Vault usando identidades gerenciadas (managed identities) para as implantações.
7. Defina SLAs e teste a disponibilidade composta: duas instâncias distribuídas por zona atrás do Front Door visam 99,99% para a camada de aplicação; valide trimestralmente os exercícios de failover de ponta a ponta, DNS, certificados e dependências de identidade.
8. Instrumente a plataforma com o Application Insights e o Azure Monitor; configure as sondas de integridade (health probes) e os alertas do Front Door; ajuste as políticas de autoescalonamento (autoscale) e de cache com base na telemetria.

Justificativa do Azure: Este design mantém os dados da UE dentro da geografia da Europa, ao mesmo tempo que fornece isolamento de falhas na região por meio das Zonas de Disponibilidade (Availability Zones) e recuperação de desastres entre regiões para a região pareada. O Azure Front Door entrega aceleração global e failover ciente da integridade (health-aware) para tráfego dinâmico, enquanto a Azure CDN descarrega o conteúdo estático para melhorar o desempenho. Templates ARM/Bicep com referências ao Key Vault fornecem implantações repetíveis e seguras entre assinaturas e regiões. As topologias escolhidas se alinham aos SLAs publicados para atingir a meta de 99,99% para a camada web, e as políticas (policy) nos níveis de grupo de gerenciamento e assinatura impõem a governança com sobrecarga operacional mínima.

← Conceitos de Nuvem · Todos os domínios · Serviços de Computação e Aplicativos →

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

Navegar Microsoft →