Prepare and test your skills
Prepare and test your skills
Infrastructure as Code with Terraform (opens in a new tab) and the Cloud Foundation Toolkit (CFT) (opens in a new tab) is the Google-recommended way to provision Google Cloud foundations consistently and repeatably. Terraform provides the declarative language and state tracking, while CFT provides Google-maintained modules and blueprints such as terraform-example-foundation that encode best practices for structure, security, and operations. Together they replace manual console work with versioned pipelines where every change is planned, reviewed, and applied the same way.
Terraform provisioning is a declarative process where configuration files describe the desired end state and Terraform calls Google Cloud APIs to make reality match. The Terraform provider for Google Cloud translates each resource block into API calls, so authors do not write imperative provisioning steps. A Terraform state file is the JSON mapping that links each object in configuration to its real object and lets Terraform decide whether to create, update, or leave each resource unchanged.
The core workflow runs in a fixed order with state as the decision point:
terraform plan to evaluate configuration and generate a plan showing resources to add, change, or destroy.terraform apply to provision infrastructure through Google Cloud APIs and write or update the state file.On later runs Terraform first creates objects that are in configuration but not in state, then updates objects where state differs from configuration, and only then leaves matching resources unchanged. Because apply overwrites drift to match configuration, out-of-band console changes are reverted unless they are imported into state or reflected in code.
The Cloud Foundation Toolkit blueprints deploy the organization in sequential stages where each later stage depends on the outputs and state of earlier stages. The 0-bootstrap stage must run first because it creates the automation itself: the seed project that holds Cloud Storage (opens in a new tab) buckets for Terraform state and highly privileged service accounts, and the CICD project that holds the Cloud Build foundation pipeline. State in bootstrap is protected with Cloud Storage Object Versioning, and Cloud Build acts as the service accounts managed in the seed project.
After bootstrap, the foundation pipeline deploys resources stage by stage in order:
Each stage uses a different service account with only the minimum Identity and Access Management (IAM) roles for that stage, as defined in 0-bootstrap/sa.tf. Each Cloud Build trigger runs as its stage-specific account, so a change in one repository cannot directly affect resources managed by another stage.
Compute and IAM best practices in CFT modules reuse safe patterns instead of re-deciding them for every workload. For virtual machines, the recommended pattern is to bake images with a tool like Packer and have Terraform only launch instances from pre-baked images. Terraform should pass configuration to the guest through instance metadata, not through ad hoc scripting.
Use a provisioner block that hands a new virtual machine to configuration management only as a last resort, because provisioners run outside the declarative model and can leave inconsistent state. When teardown logic is required, the provisioner that needs cleanup must use when = destroy so old state associated with the instance is cleaned up on deletion.
For IAM, Terraform offers three resource families with very different blast radius:
| Resource family | Scope of control | Behavior on next apply |
|---|---|---|
google_*_iam_policy, for example google_project_iam_policy | Authoritative for the whole resource policy | Overwrites the entire policy to match configuration, removing roles added outside Terraform including Google-managed roles |
google_*_iam_binding, for example google_project_iam_binding | Authoritative for one role on the resource | Overwrites all members for that role to match configuration, removing members added outside Terraform |
google_*_iam_member, for example google_project_iam_member | Additive for one member on one role | Adds or manages only that single binding and preserves other bindings |
Choose google_*_iam_member resources or the Google IAM module when multiple teams, automation, or Google Cloud services also manage access to the same project, folder, or bucket. Reserve authoritative policy and binding resources for resources wholly owned by one Terraform configuration.
Exam tip: google_project_iam_policy and google_project_iam_binding are authoritative and will remove Google-managed roles on next apply, while google_project_iam_member is additive and preserves existing access.
Remote state management stores the Terraform state file in Cloud Storage rather than locally so production runs share one system of record. The foundation pattern reuses one backend bucket such as gs://tfstate-PROJECT_ID with prefix terraform/state, producing state objects like terraform/state/default.tfstate. A backend.tf file declares that dependency with a terraform { backend "gcs" { bucket = "tfstate-PROJECT_ID" prefix = "terraform/state" } } block, so terraform init initializes the working directory against that bucket before any plan can be correct.
To redeploy an exported foundation configuration from Cloud Shell, the flow depends on that backend in order. First, download the configuration and upload it to a new directory such as cloud-foundation-example-redeploy. Then verify the backend bucket and state object exist, reuse the same bucket and prefix in backend.tf, and run terraform init. Only after initialization, run terraform plan to review adds, changes, and destroys, then run terraform apply and confirm with yes to deploy to Google Cloud.
Two state-conflict cases have explicit handling. If the foundation was first deployed with the console Deploy button, the generated state must be carried forward: lock the Infrastructure Manager deployment, download the state file, unlock the deployment, move the state file into the Cloud Storage backend bucket, and then redeploy from Cloud Shell. If Terraform tries to create a resource that already exists, it exits with a 409 conflict error; either delete the existing resource with the console or gcloud CLI and re-apply, or import the critical resource into Terraform state so it becomes managed without deletion.
Policy-compliant GitOps delivery moves code from a Git repository through review into Cloud Build triggers, with policy enforced before infrastructure changes. Cloud Build (opens in a new tab) runs Terraform against Google Cloud using per-stage service accounts. The file cloudbuild-tf-plan.yaml validates code with Open Policy Agent constraints through policy validation and runs terraform plan, then cloudbuild-tf-apply.yaml runs terraform apply only if the plan passed policy. Constraints are forked from the shared policy library and can be extended with custom constraints.
The pipeline model separates ownership and blast radius across three layers:
Pipeline hardening controls sit on different trust boundaries. Least privilege isolates stages through separate service accounts. Cloud Build private pools optionally keep builds inside a VPC Service Controls perimeter. A custom builder image defined in 0-bootstrap/Dockerfile pins Terraform and libraries to known versions so every run uses identical tooling. Optional manual approval gates the build after trigger but before execution so a privileged user must approve deployment.
Changes move through environments with persistent Git branches for development, non-production, and production plus ephemeral feature branches that never map directly to deployed environments. The ordered promotion flow is:
feature/123456-org-policies.terraform plan and terraform validate for review.terraform apply to the development environment.terraform apply deploying to each matching Google Cloud environment in turn.All foundation modifications should follow this pull-request and pipeline path rather than direct console edits, so policy checks, reviews, and state updates stay consistent across environments.
Change management for Google Cloud infrastructure is the practice of deploying modifications progressively, controlling high-risk resources, and automating promotion through pipelines to preserve reliability. A complete strategy combines small-scope rollouts with fast rollback to a stable state, rigorous review for global resources, and Infrastructure as Code (IaC) executed by Cloud Build (opens in a new tab) from version control. Availability monitoring with health dashboards then informs whether to continue promotion or roll back.
Progressive deployment is the release of an infrastructure change to a small blast radius first, with verification before expanding across all zones and regions. For example, to change Compute Engine machine types or Cloud Storage bucket storage classes, the change is first applied to a few virtual machines (VMs) in one zone while workload health is monitored. If issues appear, the infrastructure is reverted quickly to the previous stable state, the cause is diagnosed and resolved, and the progressive process restarts. If the workload runs as expected, the same change is gradually deployed everywhere, which limits the impact of a bad change and creates a natural canary and rollback strategy.
Control of global resources is the requirement for extra verification before changing resources whose failure affects users in every zone and region. Virtual Private Cloud (VPC) networks and global load balancers are global resources that are resilient to zonal and regional outages, so architectures often use only a single instance of each. That single instance can become a single point of failure, because a misconfigured forwarding rule on a global load balancer can stop the frontend from receiving or processing user requests even while the backend remains intact. To manage this risk, the change-review process should classify any modification to global resources as a high-risk change that additional reviewers must verify and approve before deployment to production.
Automated provisioning with Cloud Build pipelines treats infrastructure changes like application changes by building, validating, and promoting versioned configuration from development to production. Cloud Build is the service that executes builds on Google Cloud, importing source code from Cloud Storage, Cloud Source Repositories, GitHub, or Bitbucket, executing a build to specification, and producing artifacts such as Docker containers or Java archives. IaC makes this automation safe and repeatable because desired state is defined in configuration files that can be versioned, reused, shared, audited, and reverted, with a single source of truth in source control.
IaC delivers consistent environments and change control through several related benefits:
The build-to-promotion chain depends on three complementary services that move code from source to environments in order. Data flows from source control to Cloud Build for execution, from Cloud Build to Artifact Registry (opens in a new tab) for storage, and from Artifact Registry to target runtimes through Cloud Deploy (opens in a new tab) promotion.
| Service | Role in the pipeline | Inputs and outputs |
|---|---|---|
| Cloud Build | Executes builds to specification | Imports source from Cloud Storage, Cloud Source Repositories, GitHub, or Bitbucket; produces Docker containers or Java archives |
| Artifact Registry | Manages the full artifact lifecycle in one location | Stores packages and Docker container images; integrates with continuous integration and continuous deployment (CI/CD) tools and Google Cloud runtimes |
| Cloud Deploy | Automates delivery through promotion | Delivers applications to a series of target environments in a defined promotion sequence |
A Google-recommended blueprint for predictable environment promotion uses Terraform with Cloud Build connected to GitHub, with Terraform state stored centrally. The workflow depends on the Cloud Build service account having permission to apply Terraform, and promotion moves only after validation in the lower environment:
Exam tip: Classify modifications to VPC networks and global load balancers as high-risk changes requiring additional reviewers, while zonal changes such as VM machine types can use progressive rollout to a few VMs in one zone first.
Availability monitoring provides the signals that determine whether a progressive change should continue or roll back to ensure service continuity. The Google Cloud Service Health Dashboard shows the current status of Google Cloud services across all regions, and its history page records infrastructure failures called incidents with incident duration, affected zones and regions, affected services, and recommended workarounds. Personalized Service Health shows incidents relevant to a specific project, supports requesting incident information through an application programming interface (API) on a per-project or per-organization basis, supports alerts, and provides regular incident updates including estimated time for the next update with programmatic RSS feed access. An application can still be unavailable when no infrastructure outage exists, such as when a software update crashes application servers or an administrator deletes load balancer forwarding rules, so pipeline decisions must correlate health signals with application and configuration checks before continuing promotion.
Governance with policy blueprints and security foundations is the practice of applying consistent identity, network, and policy controls so every infrastructure change meets security and compliance benchmarks. Controls divide into user-centric checks evaluated on each API request, resource-centric perimeters that bound communication, authentication hardening, key and privilege restrictions, endpoint protection, and emergency access procedures. Together these controls reduce the impact of compromised credentials and misconfigured resources.
User-centric and resource-centric perimeter controls enforce different boundaries that work best when combined. Chrome Enterprise Premium (opens in a new tab) is a user-centric control that evaluates an access level and binding on every API request, including conditions such as IP-based access or certificate-based access for mutual TLS. Requests that use compromised authorization credentials but do not meet the defined policy conditions are rejected. VPC Service Controls (opens in a new tab) is a resource-centric control that defines perimeters within which resources can communicate, blocking access from untrusted locations and mitigating data exfiltration.
Traffic flows from the user or workload to the Google Cloud API, where Chrome Enterprise Premium first checks user identity and device attributes, and VPC Service Controls then checks whether the target resource is allowed to communicate inside its perimeter. Chrome Enterprise Premium applies only to user identities within the organization, while VPC Service Controls applies to all user identities and service account identities. When used together, the two controls reduce the effectiveness of compromised credentials on an attacker-controlled machine outside the environment.
| Control | Scope | Applies to |
|---|---|---|
| Chrome Enterprise Premium | User-centric conditions evaluated on every API request | User identities in the organization only |
| VPC Service Controls | Resource-centric perimeter around services and data | All user identities and service account identities |
Exam tip: Choose Chrome Enterprise Premium when the requirement is to reject user API traffic that fails device or network conditions, and choose VPC Service Controls when the requirement is to contain resource-to-resource communication inside a trusted perimeter.
Strong authentication for remote server access requires an additional verification checkpoint beyond OAuth tokens. OS Login (opens in a new tab) with 2-Step Verification enforces this checkpoint for Secure Shell (SSH) access to Compute Engine resources, where a user must reauthenticate with a password or security key. Authentication flows from the SSH client through OS Login to the identity check before the session is granted, so an attacker with compromised OAuth tokens but no password or security key is blocked.
Remote Desktop Protocol (RDP) access to Windows instances on Compute Engine does not support the OS Login service, so 2-Step Verification cannot be granularly enforced for RDP sessions. When using Identity-Aware Proxy (IAP) Desktop or Chrome-based RDP plugins, apply coarse-grained controls such as session length for Google services and 2-Step Verification settings for web sessions, and disable the Allow user to trust the device setting. These settings shorten the lifetime of a compromised web session and prevent a device from bypassing future verification prompts.
Restriction of service account keys and enforcement of least privilege limit what a compromised credential can do. A service account key value is stored in gcloud CLI configuration files separately from the downloaded key file, so an attacker with access to the environment can copy the key from the configuration, the local file system, or an internal code repository. To reduce this exposure, use more secure authentication alternatives and enforce the constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints to disable key creation and upload.
Identity and Access Management policies must follow the principle of least privilege by granting only the roles required to accomplish a task at the smallest scope. Policy Intelligence role recommendations help identify and remove unused and excessive roles so policies stay aligned with actual usage. Because the organization policy constraint blocks new long-lived keys at the organization boundary and least-privilege IAM limits the permissions of any remaining identity, the blast radius of a leaked credential is contained on both sides.
Endpoint protection addresses compromise of trusted devices that bypass network perimeter checks. A trusted endpoint such as a developer workstation or Compute Engine instance can run gcloud CLI commands or other code directly, so an attacker with physical or remote access to the endpoint bypasses perimeter controls. Security operations must therefore protect physical security, monitor for network breaches, and control how approved traffic connects to resources inside the VPC Service Controls perimeter.
Endpoint governance depends on answering operational questions about credential lifetime and device trust:
Incident response alignment requires that security teams responsible for incident response have appropriate access across the Google Cloud console and the Admin console in advance. Pre-provisioned access ensures that responders can investigate identity, device, and perimeter signals without waiting for emergency grants during an incident.
Breakglass access is pre-designed, highly privileged access that lets operations or site reliability engineering (SRE) teams respond to outages when normal automation fails. The workflow depends on existing privileged access management tools, but common mechanisms move privileges from a locked state to a temporary active state and then back to locked. Operations teams use breakglass to restart virtual machines, restore data, or repair foundation pipeline resources in the CI/CD project and external Git repository.
Breakglass mechanisms include temporary elevation through existing tooling:
Every breakglass design must address scope, abuse prevention, auditing, and recovery before it is needed. First, define the scope and granularity so different business units cannot disrupt each other. Then, require controls such as approvals or split operations where one person holds credentials and another holds the multi-factor authentication token. Audit and alert on use, for example with a custom Event Threat Detection module that creates a security finding when a predefined breakglass account is used, and remove the access to resume normal operations after the incident. Where possible, replace repeated manual escalation with automated workflows, safe proxies, or audited breakglass to support zero-touch production.
terraform apply creates missing objects, updates drifted objects, and leaves matching objects unchanged.terraform-example-foundation deploys in order 0-bootstrap, 1-org, 2-environments, then 3-networks, with each stage running as a separate least-privilege service account.google_project_iam_policy and google_project_iam_binding are authoritative and overwrite existing access, while google_project_iam_member is additive and preserves other bindings.google_project_iam_policy and google_project_iam_binding are authoritative and overwrite existing access, while google_project_iam_member is additive and preserves other bindings. Authoritative policy overwrites the entire policy and binding overwrites all members for one role, removing roles or members added outside Terraform including Google-managed roles, so member resources should be used when multiple teams, automation, or Google Cloud services also manage access to the same resource.
terraform-example-foundation deploys in order 0-bootstrap, 1-org, 2-environments, then 3-networks, with each stage running as a separate least-privilege service account. 0-bootstrap must run first because it creates the automation itself, including the seed project that holds Cloud Storage buckets for Terraform state and privileged service accounts and the CICD project that holds the Cloud Build foundation pipeline.
Modifications to Virtual Private Cloud networks and global load balancers should be classified as high-risk changes requiring additional reviewers before deployment to production. Zonal changes such as Compute Engine machine types can instead use progressive rollout to a few virtual machines in one zone first, with rollback to the prior stable state on failure and gradual expansion if the workload runs as expected.
Chrome Enterprise Premium evaluates user-centric conditions on every API request for organization users, while Virtual Private Cloud Service Controls enforces a resource-centric perimeter for all user and service account identities. Chrome Enterprise Premium rejects user traffic that fails conditions such as IP-based or certificate-based access, while Virtual Private Cloud Service Controls bounds resource-to-resource communication inside a trusted perimeter to block access from untrusted locations and mitigate data exfiltration.
Your enterprise is deploying an enterprise-grade Google Cloud foundation using the Cloud Foundation Toolkit (CFT) and Terraform. You need to establish the bootstrap pipeline architecture and Terraform state management according to Google-recommended practices.
The deployment must satisfy the following technical requirements:
Which implementation should you choose?
Last updated