Securing Cloud Workstations and Developer Environments

Identity, network, and encryption controls for cloud development environments keep developer desktops productive while preventing data from leaving trusted boundaries. Cloud Workstations (opens in a new tab) centralizes developer machines inside Google Cloud, Identity and Access Management (IAM) controls who can use them, private networking controls how traffic moves, and perimeter encryption controls where data can go.

1.1Identity and Access Control for Developer Workstations

Granular IAM for developer access means granting only needed roles at the smallest scope, preferably to groups rather than individuals. A group for application developers receives roles for services such as Gemini Code Assist or Cloud Workstations, which simplifies auditing and avoids sprawl from individual bindings. Assignments follow least privilege with regular review of role recommendations, while authentication is hardened with Cloud Identity, single sign-on, 2-Step Verification, and password requirements.

Access to a workstation itself depends on the Cloud Workstations User role and a short-lived token flow. Traffic flows from the caller to the generateAccessToken API, which returns a bearer token, and the caller then presents that token to the workstation as an Authorization: Bearer TOKEN header or as the _workstationAccessToken=TOKEN URL parameter that sets a browser cookie. The token remains valid until expiration and cannot be revoked, so workstations must stay single-user by default and teams should share individual ports instead of the whole workstation. Any user with workstation access can reuse user credentials or Application Default Credentials (ADC) created inside it, which makes workstation IAM the primary trust boundary for credential reuse.

Service accounts provide an alternative when users must not hold broad permissions. A workstation configuration (opens in a new tab) can specify a service account and scopes such as https://www.googleapis.com/auth/cloud-platform, and users of that configuration must hold iam.serviceAccounts.actAs on that service account to impersonate it. For SSH, OS Login with 2-Step Verification forces reauthentication with a password or security key, which blocks an attacker who holds stolen OAuth tokens but lacks the second factor. Remote Desktop Protocol (RDP) to Windows Compute Engine instances does not support OS Login, so administrators must use coarse controls such as Google session length, web-session verification, and disabling device trust.

1.2Network Isolation and Private Connectivity for Workstations

Network isolation for development environments separates developer compute from the public internet while keeping routing under central control. Shared VPC provides that topology by letting a central host project own the network while service projects hold workstations and workloads. By default, traffic flows from developer IDEs over encrypted TLS on the internet to Google Front End (GFE), the global edge that routes and load balances traffic, provides DDoS protection, and hands traffic to internal ALTS-encrypted connections between Google services.

Private connectivity replaces internet traversal when compliance or reliability requires it. Traffic flows from the corporate network to Google Cloud through Cloud VPN or Cloud Interconnect as a dedicated path, and VM-to-VM traffic within and peered VPC networks is integrity-protected and encrypted by default. Managed SSL certificates and external Application Load Balancers add Layer 7 encryption for internet ingress. To prevent exfiltration, projects enable Private Google Access and direct Google API traffic to restricted.googleapis.com, so approved traffic stays inside the perimeter and central policy controls egress.

1.3Perimeter Controls to Prevent Data Exfiltration

Perimeter controls to prevent data exfiltration combine a resource-centric perimeter with a user-centric check evaluated on every API request. VPC Service Controls defines a service perimeter around Google-managed services that blocks data movement outside the perimeter and blocks access from untrusted locations. Chrome Enterprise Premium (formerly BeyondCorp Enterprise) defines access levels and bindings that allow only requests meeting conditions such as IP-based access or certificate-based access for mutual TLS.

The two controls cover different identities and resources, so they are strongest together:

Not all device attributes collected by Endpoint Verification are evaluated on every request, so access levels must rely only on attributes actually enforced per request. Third-party connectors that call public endpoints outside Google Cloud fall outside VPC Service Controls by design, and that egress must be constrained by granular VPC firewall rules that allow only the fully qualified domain names (FQDNs) of approved services.

1.4Encryption, Key Control, and Credential Hygiene

Encryption, key control, and credential hygiene protect workstation data and authentication secrets even if files or tokens leak. Cloud Key Management Service (Cloud KMS) supports Customer-Managed Encryption Keys (CMEK) for sensitive material such as authentication secrets that Developer Connect stores in Secret Manager. The Developer Connect service account must hold the Cloud KMS CryptoKey Encrypter/Decrypter role to use that key. Extra encryption adds cost, latency, and complexity, so CMEK is chosen when regulatory compliance or centralized key revocation and rotation outweighs default Google-managed encryption.

Persistent credentials are the highest-risk secret in development environments. When a service account key authenticates the gcloud CLI, the key value is stored in gcloud CLI configuration files apart from the downloaded key file, so an attacker with file-system, endpoint, or repository access can copy it. Hardening requires enforcing the constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints and replacing persistent keys with short-lived alternatives such as impersonation, ADC through gcloud auth application-default login, or workload federation. Code run directly on a trusted workstation or Compute Engine instance also bypasses network checks, so reviews must cover SSH keys, shared-device caching, untrusted-device authentication, perimeter entry points, physical security, and aligned incident response.

1.5Workstation Templates, Images, and Lifecycle Configuration

Customization and lifecycle configuration (opens in a new tab) of Cloud Workstations defines reproducible developer environments as templates and controls how compute, storage, and software change over time. A workstation configuration acts as the template that specifies the virtual machine (VM) type, persistent storage, container image, integrated development environment (IDE), timeouts, and access policy for every workstation created from it. Updates to the configuration apply automatically the next time each workstation restarts, so platform teams standardize tooling while developers start and stop ephemeral environments on demand.

A workstation cluster defines a group of workstations in a particular region and the Virtual Private Cloud (VPC) network they attach to, and it routes each workstation's unique hostname to the running workstation. Each developer then creates a workstation from the configuration, which runs on a Compute Engine VM with a persistent disk attached for data between sessions. Custom container images standardize those environments by extending base images with pre-installed tools, pushing the result to Artifact Registry, and referencing it in the container.image field. Teams should rebuild custom images when the base image updates and scan added dependencies with Artifact Analysis.

Base images share a defined startup structure anchored by the entrypoint /google/scripts/entrypoint.sh. On startup the container runs files under /etc/workstation-startup.d/ in lexicographical order to initialize Docker, create the default user, start Secure Shell (SSH), run per-user customization, and start the IDE. The persistent disk for /home is dynamically attached at runtime and overwrites any /home changes made at image build time. Users must therefore be added on startup, not in the Dockerfile, and per-user files such as git configuration and $HOME/.config content must move to a runtime script or /etc/profile.d. Lighter customization uses the per-user script at /home/user/.workstation/customize_environment, which runs once in the background as user at workstation start.

The workstation lifecycle separates ephemeral compute from durable home data to save cost and enforce updates. When a workstation starts without pooling, Cloud Workstations performs an ordered sequence:

1. Create VM: A new ephemeral Compute Engine VM is created from the configuration's machine type.
2. Pull image: The workstation container image is pulled onto the VM.
3. Create disk on first start: A persistent disk for /home is created the first time the workstation starts.
4. Attach disk: The persistent disk is attached to the VM.
5. Start and mount: The container starts on the VM and mounts the disk to /home in the container.

When the session ends, the VM and runtime data are deleted while the disk is detached and retained until the workstation is deleted. Timeout and pooling controls bound cost and accelerate starts:

The two timeouts are independent, suspending does not reset runningTimeout, and daily restarts are recommended so security updates apply.

1.6Cloud Shell Administration and Secure Authorization

Cloud Shell administration treats the ephemeral Cloud Shell terminal as a secure control plane while preserving work in its persistent home directory. Cloud Workstations and Cloud Shell provide the Google Cloud CLI (gcloud CLI) pre-authorized to the active project through the $DEVSHELL_PROJECT_ID environment variable, and administrators use it to enable APIs, create service accounts, and apply IAM policies. Files saved to the home directory persist across sessions, while compute itself remains ephemeral and subject to access, quota, and storage constraints.

Secure gcloud CLI authorization establishes both user credentials and ADC for API calls. The authorization flow follows an ordered sequence:

1. Open terminal: Open a terminal in the workstation IDE.
2. User login: Run gcloud auth login --no-launch-browser and follow the prompts.
3. Set project: Run gcloud config set project PROJECT_ID to bind commands to the target project.
4. Enable ADC: Run gcloud auth application-default login to create ADC for service calls.
5. Persist credentials: Credentials are saved so future sessions reuse the same authorization.

On Linux and macOS the ADC file lives at $HOME/.config/gcloud/application_default_credentials.json, while on Windows it lives at %APPDATA%\gcloud\application_default_credentials.json. The owner-driven recovery path after compromise is revoke with gcloud auth application-default revoke, delete application_default_credentials.json if needed, and only then recreate with gcloud auth application-default login. Large-scale revocation uses the Google Workspace Admin SDK to invalidate tokens for the gcloud CLI client ID 32555940559.apps.googleusercontent.com, which forces password or security-key reauthentication. Diagnosing failures means separating permission errors such as The caller does not have permission from misconfigurations such as a wrong PATH_TO_METADATA_XML path, incorrect Assertion Consumer Service (ACS) and Entity ID URLs causing missing session ID, or a JWT larger than 4KB that requires filtering the groups claim at the identity provider.

Bootstrapping environments with required tooling defines approved versions once in code and ships those same versions to every developer through rebuilt images. In Google Cloud, Cloud Workstations consumes custom container and OS images, Artifact Registry stores and scans those images, Cloud Build (opens in a new tab) rebuilds and validates them, and Cloud Scheduler triggers rebuilds on a schedule. This system is operated as a custom image pipeline so teams do not drift to unapproved gcloud, kubectl, Terraform, or base-image versions.

2.1Defining and Distributing Approved Toolchain Versions

Approved toolchain versions are version-controlled configuration files stored in Git, not manual installs on individual workstations. A Dockerfile defines the custom workstation image contents, an imagebuilder.yaml recipe defines OS customization, and a cloudbuild.yaml file defines the build, validate, and publish steps that run in order. Terraform files pin the automation itself with required_version = ">= 1.3" and hashicorp/google provider version = ">= 5.0, < 7.0", plus input validation such as project_id matching ^[a-z0-9-]{6,30}$. Data flows from the Git repository to the Cloud Build trigger to the builder containers, so a change only takes effect after it is committed, built, and published.

Distribution happens through Artifact Registry repositories that host versioned images for all teams. A Docker-format repository is created with gcloud artifacts repositories create, and Docker is authenticated with gcloud auth configure-docker. The registry sits between the build system and development environments as a trust boundary: Cloud Build writes images on one side, and Cloud Workstations and Compute Engine consume images on the other side. Enabling Container Scanning on the repository adds vulnerability scanning for each pushed image, which helps ensure only scanned, approved images are promoted.

Automated rebuilds prevent version drift by reconstructing images from the current approved base on every trigger. The pipeline follows an ordered sequence:

1. Customize: The builder:stable container runs /build on a worker VM to apply OS customization and package updates.
2. Validate: The validator:stable container runs /validate on a test VM to perform system boot checks.
3. Publish: The builder:stable container runs /publish to register the image and upload artifacts to Artifact Registry.

Builds are launched by a Cloud Build trigger linked to a Developer Connect GitHub connection and by Cloud Scheduler for recurring rebuilds. The pipeline uses a Cloud Storage workdir bucket for temporary logs and artifacts, with defaults such as a 30-day lifecycle, timeout: '3600s', and logging: CLOUD_LOGGING_ONLY. The Google Cloud CLI (gcloud CLI) itself is kept consistent by installing, signing in, and running gcloud init, but gcloud components update updates only the local CLI. Team-wide enforcement requires committing the new version to Git and rebuilding the custom image, then restarting workstations from the republished image.

2.2Building and Validating Compliant Machine Images

Custom machine images for baseline compliance are prebuilt boot disks that embed hardening, security agents, logging, and standard tooling so every virtual machine (VM) starts compliant. Baking compliance into the image shifts security left because policy is enforced at creation time rather than fixed after launch. Baked images reduce boot time because software is already installed, improve deployment reliability, make rollback straightforward, and reduce startup dependencies on external services.

Compute Engine custom images can be created by manual baking, automated baking, or importing existing disks. Manual baking follows an ordered sequence:

1. Create an instance from a public image: Start a VM from a Google-supported public image as the clean baseline.
2. Connect and customize: Install hardened packages, security agents, logging, and baseline tooling.
3. Stop the instance: Stop the VM to make disk state consistent for capture.
4. Create the image from the boot disk: Create the custom image from the boot disk, which requires deleting the instance while keeping the boot disk.
5. Test and publish: Launch a new instance from the image to verify function before sharing it as the team standard.

Manual baking works for a small number of images. Automated baking with Packer makes creation reproducible and auditable for large numbers of images and can run as part of a Spinnaker pipeline. Importing uses the virtual disk import tool for RAW disks, Amazon Machine Images (AMI), and VirtualBox images, or uses Migrate to Virtual Machines with continuous block-level replication. A hardened image is validated by launching a test VM and verifying licenses through the metadata server, Python 2.6 or greater, baseline tools including gcloud, ssh, sshd, curl, and dhcp, and confirming no extra user directories or leftover credentials remain.

2.3Managing Image Lifecycle, Encryption, and Supply Chain

Image families manage related Compute Engine images as a versioned line so automation can roll forward to the latest compliant build and roll back when needed. Deployment mechanisms must reference the family pointer rather than a fixed image so they pick up the latest version. Deprecation moves an image through named lifecycle states in order, from warning to blocking to removal:

Image encryption and source control ensure baseline images protect data at rest and come only from approved publishers. All Compute Engine disks are encrypted by default, and images built from those disks inherit that encryption. For stronger ownership, disks can be created with customer-supplied encryption keys passed to the image create command. Trusted image organization policy constraints limit which projects can publish usable images, while Artifact Registry centralizes artifacts with access control and VPC Service Controls perimeters.

Centralized artifact controls further harden the supply chain:

• Assured Open Source Software supplies packages built in secure pipelines and regularly scanned and tested for vulnerabilities.
• Artifact Registry remote repositories cache artifacts from Docker Hub, Maven Central, Python Package Index (PyPI), Debian, CentOS, and user-defined sources.
• Artifact Registry virtual repositories consolidate same-format repositories behind one endpoint and prioritize private packages, which reduces dependency confusion attacks.
• Artifact Analysis provides on-demand or automated scanning of base images and language packages, plus generation of a software bill of materials (SBOM) and Vulnerability Exploitability eXchange (VEX) statements.

Cloud Workstations extends the hardened-image model to developer desktops with VPC Service Controls, private ingress or egress, forced image update, and IAM access policies. Container baselines use the same chain of trust: Cloud Build provides isolated builds with SLSA Level 3 support and provenance recording image digests and source locations, and Binary Authorization enforces deployment policy on Google Kubernetes Engine (GKE) and Cloud Run by checking attestations for build origin, vulnerability policy, and promotion criteria.

2.4Automating IDE Configuration and Enforcing Standards

Automated IDE configuration defines development environments in code so every developer receives the same editor, extensions, rules, and security checks. The base is a consistent image or managed workspace, the IDE layer is Visual Studio Code (VS Code) or JetBrains IDEs with Cloud Code support, and enforcement comes from pre-installed validators, in-IDE scans, and automated builds on repository events. Because the image and workspace definition are stored in version control, updating the image updates every new environment without manual installation.

The dependency flows from base image to workspace to IDE: the custom image supplies commands and tools, the workspace instantiates that image for each developer, and Cloud Code connects the IDE to Google Cloud services. Automated extension integration pre-configures plugins, API access, and workspace rules, including the documented pattern for the Developer Knowledge API and Model Context Protocol (MCP) access for AI-assisted IDEs. Provisioning follows an ordered sequence of enabling developerknowledge.googleapis.com, adding the Google plugins marketplace, installing the developer plugin, creating and exporting the API key, and wiring the MCP server entry so requests carry the key.

Enforcing standards means running the same checks in the IDE, as a pre-commit hook, and in continuous integration:

• Local fast check: Developers run validators such as nomos vet to confirm syntax, with nomos vet --clusters "" to restrict to semantic checks without cluster access.
• Pre-commit enforcement: The validator is installed as a Git pre-commit hook so invalid changes are rejected before leaving the workstation.
• Pipeline gate: Cloud Build runs the validator from a container image on every change request.

Baseline scans evaluate code for errors, hardcoded secrets, and vulnerable dependencies, while Wiz Code blocks non-compliant builds and Wiz Green Agent refactors code in the IDE or creates pull requests. Rebuilds are scheduled with Cloud Scheduler so patched images flow to new workstations, with guardrails from Cloud KMS for CMEK, OS Login with 2-Step Verification for SSH, and organization constraints that eliminate long-lived service account keys.

Gemini assistance on Google Cloud accelerates development and operations through IDE coding help, console operational help, and command-line generation, all bounded by IAM, privacy, and network governance. Gemini Cloud Assist (opens in a new tab) designs, troubleshoots, and optimizes workloads, Gemini Code Assist generates and debugs code in the IDE, and Gemini in the CLI synthesizes operational commands. Every output must be validated before use because models can produce plausible but incorrect results.

3.1Conversational Help, Investigations, and Proactive Triage

Context-aware conversational assistance in the console is help that understands which project and page the operator is viewing. The Cloud Assist panel is available from any Google Cloud console page and from the Cloud Mobile App, and it builds answers from the project ID, organization ID, current page URL and visible text, and session history. This context flow grounds an error message in the correct resource instead of giving a generic answer. Access follows the same pattern across services: open the resource page first so page context is correct, then open the Cloud Assist panel and enter a prompt.

Gemini Cloud Assist Investigations is the structured tool for root-cause analysis of complex outages. An investigation ingests logs, metrics, and configurations, tests multiple hypotheses in parallel, and traces causes across multi-tier topologies. Data flows from the triggering error, resource, or natural-language prompt into the investigation engine, and the engine returns ranked observations, hypotheses about likely root causes, and recommended next steps. Creating an investigation from chat follows an ordered workflow:

1. Ask for help in chat: Describe the issue in the Cloud Assist panel, and Gemini shows a Create investigation button when an investigation would help.
2. Open the creation panel: Click Create investigation to open a panel pre-filled from the chat.
3. Refine the scope: Edit resources, time ranges, logs, or symptoms that define the outage.
4. Run and review: Click Create to run, then review ranked observations and hypotheses on the Investigation details page.

An investigation can also start manually from More actions > New investigation, or directly from Logs Explorer and resource-specific pages. Using investigations requires the Investigation Creator IAM role, and moving results into a support case requires a support package.

The three diagnostic modes differ by trigger and depth:

Chat fits single errors such as CrashLoopBackOff, NotReady nodes, HTTP 429, HTTP 404, or 5XX messages. Investigations fit problems spanning code and infrastructure such as high latency on an api-gateway service. Proactive investigations fit high alert noise where the team wants clustered alerts before human triage.

3.2Performance, Cost, Security, and Incident Troubleshooting

Performance troubleshooting with Gemini Cloud Assist connects infrastructure signals to application behavior and, where supported, to application code. Google Kubernetes Engine (GKE) assistance can explain Pod errors such as nil-pointer panics, recommend latency-related metrics, and outline node troubleshooting including auto-repair concepts. Cloud Run chat analyzes container logs to pinpoint scaling, startup-time, traffic-spike, ingress, or project-state problems, while investigations add ranked hypotheses and, for services deployed from source, code-fix suggestions in the Source tab.

Database and analytics troubleshooting applies the same pattern across managed services:

• Cloud SQL for PostgreSQL
• Cloud SQL for MySQL
• AlloyDB for PostgreSQL
• BigQuery, Managed Service for Apache Spark, Spanner, and Bigtable

Gemini helps find slow SQL queries, manage slot reservations, troubleshoot bottlenecks, and configure data environments. Typical prompts ask for current CPU use, highest-latency queries, error-log counts, or fleet-wide health. For Bigtable, an investigation compares baseline data against client latencies, server latencies, CPU use, disk use, and request count, then lists misconfigurations with actionable hypotheses.

Resource optimization combines Recommender-based rightsizing with Cloud Hub cost analysis. The Cloud Assist panel surfaces recommendations for savings, cluster reliability, idle VMs, nearly exhausted quotas, and BigQuery datasets that should be partitioned or clustered. This workflow depends on the Recommender API and Recommender Viewer role. Cost investigation depends on Cloud Hub and the App Optimize API with the Cloud Hub Operator role, reporting recent changes, per-application or per-project spend, and explanations for changes. Support handoff preserves context by summarizing environment state, filling case fields from chat, and passing investigation results to human engineers when limits are reached, with integrations to Slack, WhatsApp, and ServiceNow.

Incident awareness separates a Google Cloud platform incident from a problem inside the user's project. When the Service Health API is enabled and the user has the Service Health Viewer role, prompts about Compute Engine, Cloud Storage, or BigQuery return incident status, project impact, and workarounds. Security and artifact findings are handled by specialized workers that triage Security Command Center findings into remediation steps and answer Artifact Registry questions about image vulnerabilities.

3.3IAM, Privacy, and Perimeter Governance for AI Assistance

IAM policies for Gemini assistance control which principals can invoke models and which product data they can reason over. Access to Gemini Cloud Assist requires roles/geminicloudassist.user and roles/cloudasset.viewer, while access to Gemini Code Assist and console Gemini features requires roles/cloudaicompanion.user and roles/serviceusage.serviceUsageConsumer. Permissions only work when the enabling API is active in the same project where roles are granted. To manage roles at scale, grant required roles to a developer group rather than individuals, apply least privilege, and add product-specific roles only when needed.

Custom roles for Gemini Code Assist Standard and Enterprise must contain permissions to invoke assistance, enable services, and read effective settings, including cloudaicompanion.instances.completeCode, completeTask, generateCode, generateText, exportMetrics, queryEffectiveSetting, queryEffectiveSettingBindings, and serviceusage.services.enable. License administration uses a separate set under consumerprocurement.orders. Authentication flows from Cloud Identity, Google Workspace, or federated identity, with single sign-on, 2-step verification, and password requirements before any IAM role takes effect.

Data privacy starts from the definition of Customer Data and the stateless design of the models. Gemini handles prompts, responses, conversation history, snippets of open and adjacent files, and cursor location as Customer Data under the Cloud Data Processing Addendum. The large language model instances behind the Gemini for Google Cloud API are stateless and shared by all customers, so prompts and responses are not stored by default. Only when an administrator configures logging does input and output flow to a Cloud Logging bucket. Gemini Cloud Assist can store data in any Google Cloud data center globally, so residency-sensitive or CMEK workloads should not enable the API.

Governance boundaries separate untrusted access paths from trusted services. Traffic flows from workstations over TLS to GFE, which routes the prompt to the Gemini for Google Cloud API. That API is built for Google-provided clients only and has no access to other APIs or resources in the customer project. VPC Service Controls provides the perimeter boundary, and when used, the Gemini APIs must be added to the perimeter with explicit ingress policies for outside principals. Enabling assistance follows an ordered dependency of enabling geminicloudassist.googleapis.com, enabling supporting APIs such as cloudasset.googleapis.com and appoptimize.googleapis.com, and then granting IAM roles in the same project.

3.4Secure Software Development with Gemini Code Assist

Gemini Code Assist (opens in a new tab) Standard and Enterprise is an AI coding assistant that runs inside the developer's IDE to generate, explain, refactor, and debug code. It works after setup for a project (opens in a new tab) and installation of the extension for Visual Studio Code or a supported JetBrains IDE, giving inline completions and conversational help through the Gemini panel. The models are trained on publicly available code and Google Cloud-specific material in addition to foundation models. Secure development still requires a secure software development lifecycle (SDLC), with AI output validated before use.

Code assistance means the extension proposes completions as the developer types and generates new code from natural-language prompts. The developer can select existing code and ask for targeted changes, including Write unit tests for my code, Help me debug my code, and Make my code more readable. The same pattern extends to analyzing existing code, identifying potential issues, and suggesting improvements for legacy codebases. Because the assistant sees conversation history, snippets of open and adjacent files, and cursor location, suggestions stay grounded in local context.

The enterprise architecture separates the developer environment, network path, and processing plane. Developer workstations or Cloud Workstations run the IDE extension, and traffic flows over TLS to GFE into the enabled project hosting the Gemini for Google Cloud API, which only provides access to stateless models. An optional VPC Service Controls perimeter can surround the API to block untrusted access and mitigate exfiltration. Data protection treats prompts and surrounding context as Customer Data (opens in a new tab) that is not stored by default unless Cloud Logging retention is configured. Organizations harden identity with single sign-on, 2-step verification, and password requirements, govern access with least-privilege group IAM bindings, and add Cloud VPN or Cloud Interconnect plus Shared VPC for network protection.

Key Facts

• Workstation access uses 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.
• Cloud Workstations separates ephemeral Compute Engine VMs from persistent disks mounted to /home, so Dockerfile changes to /home are overwritten at runtime and must be created from startup scripts.
• Workstation timeout defaults are idleTimeout 1200s with idleAction STOP and runningTimeout 43200s, and suspending does not reset runningTimeout.
• Approved toolchain versions are enforced by rebuilding custom images through Cloud Build and Artifact Registry, not by running gcloud components update on individual machines.
• Gemini Cloud Assist requires roles/geminicloudassist.user and roles/cloudasset.viewer, while Gemini Code Assist requires roles/cloudaicompanion.user and roles/serviceusage.serviceUsageConsumer in the project where the enabling API is active.