Prepare and test your skills
Prepare and test your skills
Security, Network Isolation, and Identity Access Management for cloud development environments is the set of identity, network, and encryption controls that keeps developer workstations usable while preventing data from leaving trusted boundaries. Cloud Workstations (opens in a new tab) centralizes developer desktops 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.
Granular Identity and Access Management for developer access means granting only the needed roles at the smallest scope, preferably to groups rather than individual users. A group for application developers receives roles for services such as Gemini Code Assist (opens in a new tab) or Cloud Workstations, which simplifies auditing and avoids sprawl from individual bindings. Assignments follow least privilege with regular review of role recommendations to remove unused permissions, while user 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 an authentication cookie for the browser session. 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 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 the service account to impersonate it. For SSH access, 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 2-Step Verification cannot be enforced granularly for RDP and administrators must use coarse controls such as Google session length, web-session verification settings, and disabling the option to trust the device.
Network isolation for development environments separates developer compute from the public internet while keeping routing and policy 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 to Google Cloud, 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 the Gemini for Google Cloud API then processes prompts through stateless large language model instances shared by all customers without gaining access to other APIs or resources in the customer project. Inside Google Cloud, VM-to-VM traffic within and peered VPC networks is integrity-protected and encrypted by default, while 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.
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 against compromised credentials used from an attacker-controlled machine:
| Control | What it protects | Which identities it covers |
|---|---|---|
| VPC Service Controls | Resources inside a service perimeter and communication between those resources | All user identities and all service account identities |
| Chrome Enterprise Premium | User API traffic that must meet device, IP, or certificate conditions on each request | Only user identities within the organization |
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 external services.
Exam tip: VPC Service Controls applies to all user and service account identities, while Chrome Enterprise Premium applies only to user identities in your organization — use both so stolen tokens fail the user check and stolen service account keys still hit the resource perimeter.
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 created by developer platforms, 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 (roles/cloudkms.cryptoKeyEncrypterDecrypter) 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 (opens in a new tab) authenticates the gcloud CLI, the key value is stored in gcloud CLI configuration files apart from the downloaded key file, so an attacker with access to the endpoint, file system, or code repository can copy it and impersonate the identity. 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 credential caching, authentication from untrusted devices, perimeter entry points, physical security, breach detection, and aligned incident response across the Google Cloud console and Admin console.
Customization and lifecycle configuration of Cloud Workstations (opens in a new tab) is the practice of defining reproducible developer environments as templates and controlling how their 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.
Workstation configurations are templates that define the runtime for workstations in a workstation cluster. 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. A workstation configuration defines the Compute Engine VM instance type, persistent storage, container image, IDE or code editor, and timeouts, while IAM rules grant use of the configuration to teams or developers. 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.
Administrators create and share configurations instead of asking developers to install software and run setup scripts. Because the configuration is versioned and reusable, changing the machine type, container image, or disk in the configuration changes the VMs used by associated workstations on their next restart. This model separates platform ownership of the template from developer ownership of the workstation instance and its home directory data.
Custom container images (opens in a new tab) standardize developer environments by extending Cloud Workstations base images with pre-installed tools, dependencies, language tooling, and automation. The recommended pattern is to build a Dockerfile FROM a preconfigured base image such as code-oss:latest, add static assets, push the result to Artifact Registry, and reference it in the container.image field of the workstation configuration. Teams are responsible for maintaining added packages and should set up a pipeline to rebuild custom images when the base image updates, plus run container scanning such as Artifact Analysis on added dependencies.
Custom images can be built in three ways that trade simplicity for control:
apt install packages and pre-installed IDE extensions./etc/workstation-startup.d/ to customize the running container at startup in lexicographical order.ENTRYPOINT to fully customize container startup.A fully custom Linux image is also supported when it runs a blocking process on start, such as sleep infinity or a config.container.args blocking command. Host custom images in Artifact Registry, and when the image lives in a private repository, configure the workstation configuration with a service account that has pull permission on the repository. Test locally with docker build and docker run --privileged -p LOCAL_PORT:CONTAINER_PORT, then push and create a configuration from the pushed image.
Base images (opens in a new tab) 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. Docker images used inside the workstation are stored at /home/.docker_data so they persist between sessions through the home disk.
The startup sequence creates strict build-time versus runtime boundaries because 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 workstation startup, not in the Dockerfile, by updating /etc/workstation-startup.d/010_add-user.sh or adding a later script, and per-user files such as git configuration, cloned repositories, and $HOME/.config content must move to a runtime script or /etc/profile.d. Custom runtime scripts run as root by default and should use a three-digit prefix greater than 200 to run after platform scripts, using runuser to drop to another user when needed.
Lighter customization without extending an image uses the per-user script (opens in a new tab) at /home/user/.workstation/customize_environment. All base images check for this executable file and, when present, run it once in the background as user at workstation start, unlike .profile or .bashrc which run per shell login. Logs are written to /var/log/customize_environment and container output logs, with /var/run/customize_environment_done created on success, so packages can become available moments after start without blocking startup.
Exam tip: Never bake users or /home files into the Dockerfile — the home disk mount overwrites /home at runtime, so create users and home content from /etc/workstation-startup.d/ or customize_environment.
Hardware, storage, and IDE selection in WorkstationConfig determines performance, durability, and developer experience for every workstation using the template. The host defines the Compute Engine machine type, with options for accelerators, Shielded VM and Confidential VM settings, boost configurations for alternate machine types, and pool size for pre-provisioned capacity. Storage is split between persistent directories backed by persistent disks mounted to /home and ephemeral directories lost when the VM is deleted, with a reclaim policy controlling whether the home disk is deleted or retained when the workstation is deleted.
IDE selection is encoded in the container image and its startup script, such as 110_start-$IDE.sh for Code OSS for Cloud Workstations or JetBrains IDEs accessed through JetBrains Gateway. Teams can list preinstalled IDE versions with /google/scripts/preinstalled-ide-versions.sh, copy /opt/code-oss and its startup script into another image with a multi-stage build to offer two IDEs, and pre-install Code OSS extensions from Open VSX Registry at build time or with a startup script that calls codeoss-cloudworkstations --install-extension. Default editor settings can be seeded by a startup script that writes $HOME/.codeoss-cloudworkstations/data/Machine/settings.json when a persistent home directory is configured. Security and compatibility hardening belongs in the same image pipeline, including refreshing Secure APT keys with /google/scripts/refresh-preinstalled-apt-keys.sh before apt-get update, relaying configuration variables to /etc/environment when SSH sessions need them, and setting CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO to true to remove the default user's sudo privileges.
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:
/home is created the first time the workstation starts./home in the container.When the session ends, the VM and all runtime data are deleted while the disk is detached and retained for future sessions until the workstation is deleted. Configuration changes such as a new machine type or image therefore take effect only on restart, which is why bounded timeouts matter for both cost and compliance.
Timeout and pooling controls in WorkstationConfig bound cost and accelerate starts:
| Control | What it does | Default and key rule |
|---|---|---|
| idleTimeout | Seconds without user traffic before the idle action fires | 1200s (20 minutes); 0s means never time out for idleness |
| idleAction | Action on idle expiration, either stop or suspend | Defaults to STOP; SUSPEND preserves memory state and pairs well with agent keep-alive |
| runningTimeout | Seconds before stopping a workstation regardless of activity | 43200s (12 hours); 0s means no maximum and is strongly discouraged |
The two timeouts are independent, suspending does not reset runningTimeout, and daily restarts are recommended so security updates apply. For long background work without interaction, /google/scripts/keep_alive.sh or agent keep-alive samples under /google/samples/agents/keepalive/ send keep-alive messages until the agent finishes or waits for input. For faster starts, pool size pre-creates VMs with the image pre-pulled and disks ready, image streaming reduces pull time from minutes to seconds, and changing container.image to a new tag or toggling pool size through zero forces pooled VMs to refresh to the updated image.
Cloud Shell customization, administration, and resource management is the practice of using the ephemeral Cloud Shell terminal as a secure administrative control plane while preserving work in its persistent home directory. Cloud Workstations (opens in a new tab) 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 Cloud Shell home directory, such as SAML metadata XML uploads, persist across sessions, while compute itself remains ephemeral and subject to access, quota, and storage constraints.
Secure gcloud CLI authorization establishes both user credentials for interactive commands and Application Default Credentials (ADC) (opens in a new tab) for API and client-library calls. Any user who can access the workstation or shell session can use generated user credentials or ADC to call Google Cloud as that identity, so workstations must stay single-user by default and sharing should use individual ports rather than full workstation access. The authorization flow from the terminal to Google Cloud follows an ordered sequence:
gcloud auth login --no-launch-browser and follow the prompts to authenticate the user identity.gcloud config set project PROJECT_ID to bind subsequent commands to the target project.gcloud auth application-default login to create ADC for service calls.Service account impersonation extends this model when security policy blocks direct user permissions. A workstation configuration specifies --service-account and --service-account-scopes, for example https://www.googleapis.com/auth/cloud-platform, and users of those workstations must hold iam.serviceAccounts.actAs permission on that service account to act through it.
Application Default Credentials lifecycle controls how ADC is created, stored, revoked, and recreated after suspected compromise. 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. Revocation causes a temporary outage until the file is recreated, so response plans must account for that interruption.
The owner-driven recovery path moves credentials from revocation back to a working state in order. First, revoke with gcloud auth application-default revoke. Then, if gcloud CLI cannot run, revoke access to the Google Auth Library through account permissions or the OAuth 2.0 revocation endpoint and manually delete application_default_credentials.json. Only after revocation and deletion, recreate the file with gcloud auth application-default login. A Google Workspace administrator can alternatively remove Google Auth Library access from the user's connected apps to force reauthentication.
Key and token restriction reduces the blast radius of credentials copied from Cloud Shell, workstation disks, or code repositories. When a service account key authenticates gcloud CLI, the key value is stored in gcloud CLI configuration files separately from the downloaded key file, so an attacker can steal it from either location. Administrators enforce the constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints to block creation and upload of new keys and push teams toward short-lived credentials.
Large-scale revocation of gcloud CLI sessions uses the Google Workspace Admin SDK to invalidate refresh and access tokens for the gcloud CLI client ID 32555940559.apps.googleusercontent.com. The script lists users, lists OAuth tokens per user, and removes tokens matching that client ID, which forces password or security-key reauthentication. Endpoint hygiene determines whether revocation is sufficient, so operations teams review the surrounding controls:
Diagnosing access, quota, and configuration errors in Cloud Shell separates permission failures from home-directory, federation, and token-size problems. The gcloud projects add-iam-policy-binding failure The caller does not have permission means the caller lacks rights on the organization or project instance and must be granted the required roles before retrying. Other failures trace to specific misconfigurations:
--attribute-mapping values when PATH_TO_METADATA_XML does not point to the SAML metadata file uploaded to the Cloud Shell home directory.Exam tip: Filter groups at the identity provider, such as by prefix match in Microsoft Entra ID, when authentication fails because the JWT exceeds 4KB.
Ephemeral lifecycle control bounds how long customized workstation environments run before they pick up new configuration. Administrators set an idle timeout or running timeout in the workstation configuration, and associated workstations apply the updated configuration the next time each workstation restarts. Timeouts force synchronization within a bounded period instead of allowing long-lived sessions to drift from platform updates. This mechanism links resource management to security, because least-privilege IAM changes, audit-log settings, and image updates only take full effect after restart.
generateAccessToken bearer token presented as an Authorization header or _workstationAccessToken parameter, and the token remains valid until expiration and cannot be revoked./home, so Dockerfile changes to /home are overwritten at runtime and users plus home files must be created from /etc/workstation-startup.d/ or customize_environment.$HOME/.config/gcloud/application_default_credentials.json on Linux and macOS and must be revoked, deleted, then recreated with gcloud auth application-default login after compromise.VPC Service Controls defines a service perimeter around Google-managed services that blocks data movement outside the perimeter and blocks access from untrusted locations for all user identities and all service account identities, while Chrome Enterprise Premium defines access levels and bindings that allow only user API traffic meeting conditions such as IP-based access or certificate-based access and covers only user identities within the organization. The two controls are strongest together against compromised credentials used from an attacker-controlled machine.
The caller calls the generateAccessToken API which returns a bearer token, and the caller then presents that token to the workstation as an Authorization Bearer header or as the _workstationAccessToken URL parameter that sets an authentication cookie for the browser session. 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.
The persistent disk for /home is dynamically attached at runtime and overwrites any /home changes made at image build time, so users must be added on workstation startup and per-user files such as git configuration and cloned repositories must move to a runtime script. Runtime customization should use files under /etc/workstation-startup.d/ or the per-user script at /home/user/.workstation/customize_environment which runs once in the background as user at workstation start.
Your enterprise is deploying Google Cloud Workstations for a software development team requiring custom development tooling and internal security packages. You must establish a secure lifecycle and deployment workflow for these workstations that satisfies the following requirements:
Which combination of steps should you implement to satisfy these requirements?
Last updated