Prepare and test your skills
Prepare and test your skills
Integrated development and AI-driven assistance is the combination of Cloud Code (opens in a new tab) and Gemini helpers to build, test, deploy, and optimize applications without leaving the development environment. Cloud Code is an extension that brings Google Kubernetes Engine (GKE) and Cloud Run directly into the integrated development environment (IDE), so code, configuration, and cloud resources are managed in one place. Gemini Cloud Assist (opens in a new tab) adds artificial intelligence (AI) help for generating code, troubleshooting problems, and improving efficiency, cost, reliability, and security across the full application lifecycle.
Cloud Code is an IDE extension that supports the full development cycle for GKE and Cloud Run applications, from creating an app from a template to monitoring deployed resources. It provides run-ready samples and out-of-the-box configuration snippets to start quickly and reduces configuration work and context-switching during development. While it works with any cloud platform, it provides a streamlined Google Cloud experience with better integration for Cloud Source Repositories, Cloud Build, Cloud Client Libraries, and unified authentication through the Google Cloud software development kit (SDK).
Cloud Code runs in familiar editors and supports five backend languages for cloud-native development. It is available by default in the Cloud Shell Editor and can be installed in Visual Studio (VS) Code and IntelliJ and other supported JetBrains IDEs, with limited support for Android Studio. The supported languages are:
Sample applications for testing these capabilities are published in the cloud-code-samples repository, so a developer can try the build, run, and deploy flow with working code.
Gemini Code Assist Standard and Enterprise is an AI-powered collaborator integrated with Cloud Code that helps solve code problems, generate project code, and receive inline suggestions while coding. Gemini Cloud Assist extends that help across the application lifecycle to design, deploy, troubleshoot, and optimize apps for efficiency, cost, reliability, and security goals. The underlying Gemini large language models are trained on publicly available code plus Google Cloud-specific material, and requests are served as close to the user as possible where capacity is available.
How Gemini works in Google Cloud (opens in a new tab) controls what context the assistant uses and how privacy is protected. Gemini Code Assist bases its answers on the file actively used in the IDE plus other open and relevant local files, and it lists those context sources every time chat is used. Code customization can base suggestions on an organization's private codebase, and suggestions that match cited sources can be disabled in settings. Gemini for Google Cloud does not use prompts or responses for model training, does not persist contextual information such as project ID, product area, page title, and organization ID, and provides citations and applicable open source licenses when it quotes another source at length.
Exam tip: Gemini Code Assist Standard and Enterprise are not auto-enabled by default and are now a separate plugin from Cloud Code; connection requires selecting a Google Cloud project with Identity and Access Management (IAM) permissions, and Virtual Private Cloud (VPC) Service Controls must allow incoming traffic to the Cloud Code API.
Local emulation in Cloud Code is the ability to build, run, and debug cloud services on the local machine before deploying to Google Cloud. The built-in Cloud Run emulator supports developing and debugging a Cloud Run service locally, while the Apigee Emulator supports building and testing application programming interface (API) proxies with unit and manual tests without impact to dependent applications. Cloud Code works with command-line container tools such as Skaffold, minikube, and kubectl to provide local, continuous feedback as a project is built, edited, run, and deployed locally or in the cloud.
Faster iteration depends on modular development and watch mode during development and debug sessions. Skaffold supports modules that let parts of a GKE application be developed and debugged independently, with dependencies defined between skaffold.yaml configuration files and specific modules. Watch mode quickly applies changes to Kubernetes and emulated Cloud Run sessions during a session, so edits flow from the IDE to the running local environment for a faster feedback loop.
Automated deployment in Cloud Code moves tested code from the IDE to a managed runtime with less manual configuration and context-switching. For GKE, a developer can create and run a new application or work on an existing application, customize YAML with intelligent authoring support, and run it on any GKE cluster, including Arm and mixed-architecture GKE and minikube clusters. For Cloud Run, a developer can create and deploy a new service and then monitor progress with the Cloud Run Explorer and service logs in the Log Viewer.
| Runtime | Build path | Deploy and monitor path |
|---|---|---|
| GKE | Container image built from source, often with Google Cloud buildpacks without a Dockerfile | Skaffold and kubectl deploy to GKE cluster; YAML authoring manages Kubernetes configuration |
| Cloud Run | Container image built from source, often with Google Cloud buildpacks without a Dockerfile | Cloud Code deploys the service; Cloud Run Explorer and Log Viewer track progress and logs |
Container creation depends on Google Cloud buildpacks to produce secure, production-ready images from source code without requiring the developer to write a Dockerfile. That build output then flows to the chosen destination, either a GKE cluster or a Cloud Run service, where the same IDE session continues into monitoring and debugging.
Cloud Workstations (opens in a new tab) is a managed development environment service on Google Cloud that provides secure, preconfigured, and customizable cloud IDEs. Platform teams define a reproducible environment once in a template, and developers launch their own instances that run on Compute Engine virtual machines (VMs) inside the team's project and Virtual Private Cloud (VPC) network. Developers connect through a browser-based IDE, local editors such as VS Code or IntelliJ IDEA Ultimate and PyCharm Professional, or Secure Shell (SSH), which supports remote workflows without local setup scripts.
Workstation resources in Cloud Workstations form a three-level hierarchy where each level has a different owner and purpose. A cluster defines where workstations run, a configuration defines what they run, and a workstation is the running environment a developer uses.
Administrators and platform teams create workstation clusters and workstation configurations, then each developer creates a workstation based on a configuration. Updates to a workstation configuration apply automatically to its workstations the next time each workstation restarts, so platform teams can roll out machine-type, image, or policy changes consistently.
The workstation lifecycle in Cloud Workstations separates short-lived compute from long-lived data to save cost and keep environments consistent. A workstation runs on an ephemeral Compute Engine VM that exists only while the session is active, while user files persist on a separate disk. Administrators set an idle timeout and a running timeout in the workstation configuration to force shutdown of unused workstations, which reduces cost and bounds how long a workstation can drift from its updated configuration.
A workstation session moves through an ordered lifecycle:
Persistent storage in Cloud Workstations is implemented as a persistent disk that attaches at session start and detaches at session end. Because only the home directory persists, configuration changes such as a new machine type or container image take effect only after shutdown and restart, and timeouts help ensure that restart happens.
VPC integration in Cloud Workstations keeps development compute and traffic inside the customer's project, VPC, and region. When a workstation cluster is created, the team selects a project and VPC network, and Cloud Workstations provisions a Private Service Connect connection between the Google-managed controller and that VPC. The Cloud Workstations architecture (opens in a new tab) uses the controller to manage VM lifecycles through the Compute Engine API, while all workstations in the cluster sit in the cluster subnet and share a cluster-specific domain.
Client traffic flows from the developer client to the cluster gateway to the VM gateway to the container. The cluster gateway receives traffic bound for a workstation and forwards it to the correct VM instance, and each workstation has a unique hostname of the form $WORKSTATION_ID.$CLUSTER_ID.cloudworkstations.dev that the cluster routes to the running workstation. Inside the VM, a VM gateway pulls client traffic from the cluster gateway, authenticates and authorizes it, and forwards it to the container that holds the IDE and tooling defined by the configuration.
The cluster gateway is public by default, but administrators can enable a fully private gateway so only endpoints inside the private network can reach Cloud Workstations. Because VMs run inside the project VPC, teams can access VPC resources directly, apply firewall rules, enable VPC Flow Logs on the cluster subnet, and enforce scheduled disk snapshot policies on workstation disks.
Exam tip: A workstation cluster is not related to a Google Kubernetes Engine (GKE) cluster; it is a regional grouping of workstations plus a controller and gateway attached to a VPC.
Access control in Cloud Workstations follows least privilege and strong isolation between developers. The default IAM configuration limits workstation access to a single developer, so each developer gets a unique workstation instance on a distinct underlying VM. Code editors and applications run inside a container with privileged mode and root access for flexibility, but that container still runs inside the developer's own VM, so even a container escape remains confined to that VM without access to other resources.
Least privilege security controls (opens in a new tab) in Cloud Workstations depend on restricting who can change the environment and its keys:
owner and designate an Organization Admin granted at the organization level, who can set IAM policies but cannot directly manage or use keys.Direct SSH to the underlying VMs must be restricted so access is possible only through the Cloud Workstations gateway, where IAM policies are enforced and VPC Flow Logs can record access. Administrators disable direct SSH to the VM with gcloud workstations configs update using the --disable-ssh-to-vm flag for the target configuration, cluster, region, and project.
Network and image security in Cloud Workstations prevents exfiltration and keeps tooling patched without manual rebuilds by developers. A VPC Service Controls service perimeter around sensitive resources limits what workstations can reach, which helps prevent source code and data exfiltration. For controlled internet egress, Secure Web Proxy enforces granular outbound policy by source, identity, destination, and request type, provides scalable Transport Layer Security (TLS) inspection, and logs transactions to Cloud Logging with the VM Internet Protocol (IP) address that can be correlated to a workstation through platform logs.
Monitoring and patching in Cloud Workstations rely on platform services and automatic restarts. VPC Flow Logs are enabled on the cluster subnet to record network activity for all workstations in that subnet, and Security Command Center with VM Threat Detection helps detect security issues on the workstation VMs. Workstations that use Cloud Workstations base images automatically pick up security patches and configuration updates on the next shutdown and restart, and the runningTimeout value helps ensure that restart occurs. Teams that use custom images remain responsible for added packages and dependencies, and should scan additions with Artifact Analysis and rebuild images weekly or through an automated rebuild pipeline.
Command-line and console resource orchestration is the practice of deploying, scaling, monitoring, and cleaning up Google Cloud resources through both visual and programmatic interfaces. The Google Cloud console (opens in a new tab) provides the web-based graphical hub for creation and governance, while the Google Cloud command-line interface (CLI) provides the primary command-line tool for scripting and automation. Cloud Shell bridges the two by running the CLI inside the browser with the current project already selected.
The Google Cloud console is the web-based graphical interface for managing projects and resources without installing software. It serves as the primary hub where console actions call the same underlying Google Cloud APIs that command-line tools use, so work started visually can be continued in code. Console sessions sit outside the project data plane and operate across project boundaries only when IAM permissions allow it.
The console organizes orchestration into four functional areas:
Complex provisioning and detailed administrative configuration belong in the web console or developer tools, while the mobile companion app is optimized only for on-the-go monitoring, alerting, and incident triage.
Cloud Shell is a web-based command-line environment that includes the Google Cloud CLI and other tools without local installation. Cloud Shell runs on a VM that Google Cloud provisions each time the session starts from the bottom of the console, and the first session also creates a persistent $HOME directory that is restored on later visits. The provisioned VM includes the latest Google Cloud CLI with values already set for the current project, so commands run immediately after the few seconds of initialization.
Cloud Shell Editor is the built-in code editor available by default with every Cloud Shell instance. The editor lets developers browse directories, view and edit files, and maintain continued access to the Cloud Shell terminal, and it is based on Code OSS. Choose Cloud Shell when rapid terminal access is needed from the browser, and choose a local installation when persistent customization or offline work is required.
The Google Cloud SDK (opens in a new tab) is a suite of libraries and tools for interacting with Google Cloud services, including command-line tools, client libraries, IDE extensions, and emulators. The Google Cloud CLI is the primary command-line tool inside that suite for managing VMs, applications, databases, and other services from a terminal. Commands flow from the CLI to Google Cloud APIs to target resources, for example gcloud compute instances create sends a creation request from the shell environment to Compute Engine.
The CLI supports scripting and automation for continuous integration and continuous delivery (CI/CD) pipelines, infrastructure lifecycle tasks, and repeatable administration. Cloud Client Libraries provide the programmatic alternative by letting application code in Python, Go, Java, Node.js, and other languages call the same APIs directly with language-idiomatic conventions. Local emulators for Pub/Sub, Spanner, Bigtable, Firestore, and Datastore simulate service behavior for development without touching production.
| Interface | Access method | Setup required | Choose when |
|---|---|---|---|
| Google Cloud console | Browser graphical interface | Sign in, select project, enable billing | Visual creation, IAM and billing administration, and monitoring overviews are needed |
| Cloud Shell | Browser terminal from console | None, CLI preinstalled and project preset | Immediate command-line work without local installation is needed |
| Local gcloud CLI | Local terminal | Install SDK, run gcloud init, run gcloud components update | Scripted, offline, or CI/CD-driven orchestration from a workstation is needed |
Exam tip: Cloud Shell starts with the current project already configured, while a local CLI requires gcloud config set project PROJECT_ID to target the correct project.
A Google Cloud project is the organizing entity that owns settings, permissions, and metadata for all resources allocated inside it. Each project has a user-provided project name, a unique project ID such as example-id, and a Google-provided project number such as 123456789012, and each project is associated with one billing account. A project acts as a namespace where resource names must be unique inside the project but often can be reused across projects, and resources in one project cannot reach another project unless Shared VPC or VPC Network Peering connects them.
The gcloud configuration is a collection of key-value pairs that controls which project, region, and zone commands target. The configuration in Cloud Shell inherits the console project, while a local CLI depends on explicit configuration commands to establish the same trust context. Authentication then determines which identity the commands act as, either a user account from gcloud init or federated sign-in, or a service account created for automation.
A standard setup workflow moves from identity to project to defaults to access:
gcloud init to authenticate the CLI and select initial defaults.gcloud projects create PROJECT_ID to create a project, then run gcloud config set project PROJECT_ID to target it.gcloud config set compute/region REGION and gcloud config set compute/zone ZONE to avoid repeating flags.gcloud config list to check current settings, and run gcloud config configurations create NAME to save a separate named configuration.gcloud iam service-accounts create SERVICE_ACCOUNT_NAME to create a service account for workloads.gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com" --role=ROLE once per required role.Creating a project requires the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission, while selecting a project requires only a granted role on that project. Enabling APIs requires the serviceusage.services.enable permission, held through the Owner role (roles/owner) or the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin).
Resource lifecycle management is the ordered progression from project preparation through API enablement, deployment, monitoring, and cleanup using console and gcloud together. The lifecycle depends on billing and APIs first, because deployment commands fail when billing is disabled or required service APIs are not enabled. The console provides the project selector, billing verification, and API enablement flow, while gcloud provides the repeatable commands for the same steps.
Enablement uses gcloud services enable with one or more API service names, such as Artifact Registry, Cloud Build, Compute Engine, Cloud Run, Pub/Sub, Eventarc, and Cloud Scheduler. IAM lifecycle actions use gcloud projects add-iam-policy-binding with a member of the form user:USER_IDENTIFIER or serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com and a specific role. Because the --role flag controls which resources the identity can access, roles can be revoked or extended later without recreating the identity, and deleting the project removes all associated resources when temporary work is finished.
gcloud init and gcloud config set project PROJECT_ID to authenticate and target a project.Gemini Code Assist Standard and Enterprise is an AI-powered collaborator integrated with Cloud Code that helps solve code problems, generate project code, and receive inline suggestions while coding. Gemini Cloud Assist extends that help across the application lifecycle to design, deploy, troubleshoot, and optimize apps for efficiency, cost, reliability, and security goals.
Choose Cloud Shell when rapid terminal access is needed from the browser because it runs with the Google Cloud CLI preinstalled and the current project preset without local installation. Choose a local installation when persistent customization or offline work is required, which requires installing the SDK, running gcloud init, and setting the target project.
A workstation cluster is a group of workstations in a single region attached to a specific Virtual Private Cloud (VPC) network and includes a Google-managed controller and gateway. A workstation configuration is a template that defines VM machine type, persistent storage, container image, IDE, timeouts, and Identity and Access Management (IAM) access, while a workstation is the preconfigured development environment a developer creates from a configuration that runs on an ephemeral Compute Engine virtual machine with an attached persistent disk.
Last updated