Last reviewed: May 2026
Build the AWS services on the AGWA exam with plain Terraform — one block at a time, each tied back to an exam domain. The same code works on OpenTofu.
By the end of this lab you'll have provisioned, with plain Terraform, the GCP-side substrate every Google Workspace admin should understand — the Cloud Identity API enabled, an IAM group created at project scope, the group bound to a viewer role, and a Cloud Audit Logs sink routing org-level audit events into a dedicated logging bucket. Four blocks; the Cloud Identity + Audit Logs boundary the AGWA exam tests.
Drop the snippets into a single main.tf, run terraform init, then terraform apply step-by-step.
Note: most of AGWA's exam content lives in the Workspace admin console (Gmail routing, Drive sharing policies, mobile device management, context-aware access) which is not directly Terraformable via the google provider. The googleworkspace provider exists but requires a Workspace super-admin service account with domain-wide delegation — out of scope for a lab.
>= 1.5 or OpenTofu >= 1.6.your-project-id and your-org-id in the snippets below.All free at lab scope:
The Workspace product itself bills per-seat (~$6/user/month for Business Starter, up to ~$30/user/month for Enterprise) — out of lab scope. The substrate below is free.
Enable Cloud Identity, IAM, and Cloud Logging APIs.
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
}Cloud Identity Groups are the GCP-side mirror of Google Workspace groups — they live in the same identity directory and are addressable via the same group-email@your-domain.com format. AGWA exam tests this single-pane-of-glass identity model: a user provisioned in Workspace is the same identity that gets IAM bindings in GCP.
We create a security group dev-readers@your-domain.com. Replace your-org-id with your Cloud Identity customer ID (find via gcloud organizations list → the directoryCustomerId field).
This resource needs domain ownership — it will fail unless you control your-domain.com and have the Cloud Identity API enabled at org scope. For a quick lab without a real domain, skip this step and use an existing IAM identity in Step 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]
}Workspace admins regularly assign GCP permissions to Workspace groups — the AGWA-recommended pattern is grant roles to groups, manage membership in Workspace. We bind the dev-readers group from Step 2 to roles/viewer at the current project. Anyone whose Workspace admin adds them to dev-readers@your-domain.com instantly inherits Viewer on this GCP project. Anyone removed loses it.
Note the group: prefix on the IAM member field — that's the canonical syntax for binding a group identity. Other prefixes the AGWA exam tests: user: (individual), serviceAccount: (service account), domain: (all users in a domain).
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}"
}AGWA exam tests Cloud Audit Logs scope: Admin Activity logs are always on and free; Data Access logs are off by default and bill normally; System Event logs are always on and free; Policy Denied logs (VPC-SC denies) are always on and free.
We create a dedicated logging bucket (separate from the default _Required and _Default buckets) named audit-events, then a log sink routing every IAM-related audit log into it. This gives compliance teams a separate retention window from the operational logs in _Default — the AGWA-recommended pattern for audit log retention to outlive incident response.
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 tears down everything. The Cloud Identity group destroys (only deletes from Cloud Identity; if it was a real Workspace group, restore from admin console within 25 days). The IAM binding detaches; group members lose Viewer immediately. The logging bucket + sink destroy cleanly; the 400-day retention only matters while logs are landing there.
AGWA covers Workspace admin surfaces that are not directly Terraformable via the google provider — Gmail routing rules / spam filters / DMARC / DKIM / SPF, Drive sharing defaults / shared drives / labels, Meet recording policies, Calendar room provisioning, mobile device management (advanced + basic), Chrome browser policies, Context-Aware Access policies (which DO have a TF surface via google_access_context_manager_* but live at org scope and need Cloud Identity Premium), Vault retention rules, eDiscovery exports, and the broader Workspace admin console settings tree.
The googleworkspace Terraform provider exists for users / groups / org-units / domains / role-assignments inside Workspace itself, but requires a service account with domain-wide delegation and a super-admin's subject — out of scope for a quick lab.
We stick to the Cloud Identity Groups + IAM + Audit Logs primitives because they're the documented boundary between Workspace and GCP — the part every Workspace admin must own. For Workspace-internal admin patterns (Gmail / Drive / Meet / mobile / Chrome), the playbook + editorial sections cover the conceptual surface.