Microsoft Azure Administrator Associate
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame AZ-104 avalia. Leia de cima a baixo ou pule para uma seção.
Gerenciar automaticamente a associação a grupos de segurança com base em atributos de usuário (por exemplo, departamento).
Configure um grupo de segurança do Microsoft Entra ID com o tipo de associação "Usuário Dinâmico" e defina uma regra baseada em atributos.
Por quê: Regras baseadas em atributos eliminam a administração manual contínua para alterações no ciclo de vida do usuário. Requer Entra ID P1/P2.
Aplicar governança consistente (políticas, RBAC) em várias assinaturas a partir de um único ponto de gerenciamento.
Crie um grupo de gerenciamento, coloque as assinaturas sob ele e atribua políticas ou funções RBAC no escopo do grupo de gerenciamento.
Por quê: Políticas e atribuições de função são herdadas por todas as assinaturas filhas, permitindo uma governança centralizada e consistente.
Impedir a implantação de recursos em regiões do Azure não autorizadas em toda uma assinatura.
Atribua a Política do Azure integrada "Localizações permitidas" com um efeito `Deny` no escopo da assinatura.
Por quê: A Política fornece governança preventiva. O RBAC controla ações, não locais de implantação. Os Bloqueios de Recurso impedem modificação/exclusão, não novas implantações.
Conceder permissões para gerenciar VMs, mas não a rede virtual subjacente ou o acesso do usuário.
Atribua a função integrada "Colaborador de Máquina Virtual" no escopo do grupo de recursos ou da VM.
Por quê: Esta função fornece permissões específicas de gerenciamento de VM (iniciar, parar, reinstalar imagem) sem conceder direitos amplos de Colaborador ou Proprietário.
Exigir MFA quando os usuários acessam aplicativos de nuvem específicos (por exemplo, portal do Azure) de fora da rede corporativa.
Crie uma política de Acesso Condicional com uma "Localização Nomeada" para IPs corporativos como uma condição de exclusão e exija MFA como um controle de concessão.
Por quê: Excluir um local confiável é a chave para ignorar o MFA na rede corporativa enquanto o aplica em todos os outros lugares.
Impedir a exclusão de recursos críticos, mesmo por administradores com funções de Proprietário.
Aplique um bloqueio de recurso `CanNotDelete` ou `ReadOnly` no recurso ou em seu grupo de recursos.
Por quê: Os bloqueios de recurso se aplicam a todos os usuários, independentemente de sua função RBAC, fornecendo a proteção mais forte contra exclusão acidental.
Corrigir automaticamente recursos não conformes existentes identificados por uma Política do Azure (por exemplo, adicionar uma tag ausente).
Para políticas com efeitos `Modify` ou `DeployIfNotExists`, crie uma tarefa de remediação para a atribuição de política.
Por quê: As tarefas de remediação acionam a ação corretiva da política em todos os recursos não conformes existentes, automatizando o processo de conformidade de um ambiente.
Relatar os custos do Azure discriminados por departamento, projeto ou unidade de negócios.
Aplique uma tag consistente (por exemplo, "CostCenter") a todos os recursos. Use o Azure Cost Management para filtrar e agrupar custos por essa tag.
Por quê: Tags são o principal mecanismo para alocação de custos personalizada e relatórios em diferentes grupos de recursos e assinaturas.
Conceder funções privilegiadas aos administradores apenas quando necessário, por tempo limitado e com um fluxo de trabalho de aprovação.
Use o Microsoft Entra Privileged Identity Management (PIM). Torne os usuários elegíveis para funções e configure os requisitos de ativação.
Por quê: O PIM impõe o acesso Just-In-Time (JIT), reduzindo a exposição de contas privilegiadas permanentes e fornecendo um registro de auditoria completo.
Conceder a parceiros externos acesso a recursos do Azure usando suas próprias credenciais corporativas.
Use a colaboração B2B do Microsoft Entra para convidar parceiros como usuários convidados para seu locatário.
Por quê: O B2B evita a criação e o gerenciamento de novas credenciais em seu locatário; os parceiros usam seu provedor de identidade existente para autenticação.
Minimizar os custos de armazenamento para dados de longo prazo (por exemplo, arquivos de conformidade) que são raramente acessados, mas devem ser retidos.
Use uma política de gerenciamento de ciclo de vida de blob para fazer a transição automática de blobs de Hot/Cool para a camada Archive.
Por quê: A camada Archive tem o menor custo de armazenamento. As regras de ciclo de vida automatizam o processo de camadas com base na idade do blob ou no último tempo de acesso.
Garantir acesso de leitura aos dados de armazenamento de uma região secundária durante uma interrupção da região primária.
Configure a conta de armazenamento com Read-Access Geo-Redundant Storage (RA-GRS) ou RA-GZRS.
Por quê: GRS/GZRS padrão replica dados, mas não permite acesso de leitura ao secundário até um failover. O prefixo "RA" é necessário para acesso de leitura contínuo.
Capacidade de revogar imediatamente um conjunto de tokens de Assinatura de Acesso Compartilhado (SAS) para um contêiner específico.
Crie tokens SAS com base em uma política de acesso armazenada no contêiner. Para revogar, modifique ou exclua a política.
Por quê: A modificação da política de acesso armazenada invalida imediatamente todos os tokens SAS associados a ela, fornecendo um mecanismo de revogação centralizado.
Sincronizar um servidor de arquivos local com um compartilhamento de arquivos do Azure, minimizando o uso do espaço em disco local.
Implante o Azure File Sync e habilite o tiering de nuvem no endpoint do servidor.
Por quê: O tiering de nuvem mantém apenas os arquivos acessados com frequência ("quentes") armazenados em cache localmente, enquanto os arquivos menos usados são distribuídos para o Azure, aparecendo como stubs no servidor local.
Restringir o acesso à rede a uma conta de armazenamento a sub-redes VNet específicas e endereços IP públicos.
Habilite o firewall da conta de armazenamento. Adicione regras de rede virtual para as sub-redes e regras de endereço IP para os IPs públicos.
Por quê: O firewall de armazenamento fornece controle de acesso em nível de rede diretamente no endpoint público da conta de armazenamento, bloqueando todo o outro tráfego.
Proteger blobs contra exclusão acidental, permitindo a recuperação por um período especificado.
Habilite a exclusão suave de blobs na conta de armazenamento e configure o período de retenção (por exemplo, 14 dias).
Por quê: A exclusão suave retém blobs excluídos pelo período configurado, permitindo uma restauração simples. Esta é a primeira linha de defesa contra perda acidental de dados.
Cumprir os requisitos de conformidade para armazenar dados em um estado não apagável e não modificável (WORM) por um período fixo.
Configure uma política de retenção baseada em tempo em um contêiner de blob e bloqueie a política.
Por quê: Uma política de retenção baseada em tempo bloqueada torna os blobs imutáveis, impedindo a exclusão ou modificação por qualquer pessoa (incluindo administradores) até que o período de retenção expire.
Migrar um conjunto de dados muito grande (por exemplo, mais de 50 TB) para o Azure Blob Storage quando a largura de banda da rede é limitada.
Use o dispositivo físico Azure Data Box para uma transferência offline.
Por quê: Para grandes conjuntos de dados, o envio de um dispositivo físico é significativamente mais rápido do que a transferência de dados por uma conexão de rede lenta ou saturada.
Atingir um SLA de 99,99% para VMs e proteger um aplicativo contra uma falha de datacenter único dentro de uma região.
Implante várias instâncias de VM em diferentes Zonas de Disponibilidade dentro da mesma região.
Por quê: Zonas de Disponibilidade são datacenters fisicamente separados. Conjuntos de Disponibilidade protegem apenas contra falhas em nível de rack dentro de um único datacenter (SLA de 99,95%).
Implantar e testar uma nova versão do aplicativo com tráfego de produção real antes de um lançamento completo, com zero tempo de inatividade.
Use um slot de implantação do Serviço de Aplicativo. Implante no slot, teste e, em seguida, execute uma troca. Opcionalmente, use o roteamento de tráfego para testes canary.
Por quê: Slots fornecem um ambiente de teste completo. A operação de troca é um redirecionamento quase instantâneo de tráfego, garantindo zero tempo de inatividade.
Executar um trabalho em lote conteinerizado de curta duração em um cronograma, com custo mínimo e sem gerenciamento de infraestrutura.
Use Azure Container Instances (ACI).
Por quê: O ACI oferece faturamento por segundo e sem sobrecarga de gerenciamento de cluster, tornando-o a opção mais econômica para cargas de trabalho de contêiner esporádicas ou de curta duração.
Dimensionar automaticamente uma carga de trabalho com picos diários previsíveis (por exemplo, horário comercial), enquanto também lida com picos inesperados.
Configure o dimensionamento automático do Conjunto de Escala de VM com regras baseadas em agendamento e regras baseadas em métricas.
Por quê: Combinar dimensionamento proativo (agendamento) e reativo (métrica) oferece o melhor equilíbrio entre desempenho (pronto antes do pico) e eficiência de custo (diminui quando ocioso).
Armazenar imagens de contêiner para um cluster do Azure Kubernetes Service (AKS) de forma segura em um registro privado com varredura de vulnerabilidades.
Use o SKU Premium do Azure Container Registry (ACR) e integre-o ao AKS usando uma identidade gerenciada.
Por quê: O ACR fornece um registro privado co-localizado no Azure. O SKU Premium inclui varredura de vulnerabilidades. A identidade gerenciada fornece autenticação segura e sem credenciais do AKS para o ACR.
Executar uma atualização de SO ou aplicativo em todas as instâncias do VMSS sem causar tempo de inatividade do aplicativo.
Atualize o modelo do VMSS (por exemplo, nova versão da imagem) e use uma política de atualização Rolling.
Por quê: A política Rolling atualiza as instâncias em lotes configuráveis, garantindo que um subconjunto de instâncias esteja sempre disponível para servir o tráfego durante todo o processo de atualização.
Implantar um aplicativo multi-contêiner (por exemplo, aplicativo + sidecar de log) que deve compartilhar rede e armazenamento, sem um orquestrador completo.
Implante os contêineres em um único grupo de contêineres do Azure Container Instances (ACI).
Por quê: Um grupo de contêineres co-localiza vários contêineres, compartilhando uma rede e volumes localhost, perfeito para padrões sidecar sem a complexidade do Kubernetes.
Aumentar o tamanho do disco de SO ou de dados de uma VM após sua implantação.
Desalocar a VM, redimensionar o recurso de disco no Azure, iniciar a VM e, em seguida, estender a partição dentro do SO convidado.
Por quê: O redimensionamento do disco do Azure apenas aloca mais espaço. O SO convidado deve ser instruído a usar esse novo espaço estendendo sua partição de sistema de arquivos.
Permitir que um Serviço de Aplicativo acesse com segurança segredos do Azure Key Vault sem armazenar credenciais no aplicativo.
Habilite uma identidade gerenciada atribuída ao sistema no Serviço de Aplicativo e conceda a essa identidade permissões de `Get` e `List` nos segredos do Key Vault.
Por quê: A identidade gerenciada fornece um mecanismo de autenticação sem credenciais. O aplicativo pode adquirir um token de acesso para o Key Vault automaticamente, eliminando o gerenciamento de segredos.
Organizar uma implantação de infraestrutura como código grande e complexa em componentes menores, reutilizáveis e mantenedores.
Refatore a implantação em módulos Bicep, com cada módulo representando uma unidade lógica (por exemplo, rede, computação), e orquestre-os a partir de um arquivo Bicep principal.
Por quê: Módulos promovem a reutilização de código, melhoram a legibilidade e simplificam o gerenciamento de implantações de infraestrutura complexas.
Isolar camadas de aplicativo (web, aplicativo, dados) dentro de uma VNet, impedindo a comunicação direta entre camadas não adjacentes.
Use uma sub-rede separada para cada camada e aplique Grupos de Segurança de Rede (NSGs) a cada sub-rede para controlar o fluxo de tráfego.
Por quê: NSGs permitem filtragem granular e com estado com base em intervalos de IP de origem/destino (sub-redes), portas e protocolos, permitindo a micro-segmentação de rede.
Conectar duas VNets em diferentes regiões do Azure de forma privada pela rede backbone da Microsoft.
Configure o Global VNet Peering entre as duas VNets.
Por quê: O Global Peering é mais simples, de menor latência e maior largura de banda do que uma conexão VPN VNet-a-VNet. O tráfego permanece na rede privada da Microsoft.
VNet-A está emparelhada com Hub-VNet, e Spoke-VNet também está emparelhada com Hub-VNet. VMs em VNet-A não podem alcançar VMs em Spoke-VNet.
A causa é que o emparelhamento de VNet é não-transitivo. Para habilitar a comunicação, emparelhe VNet-A e Spoke-VNet diretamente ou use um NVA no Hub.
Por quê: O emparelhamento não cria uma cadeia. Cada VNet deve ser conectada diretamente para se comunicar, a menos que o roteamento através de um Dispositivo Virtual de Rede seja configurado.
Estabelecer um túnel IPsec persistente e criptografado de uma rede local para uma VNet do Azure pela internet pública.
Implante um Azure VPN Gateway na VNet e configure uma conexão Site-to-Site (S2S).
Por quê: Esta é a solução padrão, segura e confiável para conectividade híbrida entre um único site local e uma VNet do Azure.
Um Azure Load Balancer continua a enviar tráfego para uma VM de backend não saudável, causando tempos limite no aplicativo.
Configure uma sonda de saúde no balanceador de carga que verifique com precisão a saúde do aplicativo nas VMs de backend.
Por quê: O balanceador de carga depende inteiramente das sondas de saúde para detectar instâncias não saudáveis. Sem uma sonda configurada corretamente, ele não pode remover VMs com falha da rotação de tráfego.
Roteie o tráfego HTTP/S para diferentes pools de servidores de backend com base no caminho da URL (por exemplo, /images/* vs /api/*).
Use o Azure Application Gateway com regras de roteamento baseadas em caminho.
Por quê: O Application Gateway é um balanceador de carga da Camada 7 que inspeciona solicitações HTTP e pode tomar decisões de roteamento com base em caminhos de URL. Um Azure Load Balancer padrão é da Camada 4 e não pode.
VMs em uma VNet com um servidor DNS personalizado não conseguem resolver nomes de host em uma Zona DNS Privada do Azure.
Configure o servidor DNS personalizado para encaminhar condicionalmente consultas para a zona privada para o IP do resolvedor DNS fornecido pelo Azure (168.63.129.16).
Por quê: Quando um servidor DNS personalizado é usado, ele ignora o DNS interno do Azure. O servidor personalizado deve ser ensinado a resolver zonas específicas do Azure encaminhando solicitações para o Azure DNS.
Forçar todo o tráfego de saída para a internet das VNets spoke a ser inspecionado por um Azure Firewall central na VNet hub.
Aplique uma Tabela de Rotas com uma Rota Definida pelo Usuário (UDR) às sub-redes spoke. A UDR é uma rota padrão (0.0.0.0/0) apontando para o IP privado do firewall.
Por quê: Uma UDR substitui a rota de sistema padrão do Azure para a internet, permitindo controlar e centralizar o fluxo de tráfego de saída para inspeção de segurança.
Fornecer acesso RDP/SSH seguro a VMs que não possuem endereços IP públicos, sem configurar uma VPN.
Implante o Azure Bastion em uma sub-rede dedicada (AzureBastionSubnet) na VNet.
Por quê: O Bastion fornece um serviço de jump box gerenciado, permitindo acesso administrativo seguro via portal do Azure sobre TLS, eliminando a exposição de IP público em VMs.
Garantir que o tráfego entre uma VM e um serviço PaaS (por exemplo, Azure SQL) permaneça na rede privada e que o serviço PaaS não seja acessível publicamente.
Crie um private endpoint para o serviço PaaS na VNet da VM e desative o acesso à rede pública no serviço PaaS.
Por quê: Um private endpoint atribui ao serviço PaaS um IP privado dentro de sua VNet, enquanto a desativação do acesso público garante que ele seja acessível apenas por meio desse IP privado.
Encaminhar usuários globais para o endpoint de aplicativo regional mais próximo para garantir a menor latência possível.
Use o Azure Traffic Manager com o método de roteamento "Performance".
Por quê: O método de roteamento Performance usa DNS para direcionar os clientes para o endpoint com a menor latência de rede a partir de sua localização.
Enviar uma notificação (e-mail, SMS, webhook) quando uma métrica de recurso (por exemplo, percentual de CPU da VM) exceder um limite por uma duração definida.
Crie uma regra de Alerta de Métrica no Azure Monitor e vincule-a a um Grupo de Ação que define a ação de notificação.
Por quê: Este é o padrão. A regra de alerta define a condição (o quê/quando), e o grupo de ação define a notificação resultante (quem/como).
Determinar se o tráfego entre duas VMs está sendo bloqueado por uma regra específica do Network Security Group (NSG).
Use a ferramenta IP Flow Verify no Azure Network Watcher.
Por quê: O IP Flow Verify simula um fluxo de pacotes e relata explicitamente qual NSG e regra está permitindo ou negando o tráfego, tornando-o a ferramenta definitiva para solucionar conflitos de NSG.
Configurar backups agendados e baseados em políticas para VMs do Azure com consistência de aplicativo e retenção de longo prazo.
Crie um cofre dos Serviços de Recuperação, defina uma política de backup (agendamento, retenção) e habilite o backup para as VMs de destino.
Por quê: O cofre dos Serviços de Recuperação é a entidade de gerenciamento central para o Azure Backup. Ele armazena dados de backup com segurança e gerencia todas as operações de backup e restauração.
Criar um dashboard centralizado para monitorar o desempenho (CPU, Memória, Disco, Rede) de VMs em várias assinaturas.
Implante um workspace central do Log Analytics e habilite o VM Insights para todas as VMs de destino, apontando-as para o workspace.
Por quê: O VM Insights coleta e agrega dados de desempenho, fornecendo pastas de trabalho pré-construídas e uma visão consolidada de desempenho "em escala" em várias assinaturas.
Identificar proativamente recursos subutilizados do Azure e oportunidades de economia de custos (por exemplo, dimensionamento correto de VM).
Revise regularmente as recomendações de Custo no Azure Advisor.
Por quê: O Azure Advisor analisa automaticamente o uso de recursos e fornece recomendações acionáveis e personalizadas para economia de custos sem exigir configuração adicional.
Replicar VMs do Azure de uma região primária para uma região secundária para fornecer capacidade de recuperação de desastres.
Use o Azure Site Recovery. Crie um cofre dos Serviços de Recuperação e habilite a replicação para as VMs na região de destino.
Por quê: O ASR é o serviço nativo do Azure para orquestrar a replicação de VM, teste de failover e failover/failback entre regiões do Azure.
Definir diferentes períodos de retenção de dados para logs de segurança versus logs de desempenho em um único workspace do Log Analytics para otimizar custos.
Defina uma retenção padrão no nível do workspace e, em seguida, configure um período de retenção mais longo no nível da tabela individual (por exemplo, para a tabela SecurityEvent).
Por quê: A retenção por tabela permite atender às necessidades de conformidade de longo prazo para dados específicos, minimizando os custos de armazenamento para dados menos críticos e de alto volume.
