Última revisão: maio de 2026
Construa os serviços da AWS do exame AGWA com Terraform puro — um bloco de cada vez, cada um vinculado a um domínio do exame. O mesmo código funciona no OpenTofu.
Ao final deste laboratório, você terá provisionado, com Terraform puro, o substrato do lado do GCP que todo administrador do Google Workspace deve entender — a API Cloud Identity habilitada, um grupo IAM criado no escopo do projeto, o grupo vinculado a uma função de visualizador e um sink do Cloud Audit Logs roteando eventos de auditoria em nível de organização para um bucket de registro dedicado. Quatro blocos; o limite do Cloud Identity + Audit Logs que o exame AGWA testa.
Solte os trechos em um único main.tf, execute terraform init, depois terraform apply passo a passo.
Nota: a maior parte do conteúdo do exame AGWA reside no console de administração do Workspace (roteamento do Gmail, políticas de compartilhamento do Drive, gerenciamento de dispositivos móveis, acesso adaptativo ao contexto), que não é diretamente Terraformável através do provedor google. O provedor googleworkspace existe, mas requer uma conta de serviço de superadministrador do Workspace com delegação em todo o domínio — fora do escopo para um laboratório.
>= 1.5 ou OpenTofu >= 1.6.your-project-id e your-org-id nos trechos abaixo.Tudo gratuito no escopo do laboratório:
O produto Workspace em si é cobrado por assento (~$6/usuário/mês para Business Starter, até ~$30/usuário/mês para Enterprise) — fora do escopo do laboratório. O substrato abaixo é gratuito.
Habilite as APIs Cloud Identity, IAM e Cloud Logging.
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE
region = "us-central1"
}
locals {
labels = {
project = "certlabpro-agwa"
managed_by = "terraform"
}
}
resource "google_project_service" "cloudidentity" {
service = "cloudidentity.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "logging" {
service = "logging.googleapis.com"
disable_on_destroy = false
}Grupos do Cloud Identity são o espelho do lado do GCP dos grupos do Google Workspace — eles vivem no mesmo diretório de identidade e são endereçáveis através do mesmo formato group-email@your-domain.com. O exame AGWA testa este modelo de identidade de painel único: um usuário provisionado no Workspace é a mesma identidade que obtém vinculações IAM no GCP.
Criamos um grupo de segurança dev-readers@your-domain.com. Substitua your-org-id pelo seu ID de cliente do Cloud Identity (encontre via gcloud organizations list → o campo directoryCustomerId).
Este recurso precisa de posse de domínio — ele falhará a menos que você controle your-domain.com e tenha a API Cloud Identity habilitada no escopo da organização. Para um laboratório rápido sem um domínio real, pule esta etapa e use uma identidade IAM existente na Etapa 3.
resource "google_cloud_identity_group" "dev_readers" {
display_name = "dev-readers"
description = "Lab Cloud Identity group for the AGWA walkthrough"
parent = "customers/your-org-id" # REPLACE — find via `gcloud organizations list`
group_key {
id = "dev-readers@your-domain.com" # REPLACE with your Workspace domain
}
labels = {
"cloudidentity.googleapis.com/groups.discussion_forum" = ""
}
initial_group_config = "WITH_INITIAL_OWNER"
depends_on = [google_project_service.cloudidentity]
}Os administradores do Workspace regularmente atribuem permissões GCP a grupos do Workspace — o padrão recomendado pelo AGWA é conceder funções a grupos, gerenciar membros no Workspace. Vinculamos o grupo dev-readers da Etapa 2 a roles/viewer no projeto atual. Qualquer pessoa cujo administrador do Workspace a adicione a dev-readers@your-domain.com herda instantaneamente o Visualizador neste projeto GCP. Qualquer pessoa removida perde-o.
Observe o prefixo group: no campo member do IAM — essa é a sintaxe canônica para vincular uma identidade de grupo. Outros prefixos que o exame AGWA testa: user: (individual), serviceAccount: (conta de serviço), domain: (todos os usuários em um domínio).
data "google_project" "current" {}
resource "google_project_iam_member" "dev_readers_viewer" {
project = data.google_project.current.project_id
role = "roles/viewer"
member = "group:${google_cloud_identity_group.dev_readers.group_key[0].id}"
}O exame AGWA testa o escopo do Cloud Audit Logs: os logs de Atividade de Administrador estão sempre ativos e são gratuitos; os logs de Acesso a Dados estão desativados por padrão e são cobrados normalmente; os logs de Evento do Sistema estão sempre ativos e são gratuitos; os logs de Política Negada (negar VPC-SC) estão sempre ativos e são gratuitos.
Criamos um logging bucket dedicado (separado dos buckets padrão _Required e _Default) chamado audit-events, e então um log sink que encaminha todos os logs de auditoria relacionados ao IAM para ele. Isso oferece às equipes de conformidade uma janela de retenção separada dos logs operacionais em _Default — o padrão recomendado pelo AGWA para que a retenção de logs de auditoria sobreviva à resposta a incidentes.
resource "google_logging_project_bucket_config" "audit" {
project = data.google_project.current.project_id
location = "global"
retention_days = 400 # 13 months — typical compliance ask
bucket_id = "audit-events"
depends_on = [google_project_service.logging]
}
resource "google_logging_project_sink" "audit_sink" {
name = "certlabpro-agwa-audit-sink"
destination = "logging.googleapis.com/${google_logging_project_bucket_config.audit.id}"
filter = "logName:\"cloudaudit.googleapis.com\" AND protoPayload.serviceName=\"iam.googleapis.com\""
unique_writer_identity = true
}terraform destroy derruba tudo. O grupo Cloud Identity é destruído (apenas exclui do Cloud Identity; se fosse um grupo real do Workspace, restaure do console de administração em até 25 dias). A vinculação IAM é desanexada; os membros do grupo perdem o Visualizador imediatamente. O logging bucket + sink são destruídos de forma limpa; a retenção de 400 dias só importa enquanto os logs estiverem sendo enviados para lá.
O AGWA abrange superfícies de administração do Workspace que não são diretamente Terraformáveis através do provedor google — regras de roteamento do Gmail / filtros de spam / DMARC / DKIM / SPF, padrões de compartilhamento do Drive / drives compartilhados / rótulos, políticas de gravação do Meet, provisionamento de salas do Calendar, gerenciamento de dispositivos móveis (avançado + básico), políticas do navegador Chrome, políticas de Acesso Adaptativo ao Contexto (que TÊM uma superfície TF via google_access_context_manager_*, mas vivem no escopo da organização e precisam do Cloud Identity Premium), regras de retenção do Vault, exportações de eDiscovery e a árvore de configurações mais ampla do console de administração do Workspace.
O provedor Terraform googleworkspace existe para usuários / grupos / unidades organizacionais / domínios / atribuições de função dentro do próprio Workspace, mas requer uma conta de serviço com delegação em todo o domínio e o subject de um superadministrador — fora do escopo para um laboratório rápido.
Nós nos limitamos às primitivas Cloud Identity Groups + IAM + Audit Logs porque elas são o limite documentado entre o Workspace e o GCP — a parte que todo administrador do Workspace deve dominar. Para padrões de administração internos do Workspace (Gmail / Drive / Meet / mobile / Chrome), as seções do Guia + Editorial cobrem a superfície conceitual.