Prepare and test your skills
Prepare and test your skills
Design and automate ephemeral environment provisioning is the practice of defining short-lived, isolated Google Cloud environments in code and creating them on demand through automated pipelines. Infrastructure as Code (IaC) (opens in a new tab) declares the desired state of virtual machines, networks, databases, storage, and identity in versioned configuration files, and continuous integration and continuous deployment (CI/CD) executes those files to build, test, and tear down the same environment repeatedly. The result is a secure, consistent environment for a development or testing task that is created by a trigger or schedule and destroyed when work completes.
Reproducible foundations with Infrastructure as Code replace manual console clicks and scripts with human-readable configuration files that declare desired state. The same configuration can be deployed multiple times to produce matching development, test, and production behavior, which is essential when an ephemeral copy must match production for a single feature, pull request, or load test. Because configuration logic lives in source control, infrastructure changes follow the same review and validation discipline as application code.
IaC provides the consistency and control that make ephemeral use safe and repeatable:
The Terraform toolchain on Google Cloud centers on HashiCorp Terraform with the Terraform provider for Google Cloud, which defines resources in files that can be versioned, reused, and shared through a consistent lifecycle workflow. Infrastructure Manager (Infra Manager) automates the deployment and management of those Terraform configurations programmatically on Google Cloud, so teams do not maintain a separate toolchain. Terraform Cloud and Terraform Enterprise add organization-wide change management, with Terraform Cloud running Terraform in a stable, remote software as a service (SaaS) environment that securely stores state and secrets.
| Tool | What it manages | Choose when |
|---|---|---|
| HashiCorp Terraform | Resource definitions and lifecycle workflow | The need is general configuration and management of Google Cloud infrastructure using code |
| Infrastructure Manager | Programmatic deployment of Terraform configurations on Google Cloud | The need is to automate deployment of an existing Terraform configuration without a separate toolchain |
| Terraform Cloud and Terraform Enterprise | Remote runs, state, secrets, version control system (VCS) integration, and API-driven workflows | The need is full change management across the organization, with Terraform Enterprise as the self-hosted distribution |
Terraform Cloud connects a workspace to GitHub, GitLab, and Bitbucket, so new commits can automatically trigger Terraform plans, and its API integrates Terraform runs into existing workflows. Infra Manager depends on the Terraform configuration as its input, while Terraform Cloud depends on the connected repository and stored state to coordinate plans and applies across teams. Choose Terraform to author reusable modules, Infra Manager to execute them natively on Google Cloud, and Terraform Cloud or Enterprise when remote state, secrets, approvals, and audit across many workspaces become the constraint.
Exam tip: Use Terraform to define infrastructure, Infrastructure Manager to automate deployment of that Terraform on Google Cloud, and Terraform Cloud or Enterprise when you need remote state, secrets, and VCS-triggered change management.
Secure and isolated environment design for ephemeral use gives each short-lived environment its own boundary for identity, network, and data so test activity cannot leak into staging or production. A common pattern provisions a dedicated Google Cloud project per ephemeral instance using the project-factory module, which creates an opinionated project with Shared VPC attachment, Identity and Access Management (IAM) bindings, and enabled APIs. The network module then creates a new Virtual Private Cloud (VPC) network inside that project, while folders, organization policy, and VPC Service Controls modules place the project under the correct folder hierarchy and apply perimeter and policy guardrails.
Trust flows from identities to resources through IAM, where permissions determine which users and service accounts can access repositories, projects, and data. The pipeline runs as a dedicated service account with least-privilege roles, and application workloads receive their own service accounts created by the service-accounts module rather than reusing the pipeline identity. Secrets and encryption are also declared in code through the secret-manager module for secrets and permissions and the kms module for keyrings, keys, and per-key IAM bindings. For network isolation, traffic from the ephemeral VPC flows only to explicitly allowed Google APIs and peered services, with Cloud NAT, Cloud DNS, and Secure Web Proxy controlling egress and name resolution when the environment must remain private.
CI/CD integration for ephemeral provisioning connects source control events and schedules to IaC execution, artifact storage, and promotion. Cloud Build imports source from Cloud Storage, Cloud Source Repositories, GitHub, or Bitbucket, executes the build to specification, and produces artifacts such as Docker containers or Java archives. Artifact Registry provides a single location for managing packages and container images across the full artifact lifecycle and integrates with CI/CD tools and runtime environments. Cloud Deploy then automates delivery of those artifacts to a series of target environments in a defined promotion sequence, which lets a validated ephemeral build move from dev to staging to prod without rebuilding.
An automated ephemeral lifecycle preserves order from request to cleanup:
validate and plan, so syntax errors and unintended resource changes are caught before any infrastructure changes state.Configuration templates accelerate this flow without sacrificing consistency. Modular Terraform configurations and curated blueprints (opens in a new tab), such as Cluster Toolkit blueprints for Slurm or GKE-based high-performance computing and AI clusters and the large catalog of Google Cloud Terraform modules for BigQuery, Pub/Sub, Cloud SQL, Memorystore, and load balancing, provide ready-to-use starting points that teams customize and store in version control. In Kubernetes-centric designs, Config Connector manages Google Cloud resources as Kubernetes objects from YAML manifests deployed to the GKE cluster, so application and infrastructure configuration update together through the same pipeline with templating for environment differences.
Implementing policies for security and configuration management means ephemeral environments inherit the same organization-level guardrails as production, even though their projects and resources are short-lived. An ephemeral project is created under the organization hierarchy, so Organization Policy constraints, VPC Service Controls perimeters, identity controls, and audit logging still apply to every API request, virtual machine, and service account inside it. This inheritance prevents temporary development, testing, or staging environments from becoming a weaker path into production data.
Organization Policy is the centralized control that enforces allowed configurations across all projects, including ephemeral ones that are created and deleted frequently. Two constraints directly reduce long-lived credential risk: constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload. When enforced, these constraints block creation and upload of downloadable service account keys (opens in a new tab), which otherwise persist in downloaded key files, in gcloud CLI configuration files, and potentially in code repositories where an attacker with filesystem access could copy them.
Because ephemeral automation often creates service accounts on demand, the policy forces workloads to use more secure alternatives instead of persistent keys. Combined with the principle of least privilege in Identity and Access Management (IAM), users receive only the roles required for a task at the smallest scope, and administrators review role recommendations to remove unused or excessive grants. The dependency is explicit: the ephemeral workflow depends on the organization policy, and the policy applies to every child project before any workload identity is provisioned.
VPC Service Controls is a resource-centric control that defines a service perimeter within which Google Cloud resources can communicate. Chrome Enterprise Premium is a user-centric control that evaluates attributes on every API request, including IP-based access or certificate-based access for mutual TLS, and rejects user API traffic that does not meet the defined access level and binding. Requests that use compromised authorization credentials but do not meet the Chrome Enterprise Premium conditions are rejected, although not all device attributes collected by Endpoint Verification are evaluated on every request.
Traffic flows from the user or service account to the Google API, and then the two controls check different sides of the trust boundary. VPC Service Controls checks whether the target resource and calling identity are inside the same perimeter, while Chrome Enterprise Premium checks whether the calling user and device meet context conditions. When used together, they reduce the effectiveness of compromised credentials on an attacker-controlled machine outside the environment.
| Control | Applies to | What it enforces |
|---|---|---|
| VPC Service Controls | All user identities and service account identities | Resources communicate only within the defined perimeter |
| Chrome Enterprise Premium | Only user identities within the organization | User API traffic is allowed only when per-request conditions are met |
Exam tip: VPC Service Controls covers service accounts and users, while Chrome Enterprise Premium covers only organization user identities — ephemeral automation that runs as a service account still needs a VPC Service Controls perimeter.
Hardened remote access for ephemeral Compute Engine instances centers on OS Login with 2-Step Verification. When developers access instances over SSH, OS Login with 2-Step Verification adds a checkpoint where the user must reauthenticate with a password or security key. An attacker holding compromised OAuth tokens but lacking the password or security key is blocked at that second checkpoint because authentication flows from the user to the instance only after both factors succeed.
Remote Desktop Protocol (RDP) to Windows instances does not support the OS Login service, so 2-Step Verification cannot be granularly enforced for RDP sessions. When access uses Identity-Aware Proxy (IAP) Desktop or Chrome-based RDP plugins, compensating controls apply to the user's web session: set coarse-grained session length for Google services and 2-Step Verification settings, and disable the Allow user to trust the device setting. For ephemeral Windows test machines, this means the RDP path depends on session policy rather than per-instance OS Login enforcement.
Just-in-time privilege for short-lived work provides temporary elevated access with justification recorded for auditing instead of standing administrative roles. Privileged Access Manager (PAM) (opens in a new tab) manages just-in-time privilege elevation and retains audit logs showing who had access to what and when. Permanent assignments stay at least-privilege, while PAM provides time-bound elevation that can be scoped, approved, and withdrawn after the task completes.
PAM fits recurring ephemeral scenarios:
A lighter alternative is a Google Group that holds the temporary role, such as emergency-compute-access@example.com granted roles/compute.admin. Access flows from the user to group membership to the protected resource, and membership expiration removes access automatically. A related pattern delegates privilege through service account impersonation: create a privileged service account, grant it the needed role, grant the group roles/serviceusage.serviceUsageConsumer on the project, and grant the group roles/iam.serviceAccountTokenCreator on the service account. Users then impersonate the service account only while they are members, and Cloud Audit Logs with ADMIN_READ, DATA_READ, and DATA_WRITE for compute.googleapis.com records the privileged use.
Continuity governance requires emergency access in every environment, not only production, because loss of access to testing or staging is still disruptive. Emergency access users (opens in a new tab) are last-resort accounts created in Cloud Identity or Google Workspace with the super admin privilege, exempt from single sign-on (SSO) and exempt from the Joiner, Mover, and Leaver lifecycle because they are not tied to a specific employee. That privilege lets them resolve misconfigurations affecting identity or Google Cloud resources when federated authentication is unavailable.
Redundancy and isolation keep that last-resort path available and controlled:
Endpoint and response readiness closes the remaining gap around trusted devices. If an attacker compromises a developer workstation or an ephemeral instance, the attacker can run gcloud CLI commands directly on that trusted endpoint and reuse cached credentials. Governance therefore reviews physical workstation security, network breach detection, SSH and RDP remote-access paths, replacement of persistent SSH keys and service account keys with short-lived credentials, risks of shared devices and untrusted-device gcloud authentication, and how approved traffic enters the VPC Service Controls perimeter. Security teams responsible for incident response hold appropriate access across the Google Cloud console and Admin console in advance, so ephemeral projects remain diagnosable under the same operational model as permanent workloads.
Ephemeral environment lifecycle and cost control is the practice of automatically creating short-lived, non-production environments in isolated projects and then tearing them down on schedule while tracking every dollar they consume. The lifecycle depends on project-level isolation, scheduled teardown triggers, and cleanup controls, while cost control depends on Cloud Billing budgets, project labels, and billing export to BigQuery. Together they keep development, testing, and preview environments operationally consistent and prevent idle resources from generating continued billing.
Automated lifecycle policies define when an ephemeral environment is created, how long it lives, and what trigger destroys it without manual intervention. The pattern starts with an isolated Google Cloud project created with Project Factory, which configures the project with Shared VPC, Identity and Access Management (IAM), and Google Cloud APIs, so all ephemeral resources share one boundary that can later be deleted at once. A time-based trigger then drives teardown, using Cloud Scheduler (opens in a new tab) to trigger a run, Cloud Workflows with Cloud Scheduler or Eventarc triggers to orchestrate steps, or the scheduled-function module that sets up a scheduled job to trigger events and run functions.
The ephemeral lifecycle moves through an ordered sequence:
Because the teardown trigger depends on the scheduler and the workflow depends on the isolated project, expiration reliably removes compute, storage, and container resources even when developers forget manual cleanup.
Resource cleanup controls remove leftover objects inside an ephemeral environment that project deletion might miss or that need to age out before deletion. Cloud Storage lifecycle management automatically transitions or deletes objects, with deletion rules that evaluate object conditions and a requirement to ensure the isLive condition is False for deletion rules so only noncurrent versions are removed. Artifact Registry provides a single location for packages and container images and supports cleanup policies that delete old test images, while Cloud Storage also supports SetStorageClass lifecycle rules to move aging test data to cheaper classes before deletion.
The documentation supports three peer cleanup controls for short-lived environments:
isLive set to False.When these controls apply to the ephemeral project, storage and artifact costs stop accumulating between runs and the next environment starts from a known-empty state.
Cost monitoring for ephemeral environments uses Cloud Billing budgets and alert thresholds to detect overspending across many short-lived projects. The foundation pattern uses a single billing account across all projects in the organization, assigns each project a billingcode metadata label for cost-center allocation, and sets budgets with alert thresholds for workload projects. The blueprint creates budget alerts for workload projects when forecasted spending is on track to reach 120% of the budget, which lets a central team identify significant overspending that can also indicate a security incident.
To estimate before launch, generate a cost estimate based on projected usage with the pricing calculator. For day-to-day ownership, delegate budget and alert setting to workload owners who can set more granular thresholds for their ephemeral namespaces, and use FinOps hub guidance for ongoing optimization.
Exam tip: Budget alerts notify about consumption of budgets you define for each project, while Billing notifications from Essential Contacts notify about pricing updates, errors, and credits.
Cost attribution for ephemeral environments assigns shared billing data to internal cost centers using labels and exported billing records. The console billing reports show cost and forecast in multiple dimensions, but for custom allocation export Cloud Billing data to a BigQuery dataset in the prj-c-billing-export project. Billing records flow from Cloud Billing to the BigQuery export table, and a query groups charges by the billingcode project label to calculate charges and credits per cost center.
| Teardown scope | What is removed | Choose when |
|---|---|---|
| Delete the project | The project and all resources associated with the project | The ephemeral environment used a dedicated project and nothing must be retained |
| Delete individual resources | Only the resources created for the task | The environment shared a project where other work must continue |
After export, incorporate the grouped results into internal chargeback, since allocation by billingcode is what connects a short-lived environment to the team that requested it. Choosing project deletion removes the entire boundary at once, while choosing individual resource deletion preserves other work in a shared project. The choice depends on whether the ephemeral environment used a dedicated project and whether anything must be retained.
constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload block creation and upload of downloadable service account keys.billingcode project label, with budget alerts firing when forecasted spending reaches 120% of budget.Virtual Private Cloud Service Controls is a resource-centric control that defines a service perimeter within which Google Cloud resources can communicate and applies to all user identities and service account identities, while Chrome Enterprise Premium is a user-centric control that evaluates attributes on every API request and applies only to organization user identities. When used together, they reduce the effectiveness of compromised credentials on an attacker-controlled machine outside the environment.
Use HashiCorp Terraform to define resource definitions and lifecycle workflow in versioned files, use Infrastructure Manager to programmatically deploy those existing Terraform configurations on Google Cloud without a separate toolchain, and use Terraform Cloud or Terraform Enterprise when you need full change management with remote runs, state, secrets, and version control system integration. Terraform Cloud connects a workspace to GitHub, GitLab, and Bitbucket so new commits can automatically trigger Terraform plans.
The ordered lifecycle is provision a dedicated project for the short-lived environment, deploy the workload with Cloud Deploy to the non-production target, expire on the scheduled trigger, time-to-live, pull-request close, or test completion condition, then teardown by deleting the project boundary. Because teardown removes the project and all resources associated with the project, expiration reliably removes compute, storage, and container resources even when developers forget manual cleanup.
Export Cloud Billing data to a BigQuery dataset in the prj-c-billing-export project, where a query groups charges by the billingcode project label to calculate charges and credits per cost center for internal chargeback. Budget alerts for workload projects fire when forecasted spending is on track to reach 120% of the budget, which lets a central team identify significant overspending that can also indicate a security incident.
Your enterprise uses automated CI/CD pipelines that dynamically provision ephemeral Google Cloud projects to run integration tests and validate containerized workloads. These temporary environments create Compute Engine instances, Cloud Storage buckets, and analytical clusters before being destroyed.
Your security team mandates the following governance requirements for all ephemeral environments:
Which combination of Google Cloud security controls and configuration management policies should you implement?
Last updated