Microsoft AZ-900: Governança e Conformidade — 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 governança no Azure alinha o uso da nuvem com os requisitos de negócios, segurança e regulatórios por meio de um conjunto de controles em camadas: estrutura organizacional, políticas, implantações padronizadas, proteção contra alterações acidentais e auditoria contínua. Esses recursos operam nativamente no plano de controle do Azure Resource Manager e escalam de uma única assinatura para grandes ambientes multilocatários (multi-tenant). Uma boa governança reduz o desvio de configuração (drift), impõe consistência e fornece evidências de conformidade sem impedir a velocidade do desenvolvedor. A conformidade depende de um inventário robusto e de um histórico de alterações. O Azure fornece visibilidade quase em tempo real dos recursos entre assinaturas, mapeamentos regulatórios prescritivos e descoberta de dados para localizar e classificar informações confidenciais. O resultado é uma postura de nuvem defensável, onde os padrões são definidos uma vez, aplicados automaticamente, evidenciados continuamente e corrigidos em escala.

Azure Policy: definições, iniciativas, controles de localização e remediação

O Azure Policy define barreiras de proteção (guardrails) que avaliam as configurações dos recursos durante a criação/atualização (e regularmente depois disso) e impõem os estados desejados. Uma definição de política usa condições e efeitos para avaliar as propriedades dos recursos expostas pelos provedores de recursos. Os efeitos principais incluem Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists e Disabled. As políticas podem ser atribuídas no escopo do grupo de gerenciamento, assinatura, grupo de recursos ou recurso, e a herança garante que as atribuições mais amplas sejam aplicadas aos níveis inferiores, a menos que sejam excluídas via notScopes. As iniciativas (Initiatives) agrupam definições de políticas relacionadas em um único pacote com parâmetros para uma atribuição consistente e repetível. Por exemplo, uma iniciativa de linha de base de segurança pode incluir políticas que exigem configurações de diagnóstico, restringem endpoints públicos, impõem o uso de tags e auditam a falta de backup. A atribuição da iniciativa aplica todas as políticas incluídas com uma única ação e resulta em uma única visão de conformidade. As políticas internas (built-in) de “Localizações permitidas” (Allowed locations) restringem onde os grupos de recursos e os recursos podem ser criados, impedindo a implantação em regiões não aprovadas e ajudando com a residência e soberania dos dados. Quando uma solicitação de criação tem como alvo uma região proibida, o efeito Deny bloqueia a operação antes que ela chegue ao provedor de recursos, garantindo conformidade estrita. Quando um desvio (drift) é descoberto, as tarefas de remediação restauram a conformidade dos recursos em escala. Para as políticas DeployIfNotExists e Modify, a identidade gerenciada (managed identity) de uma atribuição de política é usada para reconfigurar recursos não conformes (por exemplo, habilitando configurações de diagnóstico em contas de armazenamento ou anexando as tags necessárias). Os trabalhos de remediação podem ter um escopo restrito ou serem executados em assinaturas inteiras, e os resultados de conformidade são apresentados por política e por recurso para rastreamento de auditoria.

• Finalidade
  • Definição de Política (Policy Definition): Regra única que avalia as propriedades do recurso
  • Iniciativa (Policy Set): Pacote de definições de políticas com parâmetros compartilhados
  • Escopo de Atribuição: Grupo de gerenciamento, assinatura, grupo de recursos ou recurso
  • Efeitos Comuns: Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists
  • Requisitos de Remediação: Identidade gerenciada na atribuição; aplicável a Modify/DeployIfNotExists
• Caso de uso
  • Definição de Política (Policy Definition): Impor SKU, TLS, tags, endpoints privados
  • Iniciativa (Policy Set): Aplicar uma linha de base de segurança ou governança
  • Escopo de Atribuição: Aplicação ampla com herança e exclusões
  • Efeitos Comuns: Aplicação rigorosa (hard enforcement) ou auditoria apenas para evidência
  • Requisitos de Remediação: Permissões suficientes para alterar os recursos de destino

Azure Blueprints: empacotando padrões com políticas, RBAC, grupos de recursos e modelos

O Azure Blueprints empacota artefatos de governança para que as organizações possam criar (stamp) ambientes em conformidade de forma consistente. Uma definição de blueprint pode incluir atribuições de políticas, atribuições de controle de acesso baseado em função (RBAC) do Azure, definições de grupos de recursos e artefatos de implantação, como modelos ARM (incluindo Bicep) para provisionar infraestrutura padrão. Os parâmetros permitem a personalização por atribuição, preservando uma única fonte de verdade versionada. Os Blueprints ajudam a separar “o que deve existir e quem pode fazer o quê” do código da carga de trabalho (workload). Por exemplo, um blueprint de linha de base pode criar grupos de recursos spoke, atribuir a função Reader para equipes de auditoria e Contributor para equipes de plataforma, implantar um modelo de rede hub-and-spoke e atribuir iniciativas para diagnóstico e segurança. A atribuição do blueprint a uma ou mais assinaturas aplica todos os artefatos na ordem correta e registra o estado de conformidade. O versionamento suporta atualizações controladas, e o bloqueio de artefatos (artifact locking) pode proteger componentes críticos após a implantação.

• Foco principal
  • Azure Policy: Barreiras de proteção (guardrails) de configuração e conformidade
  • Modelos ARM/Bicep: Implantação declarativa de recursos
  • Azure Blueprints: Empacotamento e governança de padrões entre assinaturas
• Inclui RBAC
  • Azure Policy: Não (atribuição separada)
  • Modelos ARM/Bicep: Não (atribuição separada)
  • Azure Blueprints: Sim (atribuições de função como artefatos)
• Inclui Política
  • Azure Policy: N/A
  • Modelos ARM/Bicep: Não (pode implantar recursos de política, mas não atribuí-los)
  • Azure Blueprints: Sim (atribuições de política como artefatos)
• Cria Grupos de Recursos
  • Azure Policy: Pode exigir/impor nomenclatura/tags
  • Modelos ARM/Bicep: Pode implantar dentro de ou criar via implantações aninhadas (nested deployments)
  • Azure Blueprints: Sim (define artefatos de RG como parte do blueprint)
• Uso típico
  • Azure Policy: Restringir SKUs, impor diagnósticos, tags
  • Modelos ARM/Bicep: Provisionar VNets, Key Vaults, App Services
  • Azure Blueprints: Criar (stamp) landing zones em conformidade com política + RBAC + infraestrutura

Organização e padrões: grupos de gerenciamento, assinaturas, grupos de recursos, nomenclatura e tags

A hierarquia de gerenciamento do Azure permite que a governança seja escalável. Os grupos de gerenciamento (management groups) ficam acima das assinaturas (subscriptions) e fornecem um local para aplicar políticas (policy) e RBAC que são herdados por todas as assinaturas filhas. As assinaturas definem o faturamento, as cotas de serviço e um limite de segurança para a maioria dos controles. Os grupos de recursos (resource groups) contêm recursos com ciclo de vida, permissões e lógica de implantação alinhados; cada recurso pertence a exatamente um grupo de recursos e uma assinatura. Padrões de nomenclatura e marcação (tagging) traduzem a intenção da governança em clareza operacional. Os nomes devem codificar abreviações do tipo de recurso, carga de trabalho (workload), ambiente e região (por exemplo, kv-payroll-prod-eus2) dentro dos limites do serviço. As tags adicionam contexto de negócios aos recursos para alocação de custos, propriedade, classificação de dados e chaves de automação (por exemplo, costCenter=FIN, owner=ops-team@contoso.com, dataSensitivity=Confidential). O Azure Policy com os efeitos Modify e Append impõe a presença de tags e padrões de valor, e pode herdar tags de grupos de recursos para os recursos. A consistência aqui impulsiona relatórios de custos confiáveis, revisões de acesso e automação do ciclo de vida.

• Grupo de Gerenciamento (Management Group)
  • Propósito: Governar em escala entre assinaturas
  • Usos Comuns: Aplicar políticas, RBAC e iniciativas a unidades de negócios ou ambientes
  • Pode Conter: Grupos de gerenciamento filhos e assinaturas
  • Observações Importantes: Até 6 níveis de profundidade (excluindo a raiz); a herança flui para baixo
• Assinatura (Subscription)
  • Propósito: Limite de faturamento e de serviço
  • Usos Comuns: Isolamento de workloads, segregação de custos, gerenciamento de cotas
  • Pode Conter: Grupos de recursos e recursos
  • Observações Importantes: Atribuições de Policy/RBAC aqui afetam todos os grupos de recursos contidos
• Grupo de Recursos (Resource Group)
  • Propósito: Limite de ciclo de vida e permissão para recursos
  • Usos Comuns: Implantar, atualizar e excluir recursos relacionados em conjunto
  • Pode Conter: Recursos
  • Observações Importantes: Um recurso pode existir em apenas um RG; movimentações entre RGs/assinaturas têm restrições específicas do serviço

Bloqueios de recursos e prevenção de exclusão acidental

Os bloqueios de recursos (resource locks) fornecem uma última linha de defesa contra alterações não intencionais. Os bloqueios são aplicados no escopo da assinatura, do grupo de recursos ou do recurso e são herdados para os níveis inferiores. Existem dois tipos de bloqueio: CanNotDelete impede a exclusão, mas permite operações de leitura e gravação, e ReadOnly restringe todas as operações de gravação e exclusão (permitindo efetivamente apenas operações de leitura). Os bloqueios protegem contra ações do portal, CLI, PowerShell, ARM/Bicep e ferramentas de IaC de terceiros. Use CanNotDelete em infraestrutura crítica ou compartilhada — redes virtuais, tabelas de rotas, zonas de DNS, Key Vaults de produção — para que a manutenção possa continuar enquanto as exclusões estão bloqueadas. Use ReadOnly com moderação para artefatos que devem permanecer completamente estáticos, como contas de armazenamento arquivadas ou contêineres de evidências regulatórias; muitos serviços exigem operações de gravação para seu funcionamento normal e falharão sob um bloqueio ReadOnly. Apenas entidades de segurança (principals) com permissões suficientes (por exemplo, Owner com Microsoft.Authorization/locks/*) podem remover um bloqueio, e a remoção de um bloqueio é, por si só, uma operação auditável no Activity Log.

• CanNotDelete
  • Leituras: Permitidas
  • Gravações/Atualizações: Permitidas
  • Exclusões: Bloqueadas
  • Casos de Uso Típicos: Proteger VNets, tabelas de rotas, Key Vaults de produção, RGs críticos
  • Considerações: Permite alterações de configuração; operações de exclusão falham até que o bloqueio seja removido
• ReadOnly
  • Leituras: Permitidas
  • Gravações/Atualizações: Bloqueadas
  • Exclusões: Bloqueadas
  • Casos de Uso Típicos: Preservar armazenamentos de evidências, armazenamento de arquivamento, configurações imutáveis
  • Considerações: Muitos serviços não funcionam corretamente com ReadOnly; atualizações e escalonamento são bloqueados

Auditoria, inventário e conformidade regulatória: Resource Graph, Activity Log, Defender for Cloud e Microsoft Purview

O Azure Resource Graph fornece consultas rápidas e em escala de inventário e postura em assinaturas e grupos de gerenciamento usando a Kusto Query Language (KQL). Ele permite responder a perguntas como quais contas de armazenamento não têm criptografia, quais VNets expõem IPs públicos e quais recursos estão fora da política. Os resultados alimentam painéis, sincronização de CMDB e pipelines de remediação. O Resource Graph também pode revelar estados de conformidade de políticas, distribuições de tags e dimensões de atribuição de custos quando combinado com dados do Cost Management. O Azure Activity Log registra operações do plano de controle em recursos, incluindo quem fez o quê e quando, com uma retenção padrão de 90 dias. Encaminhe o Activity Log para o Log Analytics, Azure Storage ou Event Hubs para retenção de longo prazo, correlação e ingestão em SIEM. A análise do histórico de alterações identifica desvios de configuração, apoia a resposta a incidentes e fornece evidências para auditorias. O Microsoft Defender for Cloud traduz a postura técnica em visões regulatórias, mapeando avaliações para padrões como Azure Security Benchmark, ISO/IEC 27001, NIST SP 800-53, PCI DSS e CIS. O painel de conformidade regulatória mostra os controles aprovados/reprovados, os recursos afetados e as orientações de remediação. Habilitar o provisionamento automático integra agentes e políticas onde necessário, e a pontuação de segurança (secure score) oferece uma lente de priorização. O Microsoft Purview descobre, classifica e cataloga dados em fontes do Azure, multinuvem e locais (on-premises). As varreduras identificam dados confidenciais (por exemplo, financeiros, PII, de saúde) no Azure Storage, SQL, Synapse, Power BI e muitos outros, aplicando classificadores integrados ou personalizados. O Mapa de Dados (Data Map) e o Catálogo (Catalog) do Purview fornecem linhagem, propriedade e rotulagem de sensibilidade que se integram ao Microsoft Information Protection, permitindo a prevenção contra perda de dados e decisões de política de acesso alinhadas com as obrigações regulatórias.

• Função principal
  • Azure Resource Graph: Consultas de inventário e postura em escala
  • Activity Log: Trilha de auditoria do plano de controle de operações
  • Defender for Cloud (Regulatório): Mapear a postura para padrões e priorizar correções
  • Microsoft Purview: Descoberta, classificação, catálogo e linhagem de dados
• Escopo
  • Azure Resource Graph: Entre MGs/assinaturas
  • Activity Log: Por locatário (tenant) com roteamento para LA/Storage/Event Hub
  • Defender for Cloud (Regulatório): Por assinatura/locatário (tenant) com atribuições de iniciativa
  • Microsoft Purview: Entre fontes de dados (Azure, M365, local, multinuvem)
• Saídas típicas
  • Azure Resource Graph: Resultados de consulta KQL, painéis, exportações
  • Activity Log: Quem/o quê/quando, status, códigos de erro
  • Defender for Cloud (Regulatório): Status de conformidade do controle, pontuação de segurança (secure score), recomendações
  • Microsoft Purview: Ativos de dados, rótulos de sensibilidade, esquema, grafos de linhagem

Problema Prático: Padronizando landing zones em conformidade no Fabrikam Retail Group

Cenário: O Fabrikam Retail Group opera na América do Norte e na UE com obrigações rigorosas de residência de dados e PCI DSS. Várias equipes de aplicação implantam cargas de trabalho (workloads) mensalmente, e implantações ad-hoc anteriores levaram a um etiquetamento (tagging) inconsistente, recursos em regiões não aprovadas e à exclusão ocasional de redes compartilhadas. A liderança exige landing zones padronizadas e em conformidade, evidência contínua da eficácia dos controles e a descoberta de dados sensíveis em plataformas de armazenamento e análise (analytics).

Desafio: Projetar e implementar uma abordagem de governança do Azure que imponha restrições de região, padronize as implantações com políticas (policy) e RBAC, evite a exclusão acidental da infraestrutura principal, mantenha o inventário e o histórico de alterações, gere relatórios em conformidade com a ISO 27001 e o PCI DSS, e descubra/classifique dados sensíveis.

Abordagem Recomendada:

1. Crie uma hierarquia de grupos de gerenciamento (management groups): raiz /Fabrikam; filhos /Corp (serviços compartilhados), /NA e /EU; sob cada um, adicione /Prod e /NonProd. Mova as assinaturas (subscriptions) para os grupos de gerenciamento apropriados.
2. Crie iniciativas de política (policy initiatives) no nível do grupo de gerenciamento: (a) Localizações permitidas por geografia, (b) Tags obrigatórias (costCenter, owner, dataSensitivity) com Modify/Append, (c) Imponha configurações de diagnóstico para o Log Analytics para serviços principais, (d) Restrições de SKU e de rede pública para serviços PaaS. Atribua as iniciativas a /NA e /EU com parâmetros apropriados para cada região e exclua as assinaturas de quebra de emergência (break-glass) via notScopes.
3. Empacote um blueprint para a landing zone padrão: os artefatos incluem a criação de grupos de recursos (resource groups) de hub e de aplicação, atribuições de RBAC (Network Contributor para a equipe de plataforma, Reader para a auditoria), atribuições de política para diagnósticos e tags, e templates ARM para implantar vNETs, peering, Key Vault e Log Analytics. Versione o blueprint e atribua-o a todas as assinaturas Prod e NonProd.
4. Aplique bloqueios de recursos (resource locks): CanNotDelete nas vNETs de hub, tabelas de rotas (route tables), zonas de DNS compartilhadas e workspaces do Log Analytics; ReadOnly em uma conta de armazenamento de arquivamento para exportações regulatórias. Valide que os Owners das assinaturas de serviços compartilhados podem remover os bloqueios com as devidas aprovações quando as alterações são planejadas.
5. Habilite a exportação do Activity Log de todas as assinaturas para um workspace central do Log Analytics e arquive em uma conta de armazenamento com retenção imutável (baseada em tempo) por sete anos. Crie dashboards do Resource Graph que listem recursos não conformes, tags ausentes e ativos por região e pela tag dataSensitivity.
6. Habilite o Microsoft Defender for Cloud em todo o tenant. Selecione ISO/IEC 27001 e PCI DSS como padrões regulatórios, ative o provisionamento automático (auto-provisioning) e revise as recomendações. Crie itens de trabalho (work items) a partir de descobertas de alta severidade e acompanhe as melhorias do secure score por assinatura.
7. Implante o Microsoft Purview na assinatura de serviços compartilhados /Corp. Registre Azure SQL, Storage, Synapse e Power BI como fontes de dados (data sources). Configure varreduras agendadas com tipos de informações sensíveis integrados e classifique os conjuntos de dados (datasets). Publique o catálogo de dados e atribua proprietários de dados (data owners). Exporte os rótulos de sensibilidade descobertos para informar o acesso condicional e o DLP.

Justificativa para o Azure: Esta abordagem começa com o escopo de grupos de gerenciamento para que as políticas e o RBAC sejam herdados de forma previsível, e em seguida, impõe controles essenciais com o Azure Policy e iniciativas para prevenir a não conformidade no momento da implantação. O blueprint empacota políticas, RBAC, grupos de recursos e templates de infraestrutura para carimbar landing zones consistentes, ao mesmo tempo que permite a parametrização por região e ambiente. Os bloqueios de recursos (Resource locks) protegem serviços compartilhados críticos contra exclusão acidental, sem impedir a configuração do dia a dia quando apropriado. A retenção centralizada do Activity Log e o Resource Graph fornecem um inventário confiável e evidências de alterações. O Defender for Cloud fornece um mapa de controle regulatório em tempo real e remediação priorizada, enquanto o Microsoft Purview descobre e classifica dados sensíveis para dar suporte aos controles de PCI DSS e residência de dados em todo o patrimônio de análise (analytics estate) da Fabrikam.

← Gerenciamento de Custos e Economia de Serviços · Todos os domínios · Monitoramento →

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

Navegar Microsoft →