AZ-104 — Módulo 02: Governança e Conformidade

• Uma região representa uma coleção de datacenters.
• Fornece flexibilidade e escala; ajuda a preservar a residência de dados (manter os dados dentro de um país/área específica).
• Selecione regiões próximas dos seus usuários — mas nem todo serviço está disponível em toda região (verificar disponibilidade de implantação).
• Há serviços globais que são independentes de região (ex.: Entra ID).
• Regiões são emparelhadas (region pairs) para alta disponibilidade — replicação entre um par protege contra falha regional.

• Só identidades no Entra ID (ou em diretório confiável pelo Entra ID) podem criar uma subscription.
• É a unidade lógica de serviços do Azure vinculada a uma conta do Azure.
• É um limite de segurança e de faturamento.

Como obter uma assinatura: clientes de Contrato Enterprise assumem compromisso monetário inicial; revendedores vendem de forma simples/flexível; parceiros projetam/implementam a solução; ou conta pessoal gratuita para começar na hora.

• Um recurso só pode existir em um único grupo de recursos por vez.
• Um grupo pode conter recursos de tipos e regiões diferentes.
• Grupos de recursos não podem ser renomeados nem aninhados.
• Recursos podem ser movidos entre grupos, entre subscriptions e até entre regiões.

• Recursos têm um limite padrão por subscription — a cota.
• Útil para acompanhar o uso atual e planejar o uso futuro.
• É possível abrir um caso de suporte gratuito para aumentar limites até os máximos publicados pela Microsoft.

• Fornecem um nível de escopo acima das subscriptions.
• Permitem aplicar políticas e orçamentos entre várias subscriptions de uma vez, com herança ao longo da hierarquia.
• Ajudam a organizar relatórios de conformidade e custos por organização (empresas/equipes).

• Fornecem metadados aos recursos do Azure.
• Organizam recursos logicamente, sem depender da estrutura de grupos de recursos.
• Consistem em um par nome-valor (ex.: Departamento: Marketing).
• Muito úteis para reunir informações de cobrança/custo por critério de negócio (departamento, ambiente, centro de custo).

Uma política do tipo "Append a tag and its value to resources" (modo Indexed) adiciona uma tag a recursos dentro do escopo — mas esse modo não avalia grupos de recursos nem assinaturas, só recursos individuais. Existe uma política diferente ("...to resource groups") para isso.

Quando um departamento usa recursos espalhados por vários grupos de recursos, a forma correta de isolar o custo por departamento é:

1. Atribuir uma tag a cada recurso (não ao grupo de recursos — já que os recursos de um departamento podem estar espalhados por vários RGs, a tag precisa estar no recurso individual).
2. Na blade Cost analysis, filtrar a exibição por tag.
3. Baixar o relatório de uso (usage report).

• Associe o lock a uma assinatura, grupo de recursos ou recurso (nunca a um Management Group).
• Locks são herdados pelos recursos filhos.
• Read-only impede qualquer alteração no recurso (nem escrita, nem exclusão).
• Delete impede apenas a exclusão — alterações continuam permitidas.

• Custos são específicos por recurso e podem variar entre regiões/locais.
• Custos de transferência de dados de entrada e saída diferem entre si.
• Instâncias reservadas do Azure — pré-pagar para reduzir custo de longo prazo.
• Benefício Híbrido do Azure — reutilizar licenças on-premises já pagas.
• Azure Advisor — recomendações de custo, incluindo identificar VMs subutilizadas que poderiam usar um SKU/tier mais barato.

• Serviço para criar, atribuir e gerenciar políticas.
• Executa avaliações/varreduras para identificar recursos fora de conformidade.
• Vantagens: imposição e conformidade, aplicar políticas em escala, remediação.

Casos de uso comuns: restringir tipos de recurso permitidos, restringir SKUs de VM permitidas, restringir locais/regiões permitidos, exigir uma tag e seu valor, auditar se o Backup do Azure está habilitado em todas as VMs.

• Uma iniciativa agrupa várias definições de política.
• Uma política pode ser atribuída em qualquer nível da hierarquia (Management Group, Subscription, Resource Group) e vale para tudo abaixo desse escopo — com exclusões pontuais possíveis (ex.: excluir só um recurso específico).
• O modo Indexed de uma política só avalia recursos que suportam tag+location — não avalia Resource Groups nem Subscriptions mesmo que eles suportem tags.

RBAC oferece gerenciamento de acesso mais refinado/granular. Existem roles internas (built-in) e é possível criar roles personalizadas (custom).

Uma role é uma coleção de permissões (Actions) que lista o que pode ser feito, e opcionalmente NotActions (o que é explicitamente removido de dentro de Actions).

"Actions": ["*"],
"NotActions": [
  "Microsoft.Authorization/*/Delete",
  "Microsoft.Authorization/*/Write",
  "Microsoft.Authorization/elevateAccess/Action"
],
"AssignableScopes": ["/"]

Esse é exatamente o papel Contributor: pode fazer qualquer coisa ("*"), exceto mexer em autorização/permissões (namespace Microsoft.Authorization).

Ao criar uma role personalizada, dois campos importantes:

• assignableScopes — define onde a role PODE ser atribuída (nela mesma ou em escopos abaixo). Não existe sintaxe genérica para "qualquer grupo de recursos" — seria preciso listar cada RG, então o escopo mais próximo do pedido "só pode ser atribuída a grupos de recursos" costuma ser o da assinatura (que permite atribuição nela e em tudo abaixo).
• notActions — remove permissões específicas do que está em actions. Para bloquear gerenciamento de permissões de acesso, usa-se o namespace Microsoft.Authorization/*.