Google PCA: Design Organizacional, IAM e Governança de Nuvem — Guia de estudos

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Visão Geral

O design da organização, o IAM e a governança estabelecem a base sobre a qual todas as arquiteturas do Google Cloud são executadas. Bons designs criam limites administrativos claros, minimizam o raio de impacto, habilitam o princípio do menor privilégio, controlam custos e escalam operacionalmente entre várias equipes e ambientes. A governança deve enfatizar trilhos de proteção em vez de portões: automatize padrões que sejam seguros, mensuráveis e reversíveis, enquanto delega o controle do dia a dia para as equipes mais próximas da carga de trabalho.

Hierarquia de Recursos e Fundamentos de Identidade

Os recursos do Google Cloud formam uma árvore hierárquica estrita: Organização → Pastas → Projetos → Recursos (por exemplo, instâncias do Compute Engine, buckets). As políticas do IAM e as restrições da Política da Organização são herdadas ao longo da árvore.

Princípios chave de design:

• Use uma única Organização para centralizar a governança. Crie Pastas de nível superior para os principais limites administrativos (por exemplo, unidades de negócio, regiões ou ambientes regulamentados vs. não regulamentados).
• Dentro de cada limite, crie Pastas de ambiente (produção, não produção) para aplicar políticas diferenciadas. Mantenha os projetos com escopo de carga de trabalho e efêmeros sempre que possível para reduzir o raio de impacto e facilitar o estorno de custos (chargeback).
• Herança: as concessões de permissão se acumulam (união das vinculações de permissão dos ancestrais e do nó). As políticas de negação (Deny) do IAM, se usadas, têm precedência e podem bloquear o acesso mesmo que uma permissão de concessão exista. Evite posicionar papéis amplos no topo da hierarquia; o raio de impacto é grande e difícil de reverter.

Fontes de identidade:

• O Cloud Identity é o plano de identidade da força de trabalho. Integre-o com seu IdP corporativo (SAML/OIDC) para centralizar a autenticação e o ciclo de vida (novos funcionários, movimentações e desligamentos). Use o Google Cloud Directory Sync para sincronização de atributos e grupos, se necessário.
• Grupos são os principais sujeitos (subjects) do IAM. O acesso baseado em grupos permite alterações escaláveis e propriedade auditável. Use um padrão de grupo de grupos (por exemplo, net-admins, sec-admins, app-team-A) e restrinja quem pode gerenciar a associação aos grupos.
• Contas de serviço (Service accounts) representam cargas de trabalho. Prefira a personificação de conta de serviço com credenciais de curta duração em vez de chaves armazenadas. Evite chaves de conta de serviço gerenciadas pelo usuário; trate-as como exceções com aprovações rigorosas e rotação.
• Padrões de identidade de carga de trabalho (Workload identity):
  • O GKE Workload Identity vincula contas de serviço do Kubernetes a contas de serviço do Google, eliminando credenciais em nível de nó.
  • O Workload Identity Federation permite que identidades externas (on-premise, outras nuvens, GitHub Actions) obtenham acesso de curta duração ao Google sem chaves. Use escopo de pool/provedor e condições de atributo para restringir o acesso.

Modos de falha comuns e mitigações:

• Conceder papéis primitivos (Proprietário/Editor/Visualizador) no nível de Pasta ou Organização leva a um excesso de privilégios generalizado. Use-os apenas em projetos de quebra de vidro (break-glass) com escopo restrito.
• A proliferação de grupos com propriedade incerta enfraquece o princípio do menor privilégio. Imponha padrões de nomenclatura, tags de propósito e metadados de proprietário nos grupos.
• Contas de serviço órfãs e vinculações obsoletas acumulam riscos. Agende revisões de acesso recorrentes e use o IAM Recommender para reduzir permissões não utilizadas.

Modelos do IAM, Papéis e Operações de Acesso

Papéis e vinculações (bindings):

• Papéis predefinidos são curados para serviços específicos e devem ser a escolha padrão.
• Papéis personalizados preenchem lacunas quando os papéis predefinidos são muito abrangentes. Construa-os a partir do conjunto mínimo de permissões observadas como necessárias; versione e teste-os.
• Papéis básicos (Visualizador/Editor/Proprietário) são legados e excessivamente amplos. Evite-os nos escopos de Organização e Pasta. Não use o papel de Proprietário (Owner) para operações diárias; reserve-o para situações de quebra de vidro (break-glass) da plataforma com controles compensatórios fortes.
• Vinculações de papéis condicionais (IAM Conditions) restringem quando e onde uma vinculação se aplica usando atributos como

undefined

,

undefined

,

undefined

ou

undefined

. Use condições para acesso com tempo limitado, acesso a produção com escopo de tag ou ações restritas por localização.

Menor privilégio e elevação de privilégios:

• Separe as responsabilidades de “leitura”, “operação” e “administração”. Por exemplo, as equipes de rede, segurança e aplicação recebem papéis distintos em escopos distintos.
• Use a elevação just-in-time com fluxos de trabalho do Access Approval ou automação orientada por tickets para vincular papéis com tempo limitado por meio de condições.

Políticas de negação (Deny) e riscos:

• O IAM Deny pode bloquear centralmente permissões arriscadas (por exemplo,

undefined

). A negação (Deny) sobrepõe a permissão de concessão (allow) e se aplica a toda a subárvore. Valide minuciosamente; negações mal configuradas podem bloquear a automação ou quebrar implantações.

Auditabilidade e revisões:

• Habilite os logs de Atividade do Administrador (Admin Activity logs) na Organização; eles são retidos por 400 dias por padrão. Para serviços sensíveis, habilite os logs de Acesso a Dados (Data Access logs) e encaminhe-os para o BigQuery para retenção de longo prazo e auditoria.
• Implemente revisões de acesso periódicas: enumere as vinculações com o Cloud Asset Inventory, compare com os registros de propriedade, remova papéis não utilizados sugeridos pelo IAM Recommender e verifique a expiração das exceções.

Exemplo útil (vinculação com escopo de tag e tempo limitado):

undefined

Governança Financeira e Guardrails da Política da Organização

Arquitetura de faturamento:

• Centralize uma ou mais contas de faturamento sob a responsabilidade do setor Financeiro. Use várias contas de faturamento apenas quando for legal ou operacionalmente necessário (por exemplo, entidades separadas ou modelos de revendedor).
• Vincule projetos a contas de faturamento por meio de automação; não permita a vinculação manual fora dos fluxos de trabalho aprovados.

Estorno (chargeback) e visibilidade de custos:

• Use labels e tags de alocação de custos de forma consistente. Labels são metadados de formato livre para filtragem e relatórios; tags são hierárquicas e utilizáveis em Condições e políticas do IAM. Habilite a alocação de custos para que as tags selecionadas apareçam nas exportações de faturamento.
• Exporte os dados de faturamento para o BigQuery para análise; crie dashboards por proprietário, centro de custo e ambiente. Exija que cada projeto tenha um proprietário responsável e um orçamento.

Orçamentos e detecção de anomalias:

• Crie orçamentos com alertas nos níveis de Pasta (Folder) e de projeto. Adicione reações programáticas (por exemplo, notificar o plantonista (on-call), abrir tickets ou desabilitar novos aumentos de cota) para conter gastos descontrolados.
• Use Cotas e compromissos (CUDs) alinhados ao uso esperado; monitore a utilização.

Restrições da Política da Organização (seguro por padrão):

• Aplique os guardrails no nível da Organização ou da Pasta e flexibilize-os apenas quando justificado. Restrições comuns:
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects restringindo imagens de VM
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• Use o VPC Service Controls para reduzir o risco de exfiltração de dados para serviços compatíveis em perímetros sensíveis.

Tratamento de exceções de política:

• As exceções devem ser solicitáveis, aprovadas, com prazo determinado e auditáveis. Prefira usar Condições do IAM para delimitar o escopo das exceções por tag/tempo. Reconcilie as exceções periodicamente e faça com que expirem automaticamente por meio de pipelines de política como código (policy-as-code).

Exemplo de Política da Organização (YAML) para desabilitar chaves de conta de serviço:

• name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
  • enforce: true Depois, aplique: gcloud org-policies set-policy policy.yaml

Landing Zones, Serviços Compartilhados, Automação e Modelos Operacionais

Landing zone:

• Fornece uma linha de base com segurança pré-configurada: Políticas da Organização, sinks de logs, estratégia de CMEK, VPCs compartilhadas (Shared VPCs), DNS privado, Cloud NAT, Private Service Connect, projetos de auditoria e segurança e catálogos de imagens restritos.
• Separe os projetos host por ambiente para a Shared VPC. Os administradores de rede controlam os projetos host; as equipes de aplicação fazem a implantação em projetos de serviço anexados ao host correto.

Fábrica de projetos:

• Automatize a criação de projetos com infraestrutura como código. Crie projetos de forma padronizada com:
  • Posicionamento correto na Pasta (Folder) e vínculo de faturamento
  • Grupos e papéis pré-vinculados
  • Contas de serviço padrão desativadas ou restritas
  • Sinks de logs para projetos centrais e buckets de retenção
  • Orçamentos, labels e tags predefinidos
• Use módulos do Terraform ou o Cloud Config Controller para codificar a fábrica. Force a validação de políticas no CI antes de aplicar as alterações.

Serviços compartilhados e isolamento:

• Centralize identidade, rede, CI/CD, registros de artefatos e ferramentas de segurança em projetos dedicados. Isole os ambientes por Pasta (Folder) e VPC; bloqueie o movimento lateral com políticas de firewall, perímetros de serviço separados e keyrings distintos do Cloud KMS por ambiente.
• Use o Private Service Connect e projetos produtores para publicar serviços compartilhados para consumidores sem expor endpoints públicos.

Logs de auditoria e automação da governança:

• Roteie os logs de Atividade do Administrador (Admin Activity) e Acesso a Dados (Data Access) para um projeto de auditoria. Configure os buckets de log com CMEK e políticas de retenção alinhadas à conformidade.
• Use feeds do Cloud Asset Inventory para o Pub/Sub, além do Cloud Functions/Cloud Run, para detectar desvios (drift) (por exemplo, buckets públicos) e remediar automaticamente ou abrir tickets.
• Pilha de política como código (Policy-as-code):
  • Políticas da Organização e IAM como código armazenados em um repositório
  • Config Validator/Policy Controller para recursos KRM
  • Verificações de política pré-implantação em CI/CD
  • Jobs de reconciliação agendados para reaplicar o estado desejado

Nomenclatura de recursos e tags:

• Imponha padrões de nomenclatura curtos e legíveis que codificam ambiente, aplicação, região e sequência (por exemplo, appA-prd-usw2-web-01). Reserve as tags para governança (env=prod, pii=true, owner=team-x). Valide a presença de labels/tags obrigatórios na criação do projeto.

Operações multitime e administração delegada:

• Estabeleça equipes de plataforma, segurança e rede com escopos e papéis claramente definidos. Delegue a administração no nível do projeto para as equipes de aplicação dentro dos limites de sua Pasta (Folder). Forneça autoatendimento dentro de limites de segurança (guardrails) por meio de catálogos e modelos.
• Equilibre autonomia versus risco, delegando decisões com baixo raio de impacto (blast radius) para as equipes e centralizando decisões que afetam muitos projetos ou a infraestrutura compartilhada.

Cenário de Problema Prático

A Contoso Retail planeja integrar oito equipes de produto ao Google Cloud em três meses. Cada equipe precisa de ambientes de produção e não produção, rede isolada, logs de segurança centralizados e responsabilidade de custos. A equipe de plataforma deve evitar a proliferação de chaves de contas de serviço, restringir imagens de VM e permitir acesso elevado com tempo limitado para resposta a incidentes.

Abordagem:

1. Estabelecer a hierarquia e as Pastas (Folders)

• Crie Pastas (Folders) de nível superior para departamentos e Pastas (Folders) aninhadas para produção e não produção. Justificativa: limites administrativos claros permitem limites de segurança (guardrails) e orçamentos direcionados, ao mesmo tempo que possibilitam a administração delegada às equipes de produto sem conceder poderes em toda a organização.

2. Implantar uma landing zone com Shared VPC

• Crie projetos host para as redes de produção e não produção, gerenciados pela equipe de rede. Anexe os projetos de serviço das equipes via Shared VPC. Justificativa: centraliza o roteamento, o NAT e a política de firewall, ao mesmo tempo que isola as cargas de trabalho por projeto; evita redes ad hoc que levam à proliferação e à segurança inconsistente.

3. Implementar limites de segurança (guardrails) com políticas da organização

• Imponha restrições: desative a criação de chaves de conta de serviço, exija o OS Login, restrinja IPs públicos para o Cloud SQL, restrinja imagens de VM a projetos confiáveis e habilite o acesso uniforme no nível do bucket. Justificativa: a segurança por padrão reduz configurações incorretas de alta frequência; exceções podem ter tempo limitado quando necessário.

4. Configurar identidade e grupos

• Integre o Cloud Identity com o IdP corporativo; crie grupos para os perfis de dev, ops e admin de cada equipe e grupos no nível da plataforma para administradores de rede e de segurança. Justificativa: o IAM baseado em grupos escala e se alinha com a separação de funções; o ciclo de vida segue os eventos de RH.

5. Definir o IAM com privilégio mínimo e elevação condicional

• Vincule papéis predefinidos a grupos no escopo de Pasta (Folder) ou projeto; habilite a elevação para resposta a incidentes por meio de vínculos condicionais (conditional bindings) limitados a recursos com a tag de produção e que expiram após 24 horas. Justificativa: privilégio mínimo para o dia a dia, com escalonamento seguro e auditável quando necessário.

6. Construir um pipeline de fábrica de projetos

• Use módulos do Terraform para criar projetos com os labels/tags obrigatórios (env, owner, cost-center), vincular o faturamento, anexar à Shared VPC correta, criar sinks de logs para um projeto de auditoria central e definir orçamentos. Justificativa: o provisionamento consistente, em conformidade e em escala elimina o desvio manual e acelera a integração.

7. Centralizar logs de auditoria e revisões de acesso

• Roteie os logs de Atividade do Administrador (Admin Activity) e Acesso a Dados (Data Access) para o BigQuery com CMEK; agende consultas mensais para enumerar os vínculos do IAM e comparar com a propriedade do grupo e os dados de último acesso do IAM Recommender. Justificativa: uma trilha de auditoria durável e o dimensionamento contínuo e correto do acesso reduzem o risco e o custo.

8. Governança de custos e alertas

• Habilite tags e labels de alocação de custos, exporte os dados de faturamento para o BigQuery e defina orçamentos por Pasta (Folder) e por projeto com notificações para as equipes financeiras e líderes de equipe. Justificativa: o chargeback transparente promove a responsabilidade; alertas antecipados controlam gastos descontrolados.

9. Workload Identity e automação sem chave

• Para o GKE, habilite o Workload Identity; para CI externo (GitHub), configure o Workload Identity Federation com escopo para repositórios específicos com condições. Justificativa: elimina chaves de longa duração e restringe o uso às cargas de trabalho pretendidas.

10. Processo de exceção e automação

• Implemente um fluxo de trabalho de solicitação que crie vínculos condicionais do IAM ou flexibilizações temporárias de política com expiração automática via CI. Justificativa: capacita as equipes sem sacrificar o controle; toda exceção tem tempo limitado e é auditável.

Resultados técnicos:

• As equipes provisionam novos projetos por autoatendimento em menos de 15 minutos com padrões em conformidade.
• Nenhuma chave de conta de serviço gerenciada pelo usuário é permitida; a elevação para resposta a incidentes tem tempo limitado e escopo definido por tag.
• Os custos são consolidados por equipe e ambiente, com orçamentos automatizados e alertas de anomalia.
• Os logs de auditoria e as revisões de acesso validam continuamente se as permissões e políticas correspondem à intenção.

Todos os domínios · Computação →

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

Navegar Google →