Microsoft AZ-104: Assinaturas do Azure, Governança e Gerenciamento de Custos — Guia de estudos

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Visão Geral

As assinaturas, a governança e o gerenciamento de custos do Azure definem como você estrutura, protege, padroniza e paga por recursos de nuvem em escala. Um design sólido começa com uma hierarquia organizacional (grupos de gerenciamento e assinaturas), aplica o acesso de privilégio mínimo (RBAC), impõe padrões e conformidade (Policy, Blueprints, bloqueios e tags) e otimiza continuamente os gastos (Cost Management e Advisor). O Azure Resource Manager (ARM) sustenta as operações de implantação, agrupamento e ciclo de vida para que os padrões e controles sejam aplicados de forma consistente desde o grupo de gerenciamento raiz até os recursos individuais.

Estrutura Organizacional e Controle de Acesso

Grupos de Gerenciamento (Management Groups) são a construção de nível superior para organizar uma ou mais assinaturas sob um único grupo de gerenciamento raiz. Você pode aninhar grupos de gerenciamento em até seis níveis de profundidade (excluindo a raiz) para espelhar os limites organizacionais ou de ambiente (por exemplo, Corp > Prod/NonProd > Unidades de Negócio). Tanto as atribuições de função do RBAC quanto as atribuições do Azure Policy aplicadas em um grupo de gerenciamento são herdadas por todos os grupos de gerenciamento, assinaturas, grupos de recursos e recursos filhos, a menos que sejam explicitamente substituídas em um escopo inferior. Essa herança é fundamental para impor padrões de forma consistente; por exemplo, uma política de “Negar armazenamento público” no grupo de gerenciamento de Produção se aplica a todas as assinaturas de produção sem a necessidade de configuração por assinatura.

Assinaturas (Subscriptions) são limites de isolamento para faturamento e implantação. Os tipos comuns incluem Pay-As-You-Go, Enterprise Agreement (EA), Microsoft Customer Agreement (MCA), CSP e ofertas baseadas em crédito, como as assinaturas do Visual Studio. As assinaturas separam os escopos de gastos, cotas e RBAC e são a unidade atômica para cobranças e orçamentos. Mover recursos entre assinaturas é frequentemente necessário durante transições de ciclo de vida (por exemplo, de um tenant de desenvolvimento para um de produção, reorganizações). O suporte para movimentação de recursos é específico do provedor e do recurso; recursos baseados em ARM, como VMs, discos gerenciados, contas de armazenamento, redes virtuais e até cofres do Recovery Services, geralmente podem ser movidos com restrições. Os pré-requisitos incluem ter a origem e o destino no mesmo tenant do Azure Active Directory (movimentações entre tenants são limitadas), provedores de recursos registrados em ambas as assinaturas, regiões/SKUs compatíveis e a ausência de bloqueios/políticas impeditivas. Espere indisponibilidade transitória para alguns recursos durante a movimentação; planeje janelas de manutenção para serviços com estado (stateful). Recursos Clássicos (ASM) não podem ser movidos. Sempre verifique o suporte usando a operação “Mover” no portal ou na documentação do provedor de recursos.

O Azure RBAC fornece acesso granular de privilégio mínimo usando atribuições de função (role assignments) em um escopo específico. O escopo pode ser um grupo de gerenciamento, uma assinatura, um grupo de recursos ou um recurso individual; as atribuições são herdadas para baixo. As principais funções internas (built-in roles) são:

Owner: acesso total a todos os recursos, incluindo atribuições de função.
Contributor: permissão total para criar/atualizar/excluir recursos, exceto a permissão para atribuir funções.
Reader: acesso somente leitura. Funções personalizadas (Custom roles) permitem que você especifique as Actions e DataActions permitidas, excluindo NotActions e NotDataActions, e são definidas no escopo de atribuição pretendido ou acima dele. Atribuições de negação (Deny assignments), criadas por certos serviços como Blueprints ou por bloqueios, têm precedência sobre as atribuições de permissão (allow assignments), impedindo a escalada acidental de privilégios.

Governança, Conformidade e Barreiras de Proteção de Recursos

O Azure Policy avalia o estado do recurso no momento da criação/atualização e em varreduras regulares de conformidade. Uma definição de política expressa uma regra (com parâmetros opcionais) e um efeito. Você agrupa definições relacionadas em iniciativas para simplificar a atribuição em larga escala. As atribuições anexam uma definição ou iniciativa a um escopo (grupo de gerenciamento, assinatura, grupo de recursos ou recurso) com valores de parâmetro e, para certos efeitos, uma identidade gerenciada para remediação. Efeitos principais a dominar:

Deny: bloqueia operações de criação/atualização não conformes no momento da solicitação.
Audit: permite a operação, mas registra a não conformidade para relatórios.
DeployIfNotExists: se um recurso ou configuração relacionada estiver ausente, aciona uma implantação de template para colocar o alvo em conformidade (por exemplo, implantar uma configuração de diagnóstico ou uma atribuição de política). Outros efeitos importantes incluem Append (adiciona campos como tags na escrita) e Modify (corrige propriedades). As políticas podem impor locais permitidos, restrições de SKU, tags obrigatórias, configurações de diagnóstico e padrões de criptografia. Por exemplo, restringir os locais do Azure SQL Server garante que as implantações ocorram apenas em regiões ou grupos de recursos aprovados.

O Azure Blueprints empacota a governança como código (governance-as-code) combinando artefatos — atribuições de política, atribuições de função, templates ARM e declarações de grupos de recursos — em um blueprint versionado. Atribua blueprints a assinaturas ou grupos de gerenciamento para padronizar ambientes de forma consistente. A atribuição de blueprint pode aplicar bloqueios no nível do artefato com modos como DoNotDelete ou ReadOnly para proteger os recursos implantados contra desvios (drift). Use Blueprints para inicializar novas assinaturas com controles obrigatórios e infraestrutura de base.

Bloqueios de recursos (Resource locks) fornecem uma última linha de defesa contra modificações acidentais. Aplique CanNotDelete para impedir a exclusão, permitindo atualizações; aplique ReadOnly para bloquear operações de escrita e exclusão. Os bloqueios são herdados de escopos superiores, então um bloqueio ReadOnly em um grupo de recursos afeta todos os recursos contidos (por exemplo, parar/iniciar uma VM falha porque essas operações realizam escritas). Os bloqueios sobrepõem as permissões do RBAC: mesmo os Owners não podem excluir um recurso bloqueado sem primeiro remover o bloqueio.

Tags são pares de chave-valor em grupos de recursos e recursos para categorizar cargas de trabalho (workloads) (departamento, ambiente, centro de custo). A herança de tags não é automática; para garantir tags em cada recurso, use o Azure Policy (Append/Modify) para impor ou herdar tags do grupo de recursos no momento da criação/atualização. As tags impulsionam os relatórios de custos baseados em tags no Cost Management para que os departamentos sejam cobrados (chargeback) com precisão. Para associar recursos individuais, como máquinas virtuais, a departamentos, aplique tags diretamente em cada VM.

Gerenciamento e Otimização de Custos

O Azure Cost Management + Billing oferece orçamentos, análise de custos, exportações e alertas. Os orçamentos são definidos em um escopo (assinatura ou grupo de recursos) e podem filtrar por grupo de recursos, serviço ou tag. Configure limites (ex: 50%, 80%, 100%) para enviar alertas via grupos de ação e, opcionalmente, acionar automação (Logic App, Function) para reduzir a escala ou desligar cargas de trabalho não críticas; os orçamentos em si não impõem um limite de gastos. A análise de custos permite dinamizar por tempo, recurso, medidor (meter), grupo de recursos, assinatura e tag para entender os fatores e tendências; agende exportações para o armazenamento para ingestão em ferramentas de BI. Limites de gastos estão disponíveis para ofertas baseadas em crédito (por exemplo, avaliação gratuita, Visual Studio) e, quando atingidos, colocam a assinatura em um estado desabilitado para evitar cobranças futuras. Limites de gastos não são suportados em ofertas Pay-As-You-Go ou na maioria das ofertas EA/MCA; use orçamentos e automação em vez disso.

O Azure Advisor avalia continuamente seus recursos e produz recomendações acionáveis nas categorias de custo, segurança, confiabilidade, desempenho e excelência operacional. As recomendações de custo incluem o dimensionamento correto (rightsizing)/desligamento de VMs subutilizadas, a compra de reservas ou planos de economia (savings plans) e a eliminação de IPs públicos ou discos ociosos. Confiabilidade inclui conjuntos/zonas de disponibilidade e configurações de backup; desempenho abrange otimizações de computação/armazenamento; segurança se integra com o Defender for Cloud; excelência operacional destaca configurações de melhores práticas. Use o Advisor Score para acompanhar o progresso e integre as recomendações ao backlog ou à remediação automatizada, quando apropriado.

Implantação e Ciclo de Vida com o Azure Resource Manager

O ARM é o plano de controle do Azure, permitindo implantações declarativas e idempotentes e um gerenciamento consistente. Grupos de recursos (resource groups) são contêineres lógicos para limites de ciclo de vida e RBAC; agrupe recursos que compartilham o mesmo ciclo de vida, permissões e dependências de localização. As atribuições de RBAC e de políticas (policy) no escopo do grupo de recursos governam todos os recursos contidos, e os bloqueios (locks) e tags em nível de grupo são herdados, a menos que sejam substituídos por políticas ou operações em nível de recurso.

Os templates ARM (e o Bicep como uma linguagem de nível superior) definem recursos, parâmetros, variáveis, saídas e dependências. Eles permitem implantações repetíveis e garantem que artefatos de governança (ex: políticas, atribuições de função) e workloads sejam aplicados em conjunto. Use as especificações de template (template specs) para versionar e compartilhar templates em toda a organização. Os modos de implantação são importantes:

Incremental: cria/atualiza recursos no template; não remove recursos existentes que não estão no template.
Complete: após a implantação, exclui os recursos no escopo de destino que não estão definidos no template — use com cautela para impor um estado desejado estrito dentro do grupo de recursos. O histórico de implantação tem como escopo o grupo de recursos, a assinatura (subscription) ou o grupo de gerenciamento (management group). Quando vários recursos são implantados por um único template, você visualiza a implantação e seu template a partir da folha (blade) de Implantação do escopo de destino — comumente o grupo de recursos — para auditar alterações e solucionar problemas.

Cenário de Problema Prático

A Starbucks adquire uma rede regional e precisa integrar três novas assinaturas (subscriptions), aplicando políticas de segurança globais, permitindo o estorno de custos (chargeback) em nível de departamento e migrando vários serviços compartilhados para uma assinatura consolidada “Corp-IT” sem interrupção do serviço.

Construa a hierarquia de grupos de gerenciamento

Ação: Crie uma hierarquia alinhada à raiz Starbucks > Prod/NonProd > BusinessUnits (Retail, SupplyChain, CorpIT).
Por quê: Grupos de gerenciamento fornecem herança hierárquica de RBAC e Policy para que os controles globais (ex: baselines de segurança) sejam aplicados a cada nova assinatura automaticamente.

Defina o acesso base com RBAC

Ação: Em BusinessUnits, atribua a função Reader para a Auditoria, Owner para a equipe de plataforma central em CorpIT e Contributor para os administradores delegados das BUs em seus respectivos escopos. Crie uma função personalizada “Tag-Editor” que permita a ação

undefined

Por quê: O princípio do menor privilégio no escopo correto evita o excesso de permissões, ao mesmo tempo que permite a autonomia da BU; uma função personalizada evita conceder permissão de escrita completa para realizar a manutenção de tags.

Imponha a governança usando Policy e Blueprints

Ação: Crie uma iniciativa (initiative) que inclua políticas para locais permitidos, tags obrigatórias (CostCenter, Department, Environment), configurações de diagnóstico em serviços-chave e “Negar acesso público” (Deny public access) no armazenamento. Empacote-a em um Azure Blueprint com artefatos: a atribuição da iniciativa, atribuições de função RBAC, templates ARM para um workspace compartilhado do Log Analytics e um plano de DDoS, e um layout padrão de grupo de recursos. Atribua o blueprint a cada nova assinatura com bloqueios DoNotDelete nos recursos de base.
Por quê: Blueprints entregam uma landing zone versionada e repetível com bloqueios para prevenir exclusão acidental; a Policy garante que cada recurso esteja em conformidade na criação e remedia desvios (drift) através de DeployIfNotExists.

Aplique tags e garanta a herança

Ação: Use uma política de Modify para herdar tags dos grupos de recursos e uma política de Append para adicionar tags ausentes no momento da criação/atualização do recurso. Exija que os valores de CostCenter correspondam ao sistema financeiro da Starbucks.
Por quê: A herança nativa não é automática; a Policy garante que todos os recursos possuam os metadados necessários para relatórios de custos baseados em tags.

Configure o Cost Management e alertas

Ação: Crie orçamentos (budgets) no escopo de cada assinatura e grupo de recursos crítico, filtrados por tags quando apropriado, com alertas em 50/80/100% para um grupo de ação que aciona um Logic App para notificar os líderes da BU e, opcionalmente, reduzir a escala de recursos de Dev/test. Configure dashboards do Cost Analysis por tag e exporte os dados diariamente para o armazenamento.
Por quê: Orçamentos e alertas fornecem aviso prévio e acionam ações corretivas quase em tempo real; a dinamização por tags (tag pivots) permite um estorno de custos (chargeback) preciso.

Migre serviços compartilhados com segurança entre assinaturas

Ação: Valide o suporte à movimentação para os recursos de destino (VMs, managed disks, VNets, storage, Recovery Services vaults). Remova bloqueios impeditivos, garanta que os provedores de recursos (resource providers) estejam registrados na origem/destino, confirme a compatibilidade de região/SKU e agende uma janela de manutenção. Use a operação Move a partir do escopo do grupo de recursos para mover para a assinatura Corp-IT; revalide os diagnósticos e as políticas após a movimentação.
Por quê: Mover no limite do grupo de recursos preserva as dependências e minimiza o tempo de inatividade (downtime); as verificações prévias evitam falhas na movimentação devido a incompatibilidades de política ou de provedor.

Proteja recursos críticos com bloqueios (locks)

Ação: Aplique CanNotDelete aos recursos fundamentais de rede e monitoramento; aplique ReadOnly a um grupo de recursos de imagem de ouro (golden image).
Por quê: Os bloqueios (locks) se sobrepõem ao RBAC para prevenir a exclusão ou alteração acidental de ativos de base, permitindo operações normais em outros locais.

Otimize continuamente com o Advisor

Ação: Revise as recomendações do Advisor semanalmente; aceite as recomendações de custo para redimensionar (rightsize) VMs subutilizadas e comprar reservas para workloads estáveis; acompanhe o progresso com o Advisor Score.
Por quê: O Advisor operacionaliza a otimização contínua em custo, segurança, confiabilidade, desempenho e excelência operacional, sustentando a governança além da implantação inicial.

← Azure Active Directory e Gerenciamento de Identidade · Todos os domínios · Máquinas Virtuais do Azure e Computação →

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