Google Cloud Organization Setup and Governance

Designing the overall resource hierarchy for an organization means arranging the Organization resource, folders, and projects into a tree that controls security, cost, and delegation. The tree limits blast radius so a compromise in one project does not spread to sibling projects.

1.1Organizing Resources with Organization, Folders, and Projects

Organizing resources with Organization, folders, and projects creates the foundation for isolation and delegated administration in Google Cloud. The Resource Manager (opens in a new tab) provides a tree with the Organization resource as the root, folders in the middle, and projects as leaves that hold virtual machines, buckets, and other service resources. Folders can nest up to 10 levels deep with up to 300 child folders under one parent, and Identity and Access Management (IAM) permissions and organization policies attached higher in the tree cascade to everything below. A common pattern places Development and Production folders below the Organization, then App 1 and App 2 folders inside each environment, then separate projects for independent modules. A Bootstrap folder sits directly below the Organization for infrastructure-as-code and pipelines, while shared monitoring sits below the Organization when one instance serves all environments.

1.2Sharing Networks Across Projects with Centralized Connectivity

Shared networking across projects connects workloads while keeping routing and firewalls under central control. Shared VPC centralizes a Virtual Private Cloud (VPC) network in a host project that owns subnets, routes, and firewall rules, while attached service projects own instances that receive internal addresses from those shared subnets. VPC Network Peering merges forwarding between two VPC networks so workloads use internal addresses over Google's backbone, but it is non-transitive and requires non-overlapping ranges. Private Service Connect (PSC) exposes only one service through a private endpoint without exposing the whole producer network.

Traffic flows from service-project instances into host-project subnets in Shared VPC, from spoke to hub in peering, and from consumer endpoint across Google's backbone to producer load balancer in PSC. Provisioning Shared VPC follows a fixed order: first create and enable the host project and network, then attach each service project and grant subnet-level access.

1.3Collecting Logs and Metrics Across Projects

Multi-project monitoring and logging collects logs and metrics from many projects into central destinations for security and operations. Log entries flow from workload projects through an aggregated sink created at the organization or folder level into a central Logging bucket, BigQuery dataset, or Pub/Sub topic. An aggregated sink automatically covers current and future child projects, so new projects are included without new configuration. Time-series data stays in its source project but becomes visible centrally through a metrics scope attached to a scoping project.

Building central logging follows an ordered workflow: first create the central bucket or dataset, then create the aggregated sink with an inclusion filter, then grant the sink writer identity write permission, then grant analysts read permission. By default logs are stored for 30 days, 365 days is recommended for large enterprises, and custom retention ranges from 1 day to 3650 days. Admin Activity, System Event, and Access Transparency logs are included by default, while Data Access and Policy Denied logs export centrally only if enabled in source projects.

1.4Controlling Access with IAM Roles and Organization Policies

Controlling access with IAM roles and organization-level policies combines who can act with what configurations are allowed. Identity and Access Management (opens in a new tab) allow policies bind a principal such as a user, group, or service account to a role on an organization, folder, or project node and inherit downward. Least privilege places each grant at the lowest node that covers the work: organization only for central admins, folder for team administration, and project for workload operators. The Organization Policy Service evaluates every create or update request against constraints and denies non-compliant requests at request time.

Inheritance differs between the two systems: a child organization policy replaces the inherited parent policy for that branch, while a child IAM allow policy adds to the inherited allow policy. IAM deny policies are evaluated before allow policies and can override them. Common guardrails include gcp.resourceLocations for allowed regions, gcp.restrictServiceUsage for allowed services, iam.allowedPolicyMemberDomains for trusted domains, and gcp.restrictTLSVersion for minimum TLS.

1.5Creating and Managing Service Accounts as Workload Identities

Creating and managing service accounts means deciding where workload identities live and securing how they authenticate. A service account is both a principal that can receive IAM roles and a resource that other principals can be given permission to use. Each account lives in one project, cannot be moved after creation, and is limited per project by quota. Same-project placement keeps the account with its resources, while centralized placement in dedicated projects improves tracking but requires cross-project attachment and API enablement in both projects.

Authentication should use short-lived credentials instead of long-lived keys. The constraints iam.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyUpload block new user-managed keys and external key uploads, while constraints/iam.serviceAccountKeyExpiryHours enforces rotation where keys remain. Workload Identity Federation lets external workloads exchange native credentials for short-lived Google tokens and impersonate a service account without keys. Impersonation uses Service Account User for attaching an account to a resource and Service Account Token Creator for requesting tokens directly, and access should be managed per account rather than at the project level.

1.6Enforcing Data Residency with Location and Key Controls

Enforcing data residency controls where data rests, where encryption keys live, and where data can be reached from. Geographic prevention uses constraints/gcp.resourceLocations on an organization, folder, or project to allow only approved locations, and every new creation request for supported services is denied if it does not match. The check applies only to newly created resources and does not move existing violating resources, which must be migrated, redeployed, or deleted. Detection compares runtime location against policy with Cloud Asset Inventory feeding Security Command Center findings such as RESOURCE_LOCATION_NOT_ALLOWED.

Compliant storage pins data to approved footprints: Cloud Storage single-region for strictest locality, dual-region for bounded recovery, and multi-region for broad durability. Cloud SQL pins data and backups to the creation region unless a cross-region replica adds a second location, BigQuery residency follows dataset location, and Firestore and Bigtable follow regional or multi-region replication choices. Cryptographic separation with Cloud External Key Manager keeps keys outside Google, while customer-supplied keys are supplied per operation and purged afterward.

Managing infrastructure means defining desired state in versioned files and reconciling Google Cloud to that state through automated pipelines. Version control is the source of truth, Cloud Build executes changes, and policy checks block non-compliant plans before resources are created.

2.1Provisioning Foundations with Infrastructure-as-Code Tooling

Provisioning foundations with infrastructure-as-code tooling separates authoring configuration from running it with consistent state. Infrastructure Manager provides managed Terraform orchestration on Google Cloud with previews that verify plans and deployments that track resources, depending on config.googleapis.com and roles/config.agent. Config Connector reconciles Google Cloud resources from Kubernetes YAML manifests through a Google Kubernetes Engine (GKE) cluster controller. Terraform Cloud runs remotely with stored state and secrets, while Terraform Enterprise is the self-hosted distribution for keeping that control plane inside an organizational boundary.

Shift-left validation checks a Terraform JSON plan against organization policies before creation and requires Security Command Center Premium or Enterprise tier at the organization level. Creating a report follows an ordered workflow: first run terraform init with provider v5.5 or later, then run terraform plan -out and convert with terraform show -json, then run gcloud scc iac-validation-reports create with the parent organization and location.

2.2Making Infrastructure Changes with Blueprints and Pipelines

Making infrastructure changes with blueprints and pipelines replaces manual console work with planned, reviewed, and repeatable promotion. The Terraform state file links each configured object to its real object, so later runs create missing objects, update differing objects, and leave matching objects unchanged. The terraform-example-foundation blueprint deploys in sequential stages where later stages depend on earlier outputs: 0-bootstrap for state buckets and pipeline identities, then 1-org for folders and policies, then 2-environments for development and production, then 3-networks for Shared VPC topology. Each stage uses a different least-privilege service account so one trigger cannot affect another stage's resources.

IAM resource behavior on the next apply depends on authoritativeness: google_project_iam_policy overwrites the entire policy, google_project_iam_binding overwrites all members for one role, and google_project_iam_member only adds one member and preserves others. Progressive rollouts apply changes to a few machines in one zone first, verify health, then expand gradually, with fast reversion on failure. Data flows from source control to Cloud Build for execution, to Artifact Registry for storage, and through Cloud Deploy promotion to target runtimes.

2.3Automating Operations with Scripting and Event Remediation

Automating operations with scripting runs Python and Go code as pipeline steps and reactive handlers that call Google Cloud APIs. Pipeline execution separates building once from releasing safely: Cloud Build imports source and runs versioned steps, Artifact Registry stores versioned images, and Cloud Deploy promotes the same artifact through environments. Secret Manager supplies credentials at runtime so passwords and tokens stay out of code and logs. Local development uses Application Default Credentials from gcloud auth application-default login, while workloads on Google Cloud use the service account attached to the compute resource.

Event-driven remediation detects drift and fixes it without human action through an ordered pipeline:

1. Record: An API call is recorded as an audit log entry in Cloud Logging.
2. Route: A log sink forwards matching entries to a Pub/Sub topic.
3. Deliver: Pub/Sub delivers the message to a Cloud Functions handler or Cloud Run service.
4. Remediate: The function or service calls the resource API to restore desired state.

Cloud Functions fits lightweight handlers that parse one message and call one or two APIs, while Cloud Run fits containerized work with custom dependencies or longer processing. Retry logic must discard events older than 10 seconds to avoid poison-message loops.

Designing a CI/CD architecture stack in hybrid and multicloud (opens in a new tab) environments connects source events to tested artifacts to progressive delivery. Cloud Build tests and builds, Artifact Registry stores, and Cloud Deploy promotes one release through ordered targets.

3.1Running Continuous Integration with Cloud Build

Running continuous integration with Cloud Build tests every commit and pushes a versioned image to Artifact Registry. A cloudbuild.yaml file declares an ordered list of steps that share source code and a workspace, and a build trigger starts that file when a repository event occurs. Data flows from the source repository to the trigger, through build steps in declared order, and to deployment targets. Each step names a builder image such as python:3.13-slim for tests, gcr.io/cloud-builders/docker for build and push, gcr.io/cloud-builders/gcloud for manifests, and gcr.io/cloud-builders/kubectl for cluster applies.

A minimal pipeline runs test, then build tagged with commit SHA, then push to Artifact Registry. Creating a trigger follows an ordered workflow: open Triggers and select a region, connect the Git repository, name the trigger and select event and branch, point to the cloudbuild.yaml path, add substitution values, and assign a least-privilege service account. Substitutions such as $PROJECT_ID, $SHORT_SHA, and custom $_REGION keep one configuration reusable, and tagging with short SHA links each image to its exact commit.

3.2Progressing Delivery with Cloud Deploy, Kustomize, and Skaffold

Progressing delivery with Cloud Deploy moves one versioned release through ordered targets with consistent manifests. Cloud Deploy owns the pipeline and promotion order, Skaffold renders and applies manifests, and Kustomize customizes shared manifests per environment. Two-stage rendering separates generation from image injection: first Kustomize hydrates manifests from kustomization.yaml, then Skaffold substitutes release images supplied with --images. Cloud Deploy runs skaffold diagnose and skaffold render for all targets at release creation through Cloud Build, then runs skaffold apply with kubectl on each rollout.

Skaffold profiles select per-target overlays by matching profile names on pipeline stages to profiles in skaffold.yaml, such as staging versus prod paths. The release flow preserves order: provide source and images, diagnose and render, substitute images, apply to the first target, then promote the already-rendered manifest to each next target. Strategy controls placement: standard deploys fully at once, automated canary shifts traffic by percentages, and custom canary defines named phases ending with stable at 100%. Kustomize and Helm are renderers, not deployers.

3.3Storing Artifacts with Artifact Registry Configuration

Storing artifacts with Artifact Registry configuration separates private publishing, public caching, and consolidated access. Each repository holds one format such as Docker, Maven, npm, Python, Go, or Helm and uses one mode that controls request flow. A standard repository stores private artifacts uploaded by builds, a remote repository caches copies from Docker Hub or Maven Central on first request, and a virtual repository forwards to upstreams in priority order without storing directly. Prioritizing the private repository above the remote reduces dependency confusion attacks.

Security combines repository-level IAM, VPC Service Controls perimeters, and location constraints for residency. Artifact Analysis scans uploads and monitors for new findings with software bill of materials (SBOM) and Vulnerability Exploitability eXchange (VEX) support, while Binary Authorization blocks deployment unless required attestations are present. Cleanup policies with DELETE or KEEP actions remove old versions by tag state, age, or count, and placing repositories in the same region as builds and runtimes reduces latency and egress cost.

3.4Integrating Widely Used Third-Party Tooling

Integrating widely used third-party tooling combines Git signals, automation engines, and delivery controllers. Git merges trigger tests on each commit, and tagging images with $COMMIT_SHA links each image to its commit for audit and rollback. Cloud Build runs copy source, test, build images, publish images, rewire specifications, and publish pipelines in order, while Jenkins serves as an alternative engine and Argo CD reconciles live clusters toward Git desired state. Packer automates golden Compute Engine images that already contain required software, while kpt packages and validates declarative Kubernetes configurations.

Security gives third-party tools only needed access through per-environment service accounts, Secret Manager for secrets, and VPC Service Controls to block unauthorized API reach. Integrity controls require signed artifacts, trusted publisher keys, and regular rebuilds from trusted sources. Confidentiality follows Bell-LaPadula by blocking flow from higher to lower confidentiality, while integrity follows Biba by blocking flow from lower to higher integrity.

3.5Securing CI/CD Tooling with Policy and Admission Control

Securing CI/CD tooling treats the pipeline as a production system with prevention at check-in and detection in production. Policy-as-Code with Open Policy Agent checks infrastructure before deployment, while Policy Controller enforces admission in Kubernetes. Organization policies limit domain sharing, service account use, and resource locations, and Cloud Deploy adds human approval gates before promotion. Cloud Logging records pipeline activity for audit, with dashboards and breakglass procedures for emergency use.

Binary Authorization is the pre-deployment gate that allows only trusted images to deploy to GKE and Cloud Run. The policy maintains an exempt list and can require attestations such as build origin or vulnerability checks. Continuous validation does not block running Pods but logs conformance results throughout their lifecycle, including dry-run and breakglass admissions.

Managing multiple environments means isolating development, staging, and production while promoting the same tested artifact and configuration through each stage. Isolation uses separate projects and networks, while consistency uses shared pipelines, policies, and fleet controls.

4.1Managing Ephemeral Environments with Isolated Projects

Managing ephemeral environments creates short-lived, isolated Google Cloud environments on demand and destroys them when work completes. Infrastructure as Code (IaC) declares machines, networks, databases, and identity in versioned files, and CI/CD executes those files to build, test, and tear down the same environment repeatedly. A common pattern provisions a dedicated project per instance with Shared VPC attachment, IAM bindings, and enabled APIs, then creates a new VPC network inside that project. The pipeline runs as a dedicated least-privilege service account, organization constraints block downloadable service account keys, and VPC Service Controls checks whether caller and resource are inside the same perimeter.

The triggered lifecycle preserves order from request to cleanup:

1. Trigger: A commit, pull request, schedule, or API call invokes a Cloud Build trigger.
2. Validate and plan: The pipeline runs Terraform validate and plan before changing state.
3. Apply: The pipeline creates the isolated project, network, accounts, and workloads.
4. Test and publish: Tests run inside the ephemeral environment with artifacts stored centrally.
5. Promote or destroy: The same configuration promotes with distinct variables, then the project is deleted to stop cost.

Cost attribution exports billing to BigQuery grouped by project labels, with budget alerts at forecasted thresholds.

4.2Managing Configuration and Policy Across Environments

Managing configuration and policy across environments ensures every project inherits the same guardrails without manual checks. The Organization Policy Service attaches constraints at organization, folder, or project level that descendants inherit, and violating creates fail. Managed constraints cover best practices, while custom constraints restrict specific fields such as machine family, disk type, or firewall ports before resources persist. Foundational constraints include gcp.resourceLocations for residency, gcp.restrictNonCmekServices for customer-managed encryption, and gcp.restrictServiceUsage for allowed services.

Declarative export converts live resources into versioned code with separated state per environment. The workflow runs in order: prepare isolated Cloud Shell context for one project, bulk-export with gcloud beta resource-config bulk-export, generate reusable modules with import scripts, then run terraform init and import live IDs into state. GitOps fleet configuration with Config Sync distributes desired cluster state and Policy Controller enforces admission, so staging and production converge without per-cluster edits.

4.3Managing GKE Clusters Across an Enterprise with Fleets

Managing Google Kubernetes Engine (GKE) clusters across an enterprise joins different clusters into one fleet with shared identity and management. Registration creates a membership record for each cluster, and federation lets workloads exchange Kubernetes credentials for Google Cloud credentials. Heterogeneous registration with GKE attached clusters joins external clusters such as Amazon EKS or Azure AKS as regional AttachedCluster resources, with metadata stored in that region for residency. The Connect Agent inside each cluster connects outward to the Connect API to create a secure tunnel, so management traffic flows from Google Cloud through the tunnel without a direct inbound path.

Workload Identity Federation for GKE depends on the Kubernetes Engine Service Agent for compute management and the Default Node Service Agent for node workloads, each holding its specific role. Cross-cluster traffic uses Multi-cluster Services (MCS) for Pod-to-Pod discovery and Multi-cluster Ingress (MCI) for external access through one virtual IP.

MCS requires VPC-native clusters on connected networks and the same namespace in every cluster, while MCI uses one config cluster to create load balancer resources for all backends.

4.4Applying Safe and Secure Patching and Upgrading Practices

Applying safe and secure patching and upgrading practices validates changes in lower environments and rolls them to production in small batches. VM Manager divides operating system work into patch deployment that schedules jobs and compliance reporting that verifies remaining updates. Both depend on the OS Config API in the control plane and the OS Config agent on each virtual machine. The agent invokes the native updater and reports progress, where a patch deployment schedules one or more patch jobs and a patch job is the single execution against VMs matched at start time.

The Patch service does not host patches, so each VM must reach its distribution source directly or through a mirror, Windows Server Update Service, Cloud NAT, or proxy. One job patches a maximum of 500 VMs simultaneously, with zone-by-zone or concurrent-zones modes and disruption budgets limiting concurrent changes. Patch compliance maps distribution severities to Critical, Important, Other, and Up-to-date states with about 30 minutes lag. Secure GKE upgrades group clusters into ordered stages that advance only after a version becomes the auto-upgrade target for the release channel, with Autopilot surge or Standard blue-green node strategies.

Enabling secure cloud development environments keeps developer desktops productive while preventing data from leaving trusted boundaries. Centralized workstations, rebuilt images, and governed AI assistance enforce identity, network, and encryption controls without manual setup on each laptop.

5.1Configuring and Managing Cloud Development Environments

Configuring and managing cloud development environments centralizes developer machines inside Google Cloud with strict identity and network boundaries. Cloud Workstations (opens in a new tab) runs each workstation on a Compute Engine virtual machine with a persistent disk for /home, created from a configuration template that defines machine type, image, IDE, timeouts, and access policy. Access depends on the Cloud Workstations User role plus a generateAccessToken bearer token that remains valid until expiration and cannot be revoked, making workstation IAM the primary trust boundary. Service account impersonation with iam.serviceAccounts.actAs and OS Login with 2-Step Verification further harden access, since OS Login blocks attackers holding only stolen OAuth tokens.

Network isolation uses Shared VPC with central routing, while traffic from IDEs normally flows over TLS to Google Front End for routing and protection. Private connectivity through Cloud VPN or Cloud Interconnect replaces internet traversal when required, with Private Google Access directing API traffic to restricted.googleapis.com. Perimeter defense combines VPC Service Controls, which covers all users and service accounts around resources, with Chrome Enterprise Premium, which checks per-request user and device conditions only for organization users.

Workstation lifecycle separates ephemeral compute from durable data: start creates a VM, pulls the image, creates and attaches the home disk on first start, then mounts it; stop deletes the VM while retaining the disk. Defaults are idleTimeout 1200 seconds with STOP action and runningTimeout 43200 seconds, where suspending does not reset running timeout.

5.2Bootstrapping Environments with Required Tooling and Images

Bootstrapping environments with required tooling defines approved versions once in code and ships them through rebuilt images. A Dockerfile defines workstation contents, an imagebuilder.yaml recipe defines OS customization, and cloudbuild.yaml defines build and publish steps, with Terraform pinning automation versions. Distribution flows from Git to Cloud Build triggers to Artifact Registry repositories, where Cloud Build writes images on one side and workstations and Compute Engine consume them on the other. Automated rebuilds on Git pushes and Cloud Scheduler schedules prevent drift to unapproved tools.

Custom machine images embed hardening and tooling so every VM starts compliant through manual baking, automated baking with Packer, or disk import. Image families manage versioned lines where deployments reference the family pointer to roll forward, and deprecation moves through states in order: DEPRECATED still launches with warning, OBSOLETE fails new launches but allows data mounting, and DELETED blocks launch pending removal. Supply chain hardening uses Assured Open Source Software, remote repositories that cache public sources, virtual repositories that prioritize private packages, and Artifact Analysis scanning with SBOM and VEX. IDE standards enforce the same checks locally, as pre-commit hooks, and in Cloud Build gates.

5.3Leveraging AI to Assist with Development and Operations

Leveraging AI to assist with development and operations accelerates coding and troubleshooting within IAM, privacy, and network governance. Gemini Code Assist (opens in a new tab) generates, explains, and debugs code inside Visual Studio Code or JetBrains IDEs, while Gemini Cloud Assist helps from the console and CLI with design, optimization, and incident analysis. Every output must be validated because models can produce plausible but incorrect results. Context-aware chat builds answers from project ID, page context, and session history, while Investigations ingests logs and metrics to produce ranked observations and hypotheses.

Access requires roles/geminicloudassist.user and roles/cloudasset.viewer for Cloud Assist and roles/cloudaicompanion.user plus roles/serviceusage.serviceUsageConsumer for Code Assist, granted in the project where the enabling API is active. Prompts and responses are Customer Data handled by stateless shared models and not stored by default unless logging is configured. Traffic flows from workstations over TLS to Google Front End into the Gemini API, which has no access to other project resources. When a VPC Service Controls perimeter is used, Gemini APIs must be added with explicit ingress policies.

Key Facts

• The resource hierarchy nests folders up to 10 levels deep with up to 300 child folders per parent, where organization policies replace inherited policies while IAM allow policies add to them.
• A Google Cloud project is the container for deployment, billing, and per-project quota enforcement, while Shared VPC centralizes networking, peering is non-transitive, and Private Service Connect exposes only one service.
• google_project_iam_policy and google_project_iam_binding overwrite existing access while google_project_iam_member is additive, and tagging images with commit SHA links each artifact to its exact source commit.
• Binary Authorization blocks deployment without required attestations while continuous validation only logs violations for running Pods, and a single VM Manager patch job patches a maximum of 500 VMs without hosting packages itself.
• Cloud Workstations separates ephemeral VMs from persistent home disks with idle timeout of 1200 seconds and running timeout of 43200 seconds, and approved toolchains are enforced by rebuilding custom images rather than updating individual CLIs.