Google ACE: Hierarquia de Recursos, IAM e Administração de Faturamento — Guia de estudos

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Faz parte do Google Associate Cloud Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A hierarquia de recursos, o gerenciamento de identidade e acesso (IAM) e a administração de faturamento formam o plano de controle das operações do Google Cloud. Um design resiliente começa com uma hierarquia clara (organização, pastas, projetos) para definir o escopo de políticas e responsabilidades; aplica o princípio de menor privilégio no IAM com administração centrada em grupos e credenciais de curta duração para cargas de trabalho; usa orçamentos, exportações e rótulos para atribuição de custos; e impõe a governança com políticas da organização e registro de auditoria abrangente. A excelência operacional vem da padronização da herança, da centralização do faturamento e dos logs e do uso da personificação de contas de serviço em vez de chaves de longa duração. Esta seção detalha as construções principais, seu uso pretendido e os modos de falha comuns a serem evitados.

Hierarquia de Recursos e Modelo de Identidade

• Hierarquia de recursos

  • Organização: Nó raiz, criado com o Cloud Identity ou Google Workspace. Detém as políticas globais (IAM, políticas da organização, tags).
  • Pastas: Agrupamento opcional para departamentos, ambientes (ex: dev, prod) ou aplicações. Útil para administração delegada e escopo de políticas.
  • Projetos: Fronteira administrativa para recursos, APIs, cotas, IAM e associação de faturamento. A maioria dos recursos do Google Cloud são filhos de projetos.
  • Herança: As políticas do IAM e as políticas da organização são herdadas de cima para baixo. Negações e restrições em níveis mais altos têm precedência. Planeje o posicionamento (organização → pastas → projetos) para minimizar exceções e necessidades de quebra de emergência (break-glass).

• Principais

  • Contas Google (usuários), grupos Google, contas de serviço e identidades externas via Workload Identity Federation.
  • Os grupos Google devem ser o principal alvo de vinculação para acesso humano, a fim de simplificar as mudanças no ciclo de vida e as revisões.
  • Contas de serviço representam aplicações ou serviços; prefira a identidade da carga de trabalho (workload identity) em vez de chaves.

• Identidades de carga de trabalho (Workload identities)

  • No Google Cloud: GCE/GAE/Cloud Run/GKE usam o servidor de metadados para emitir tokens de curta duração para a conta de serviço anexada.
  • Fora do Google Cloud: O Workload Identity Federation mapeia identidades externas (OIDC/SAML/AWS) para contas de serviço sem chaves estáticas.

• Trade-offs de design e modos de falha

  • A proliferação de projetos sem uma estrutura de pastas causa duplicação e desvio (drift) de políticas.
  • Conceder papéis diretamente a usuários aumenta o trabalho manual; prefira vinculações baseadas em grupos.
  • Usar a conta de serviço padrão do Compute Engine com permissões amplas eleva o risco; crie contas de serviço com o menor privilégio possível por carga de trabalho.
  • Posicionar um projeto na pasta errada faz com que ele herde políticas incorretas; use tags ou mova projetos com cuidado e com controle de mudanças.

Papéis do IAM e Design de Políticas

• Tipos de papéis

  • Papéis básicos (Visualizador, Editor, Proprietário): Amplos, legados. Evite, exceto para quebra de emergência (break-glass) rigidamente controlada.
  • Papéis predefinidos: Selecionados por serviço; prefira para a maioria dos casos de uso.
  • Papéis personalizados: Agregação de permissões no escopo da organização ou do projeto para necessidades específicas.
  • Papéis condicionais: As Condições do IAM (CEL) adicionam contexto como nome do recurso, pasta, tags ou tempo; use para restringir papéis poderosos.

• Princípios de política

  • Menor privilégio: Conceda apenas o papel mínimo no escopo mais restrito (recurso/projeto/pasta).
  • Separação de funções: Divida as responsabilidades (ex: administrador de rede vs. administrador de segurança vs. administrador de faturamento). Não acople ações de implantação e aprovação em um único principal.
  • Consciência da herança: Uma vinculação no nível da organização/pasta afeta todos os descendentes; documente o raio de impacto (blast radius) pretendido antes de aplicar.

• Políticas de negação (Deny)

  • O IAM Deny bloqueia explicitamente permissões, mesmo que concedidas em outro lugar; use para criar barreiras de proteção (guardrails) (ex: negar iam.serviceAccountKeys.create).
  • A negação (Deny) tem precedência; garanta processos de quebra de emergência (break-glass) documentados com exceções de tempo limitado.

• Exemplos

  • Copiar um papel personalizado de dev para prod:

undefined

• Conceder acesso de administrador SSH baseado em grupo com o OS Login:

undefined

• Modos de falha
  • O papel de Editor concedido na organização ou em uma pasta se propaga não intencionalmente para todos os projetos.
  • Papéis condicionais com condições excessivamente restritas podem quebrar automações silenciosamente; teste com o Policy Troubleshooter antes da implementação.
  • Papéis personalizados ficam defasados em relação a novas permissões; revise-os periodicamente.

Faturamento e Administração de Custos

• Contas de faturamento e associação

  • Um projeto deve estar vinculado a exatamente uma conta de faturamento para usar serviços faturáveis.
  • Papéis: O Administrador da conta de faturamento gerencia a conta e os métodos de pagamento; o Usuário da conta de faturamento vincula projetos; o Gerente de faturamento do projeto gerencia o vínculo de faturamento de um projeto.
  • Centralize em uma conta de faturamento corporativa; migre projetos atualizando a associação de faturamento do projeto.

• Orçamentos, alertas e atribuição

  • Orçamentos geram alertas, não limites de gastos. Use correção programática com o Pub/Sub e o Cloud Functions/Cloud Run se a imposição de limites for necessária.
  • Exporte os dados de faturamento para o BigQuery para análise e previsão de custos diária/mensal; combine com rótulos e tags de recursos para atribuição.
  • Rótulos e tags: Padronize as chaves (ex: cost_center, env, app). A falta de rótulos reduz a precisão da atribuição.

• Análise de custos

  • Use a exportação para o BigQuery para calcular previsões contínuas por SKU/serviço com SQL. Junte com metadados de recursos (ex: rótulos do GCE) para relatórios granulares.
  • Para análise multiprojeto, agregue todas as exportações de projetos ou exporte para um único conjunto de dados central.

• Armadilhas comuns

  • Orçamentos não configurados para novos projetos; estabeleça uma política para criar orçamentos automaticamente na criação de projetos.
  • A ausência de exportação para o BigQuery significa uma visão histórica limitada; habilite-a cedo para construir um histórico.
  • Cartões de crédito pessoais em projetos fragmentam a responsabilidade; consolide sob a conta de faturamento corporativa com perfis de pagamento e IAM apropriados.
  • Anomalias de custo em projetos de serviços compartilhados exigem o uso de tags e uma política de cobrança cruzada (cross-charging).

Governança, Políticas da Organização, Auditoria e Solução de Problemas

• Políticas e restrições da Organização

  • Aplicar barreiras de proteção (guardrails) usando restrições: proibir IPs externos em VMs, restringir regiões, impedir a criação de chaves, restringir os serviços permitidos, exigir acesso uniforme no nível do bucket, restringir o compartilhamento de domínios.
  • Direcionar pela hierarquia de recursos e refinar com tags para exceções específicas do ambiente.

• Cloud Identity e ciclo de vida

  • O Cloud Identity fornece o diretório de usuários, SSO e funções administrativas. Delegue de forma restrita (ex: Group Admin, User Management Admin) e automatize fluxos de trabalho de entrada, movimentação e saída (joiner-mover-leaver) para atualizar a associação a grupos e o acesso.
  • Use o Access Approvals e o Access Transparency para ambientes sensíveis.

• Logs de auditoria

  • Os logs de Admin Activity e System Event estão sempre ativados; os logs de Data Access precisam ser habilitados explicitamente e podem gerar custos.
  • Centralize roteando coletores agregados (aggregated sinks) de pastas/organização para um projeto de segurança. Proteja com CMEK e acesso restrito.
  • Monitore os logs de Policy Denied para detectar conflitos de políticas da organização.

• Kit de ferramentas para solução de problemas em múltiplos projetos

  • Policy Troubleshooter: Diagnostique por que o acesso é permitido ou negado, considerando as políticas de IAM e de negação (denies) efetivas.
  • Cloud Asset Inventory: Consulte vinculações (bindings) de IAM e histórico de políticas em toda a organização/pastas/projetos. Exemplo:

undefined

• Logs Explorer: Filtre por principal, método e recurso para rastrear ações entre projetos.
• Configurações do gcloud para troca de contexto do operador:

undefined

• Modos de falha comuns: políticas da organização conflitantes bloqueando implantações, falta de logs de Data Access dificultando investigações e permissões de IAM concedidas no escopo errado. Estabeleça runbooks e pré-visualizações pré-mudança para reduzir o MTTR de incidentes.

Cenário de Problema Prático

A Aurelia Retail está consolidando várias equipes e projetos após uma aquisição. Eles precisam centralizar o faturamento, impor uma administração consistente de IAM e SSH em centenas de VMs do Compute Engine e estabelecer governança com o mínimo de interrupção.

1. Criar uma conta de faturamento corporativa e vincular projetos

• Justificativa: Uma única conta de faturamento centraliza métodos de pagamento, créditos e orçamentos. Conceda a permissão Billing Account User a um grupo de migração de projetos e Project Billing Manager aos líderes de equipe para revincular os projetos sem conceder privilégios excessivos.
• Ação: No console, crie a conta de faturamento. Para cada projeto, atualize sua associação de faturamento. Habilite imediatamente a exportação do Faturamento (Billing) para o BigQuery em um projeto central de análise.

2. Padronizar a hierarquia de recursos com pastas e tags

• Justificativa: Colocar projetos sob pastas de ambiente (prod, nonprod) permite a herança de barreiras de proteção (guardrails) e exceções direcionadas. As tags permitem o direcionamento refinado de políticas da organização sem duplicar as árvores de pastas.
• Ação: Crie pastas para prod e nonprod; mova os projetos para elas. Defina tags como env=prod|nonprod e identificadores de aplicação.

3. Implementar IAM baseado em grupos com o princípio do menor privilégio e separação de funções

• Justificativa: Grupos simplificam o ciclo de vida e a auditoria. Dividir as funções entre equipes de implantação, segurança e administradores de rede reduz o raio de impacto (blast radius).
• Ação: Crie grupos do Google para app-operators, net-admins, sec-admins e billing-managers. Vincule papéis predefinidos no escopo da pasta/projeto conforme necessário; evite papéis básicos.

4. Impor a administração de SSH baseada no OS Login

• Justificativa: Chaves SSH individuais vinculadas a contas de usuário fornecem acesso atribuível e revogável. Os papéis do OS Login gerenciam contas Linux via IAM, eliminando chaves compartilhadas.
• Ação: Em cada projeto, habilite os metadados do OS Login. Conceda o papel compute.osAdminLogin ao grupo ops-admins. Exemplo:

undefined

5. Substituir chaves de conta de serviço por personificação (impersonation)

• Justificativa: Credenciais de curta duração mitigam o risco de exfiltração de chaves e simplificam a rotação. Os logs de auditoria capturam quem personificou quem, melhorando a rastreabilidade.
• Ação: Conceda o papel roles/iam.serviceAccountTokenCreator às identidades dos executores de CI/CD nas contas de serviço das cargas de trabalho. Remova as chaves gerenciadas pelo usuário e aplique uma política da organização para bloquear novas chaves.

6. Aplicar políticas da organização como barreiras de proteção (guardrails)

• Justificativa: As restrições (constraints) previnem configurações de risco em todos os projetos, permitindo exceções baseadas em tags quando justificadas.
• Ação: Aplique restrições para proibir IPs externos em produção, restringir regiões a locais aprovados e desabilitar a criação de chaves de conta de serviço. Use tags para permitir exceções para projetos específicos com aprovações documentadas.

7. Estabelecer governança de custos

• Justificativa: Orçamentos (budgets) alertam os proprietários antes de gastos excessivos; a exportação para o BigQuery permite atribuição e previsão. Rótulos (labels) e tags mapeiam os gastos com recursos para centros de custo.
• Ação: Crie orçamentos por pasta e por aplicação principal com notificações via Pub/Sub. Imponha políticas de rótulos por meio de modelos de implantação e validação de políticas no CI.

8. Centralizar a auditoria e acelerar a solução de problemas

• Justificativa: A centralização de logs e o inventário de ativos (asset inventory) em toda a organização aceleram investigações e relatórios de conformidade.
• Ação: Crie coletores agregados (aggregated sinks) para um projeto de segurança com buckets protegidos por CMEK. Habilite os logs de Data Access para serviços críticos (Cloud Storage, BigQuery). Use o Cloud Asset Inventory para escanear rotineiramente as vinculações de IAM. Treine os operadores para usar o Policy Troubleshooter quando o acesso falhar e o Logs Explorer para rastrear Admin Activity/Data Access.

9. Operacionalizar mudanças com pré-visualizações e implementação em fases (staged rollout)

• Justificativa: Validar os efeitos do IAM e das políticas antes de aplicá-los reduz interrupções.
• Ação: Teste as políticas de IAM e da organização primeiro em ambiente de não produção (nonprod). Use execuções de simulação (dry-runs) e simulação de políticas onde disponível. Para automação de implantação, implemente canaries e planos de reversão (backout).

Essa abordagem resulta em faturamento e visibilidade de custos centralizados, administração de SSH atribuível via OS Login, IAM com princípio do menor privilégio usando personificação, controles preventivos fortes por meio de políticas da organização e uma auditoria e solução de problemas robustas em todo o novo ambiente multiprojeto.

Todos os domínios · Compute Engine e Operações de Máquinas Virtuais →

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

Navegar Google →