Prepare and test your skills
Prepare and test your skills
Manage and Enforce Cloud SDK and Toolchain Versions is the practice of defining approved versions of command-line tools once in code and shipping 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 rebuilds and validates them, and Cloud Scheduler triggers rebuilds on a schedule. This system is operated as a custom OS image pipeline (opens in a new tab) so teams do not drift to unapproved gcloud, kubectl, Terraform, or base-image 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}$ and github_repo_name matching Developer Connect or Cloud Build v2 repository link formats.
Central definition creates a single source of truth for compatibility and security. Data flows from the Git repository to the Cloud Build trigger to the builder containers, so a change to the Dockerfile or version pin only takes effect after it is committed, built, and published. Because the repository holds both application tooling and infrastructure code, platform teams can review version bumps, vulnerability fixes, and base-image updates together before developers receive them.
Distribution of approved tooling happens through Artifact Registry repositories that host versioned workstation and OS images for all teams. A Docker-format repository is created with gcloud artifacts repositories create custom-images --repository-format=docker --location=$REGION, and Docker is authenticated with gcloud auth configure-docker $REGION-docker.pkg.dev. For OS images, the pipeline publishes generic artifacts from folder ${_IMAGE_OUTPUT_PATH} to projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_NAME/packages/PACKAGE_NAME/versions/v${BUILD_ID}, with defaults such as repository ID vm-images and package name image-builder.
The registry sits between the build system and development environments as a trust and distribution boundary. Cloud Build writes images to the registry on one side, and Cloud Workstations and Compute Engine consume images from the registry 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 for developer use.
Automated rebuilds prevent version drift by reconstructing custom images from the current approved base and toolchain definitions on every trigger. The automated pipeline follows an ordered sequence:
builder:stable container runs /build on a worker VM to parse configs and apply OS customization, system package updates, and custom shell commands.validator:stable container runs /validate on a test VM to perform system boot checks.builder:stable container runs /publish to register the image in Compute Engine and upload tar files 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, so fixes in base images are pulled in without manual action. The pipeline uses a Cloud Storage workdir bucket such as gs://STAGING_BUCKET_NAME/workdir/ for temporary logs and artifacts, with a lifecycle default of 30 days (gcs_lifecycle_age_days = 30), timeout: '3600s', and logging: CLOUD_LOGGING_ONLY. Progress is verified in the console under Cloud Build History by opening the Build ID to inspect container logs for customization steps, validation test results, and final registration.
The Google Cloud CLI (gcloud CLI) is the command-line toolchain developers use to submit builds, manage registries, and interact with Google Cloud services. Consistent installation requires installing the CLI, signing in with a federated identity when using an external identity provider, and initializing with gcloud init. Developers without a local install can use Cloud Shell in the console, which provides the CLI without local version management.
Keeping the CLI current depends on where the version lives. An existing local install is updated with gcloud components update, but that command only updates that workstation and does not update team-wide custom images. Team-wide enforcement requires committing the new version to Git and rebuilding the custom image through the pipeline, then having workstations restart from the republished image.
Exam tip: gcloud components update updates only the local CLI, while rebuilding and republishing the custom image through Cloud Build is what enforces the approved version across all Cloud Workstations.
The image customization pipeline can be submitted for immediate execution or provisioned as persistent automation, and the two paths serve different lifecycle states:
| Path | Primary action | Choose when |
|---|---|---|
| gcloud builds submit | Uploads workspace and runs cloudbuild.yaml once | A new Dockerfile or toolchain version needs an immediate, one-time build and validation |
| Terraform automation | Provisions APIs, workdir bucket, and Cloud Build trigger | Recurring, event-driven rebuilds from GitHub must be enforced automatically across teams |
Terraform provisioning itself follows a fixed order where each step depends on the prior step: first terraform init, then terraform validate, then terraform plan, and only after review terraform apply. The gcloud path depends on the same configuration files and a service account with required IAM permissions, specified with --project, --region, and --service-account=projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_EMAIL.
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. In Google Cloud, Compute Engine images (opens in a new tab) provide this baseline for VMs, Container-Optimized OS provides a minimal hardened host for containers, and Cloud Workstations provides managed development environments from centrally controlled images. Baking compliance into the image shifts security left because policy is enforced at creation time rather than fixed after launch.
Baked custom images package applications, patches, agents, and configuration into a versioned artifact that launches identically everywhere. This approach reduces boot time from boot to application readiness because software is already installed, improves reliability of deployments, and makes rollback to a previous version straightforward. Scaling up creates instances that contain identical software versions, and bootstrap has fewer dependencies on external services because the instance does not need to download everything at startup.
Compute Engine custom images can be created by manual baking, automated baking, or importing existing disks, with the choice driven by scale and audit needs.
Manual baking works for a small number of images configured from scratch. Automated baking with Packer, an open source image-building tool, makes creation reproducible, auditable, configurable, and reliable for large numbers of images and can run as part of a Spinnaker pipeline. Importing existing images uses the virtual disk import tool to automate import of RAW disks, Amazon Machine Images (AMI), and VirtualBox images, or uses Migrate to Virtual Machines with continuous block-level replication to move machines to Compute Engine and then bake them.
A hardened image release is validated by launching a test VM from the newly created image and verifying licenses, runtimes, tooling, and identity hygiene. Validation checks that valid licenses are attached through the metadata server, that Python 2.6 or greater is installed, and that baseline tools respond, including gcloud, ssh, sshd, curl, and dhcp. The check also confirms that no extra user directories or leftover credentials remain except the builder's own. Because Google updates base public images monthly, hardened images must be rebuilt and republished on that cadence so baselines do not drift behind patched sources.
Image encryption and source control ensure that baseline images protect data at rest and come only from approved publishers. All Compute Engine disks are encrypted by default with Google's encryption keys, and images built from those disks inherit that encryption. For stronger ownership, disks can be created with customer-supplied encryption keys and the keys passed to the image create command to produce an encrypted image. Trusted image organization policy constraints then limit which projects can publish images that teams are allowed to use, while Artifact Registry centralizes build artifacts with access control, Virtual Private Cloud (VPC) Service Controls perimeters, and organization policies.
Centralized artifact controls further harden the supply chain for images:
Image families manage related Compute Engine images as a versioned line so deployment automation can roll forward to the latest compliant build and roll back when needed. After an image-build pipeline is established, deployment mechanisms must reference the family pointer rather than a fixed image so they pick up the latest version, and curation must prevent old images from being used inadvertently. Deprecation moves an image through named lifecycle states in order, from warning to blocking to removal.
| State | Launch behavior | Intended use |
|---|---|---|
| DEPRECATED | Launch still succeeds with a warning that it is not the latest | Mark superseded images that remain usable during transition |
| OBSOLETE | Launch fails for new instances, but data remains mountable as a non-boot disk | Archive images that must not be launched by users or automation |
| DELETED | Launch is impossible and deletion is pending | Remove images marked for deletion as soon as possible |
Exam tip: DEPRECATED still launches with a warning, while OBSOLETE blocks creation of instances from the image.
Cloud Workstations extends the hardened-image model to developer desktops by giving administrators centrally provisioned, scalable environments with consistent configuration and customizable tooling. Traffic and access for workstations are controlled by VPC Service Controls, private ingress or egress, forced image update, and Identity and Access Management (IAM) access policies. When combined with Chrome Enterprise Premium, workstations add data loss prevention for development data.
Container and production baselines use the same chain of trust. Cloud Build runs builds on Google Cloud infrastructure with granular IAM permissions, isolated and ephemeral build environments, Support for Supply-chain Levels for Software Artifacts (SLSA) Level 3 builds for container images, and authenticated build provenance recording image digests, source locations, toolchain, steps, and duration. Binary Authorization then enforces deployment policy on Google Kubernetes Engine (GKE) and Cloud Run by checking attestations that prove the build system created the image, vulnerability policy passed, and promotion criteria from development to quality assurance were met. For runtime hosts, Container-Optimized OS, GKE Sandbox, Shielded VMs with Secure Boot, and confidential computing isolate workloads and protect execution from tampering.
Automate IDE Configuration and Extension Management is the practice of defining development environments in code so every developer receives the same editor, extensions, rules, and security checks. On Google Cloud, 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 (opens in a new tab) that rebuild IDE base images. Because the image and workspace definition are stored in version control, updating the image updates every new environment without manual installation.
Standardized IDE foundations are managed, repeatable workspaces that carry required tooling instead of relying on manual laptop setup. Cloud Workstations provides containerized, managed cloud environments, while local development uses VS Code or supported JetBrains IDEs with Cloud Code support. VS Code can also run inside a Docker container through the Dev containers extension and attach to remote hosts through remote development using SSH, so the container image becomes the versioned source of editors, CLIs, and libraries.
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. Because the image and workspace definition are stored in version control, updating the image updates every new environment without manual installation.
Automated extension integration is the pre-configuration of IDE plugins, API access, and project-specific workspace rules through scripts and configuration files. The documented pattern provisions the Developer Knowledge API for AI-assisted IDEs such as Claude Code CLI and Codex, plus Model Context Protocol (MCP) access for live environmental data. Project workspaces are further customized by embedding project-specific rules, specialized skills, and deterministic command hooks directly into the developer workspace, so coding agents follow the same steps on every machine.
Provisioning follows an ordered sequence:
gcloud services enable developerknowledge.googleapis.com --project=YOUR_PROJECT_ID to activate Developer Knowledge in the project.plugin marketplace add google/skills to register the Google plugins marketplace.plugin install google-cloud-developer@google-plugins to add mandated Google Cloud assistance to the IDE or CLI.export DEVELOPERKNOWLEDGE_API_KEY=YOUR_API_KEY before starting the CLI so the variable exists in the process environment.[mcp_servers.developer-knowledge] with url = "https://developerknowledge.googleapis.com/mcp" and env_http_headers = { "X-Goog-Api-Key" = "DEVELOPERKNOWLEDGE_API_KEY" } in ~/.codex/config.toml so requests from the workspace to the MCP server carry the key.Only after the environment variable is exported and the MCP server entry is saved can the IDE resolve knowledge requests; starting the CLI first leaves authentication unavailable until restart.
Enforcing development standards means running the same syntax, policy, and security checks in the IDE, as a pre-commit hook, and in continuous integration. Baseline scans continuously evaluate code in the IDE and CI/CD pipeline for common coding errors, hardcoded secrets, and vulnerable dependencies. Wiz Code evaluates code against security policies in the CI/CD baseline and blocks builds that do not meet standards, while Wiz Green Agent refactors the code in the developer IDE before commit when the issue is found locally and creates a pull request in GitHub or GitLab when the issue is found in the pipeline.
The same shift-left pattern applies to configuration validation:
nomos vet to confirm repository syntax is valid, and run nomos vet --clusters "" to restrict validation to semantic and syntactic checks when workstations lack access to managed clusters.Google Antigravity provides a complete agent manager and IDE experience, and Gemini Code Assist in Gemini CLI provides a terminal CLI for headless execution. Both act as collaborators that capture, test, and repair issues before human review, with specialized agents for security scanning, debugging, and red teaming invoking peer review by separate agents.
Automating base images is the use of repository triggers to rebuild custom OS images that host IDE tooling whenever the definition changes. Cloud Build triggers listen for push events on a Developer Connect second-generation repository link and launch an image-builder pipeline defined by cloudbuild.yaml and imagebuilder.yaml. The gcloud path uses gcloud builds triggers create repository with --repository set to projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME, --branch-pattern set to ^main$, --build-config for the Cloud Build path, --service-account for the build identity, and substitutions for _GCS_WORKDIR, _IMAGE_BUILDER_CONFIG_PATH, and _SERVICE_ACCOUNT. The Terraform path defines google_cloudbuild_trigger with repository_event_config and a push { branch = "^main$" } block, filename for the build config, and the same substitutions map, then applies it with terraform plan followed by terraform apply.
Rebuilds are scheduled periodically with Cloud Scheduler for security patching, so patched images flow from Cloud Storage staging workdir to image output and then to new workstations. Guardrails around those environments separate user-centric request checks from resource-centric perimeters:
| Control | Focus | Applies to |
|---|---|---|
| Chrome Enterprise Premium | User-centric access level evaluated on every API request, including IP-based and certificate-based mutual TLS conditions | User identities in the organization; rejects traffic with compromised credentials that fails device or network conditions |
| Virtual Private Cloud (VPC) Service Controls (VPC-SC) | Resource-centric perimeter within which resources can communicate and from which egress is denied | User identities and service account identities; mitigates data exfiltration when localized data is sent to cloud reasoning engines |
Additional guardrails harden the automated IDE supply chain. Cloud Key Management Service (Cloud KMS) key rings and keys provide customer-managed encryption keys (CMEK) for data at rest, OS Login with 2-Step Verification forces password or security-key reauthentication for SSH to Compute Engine resources, and organization policy constraints constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload eliminate long-lived downloaded keys in favor of short-lived credentials under least privilege.
Exam tip: Chrome Enterprise Premium rejects user API traffic that fails its conditions, while VPC Service Controls defines the perimeter in which resources can communicate for all user and service account identities.
Bootstrapping environments ties toolchain control, compliant images, and automated IDEs into one supply chain. Approved CLI and tool versions defined in Git are baked into hardened Compute Engine and container images, those images are distributed and scanned through Artifact Registry, and Cloud Workstations and IDEs consume only the rebuilt, validated images on triggers and schedules. Validation, encryption, deprecation, Binary Authorization, and perimeter guardrails then ensure every new VM or developer workspace starts compliant and stays current.
gcloud components update on individual machines.Running gcloud components update updates only that local workstation and does not update team-wide custom images. Enforcing an approved version across all Cloud Workstations requires committing the new version to Git and rebuilding and republishing the custom image through Cloud Build so workstations restart from the republished image.
Use gcloud builds submit when a new Dockerfile or toolchain version needs an immediate, one-time build and validation because it uploads the workspace and runs cloudbuild.yaml once. Use Terraform automation when recurring, event-driven rebuilds from GitHub must be enforced automatically across teams because it provisions APIs, the workdir bucket, and the Cloud Build trigger.
A DEPRECATED image still allows launch to succeed with a warning that it is not the latest and is used for superseded images during transition. An OBSOLETE image blocks creation of new instances but data remains mountable as a non-boot disk and is used to archive images that must not be launched.
Chrome Enterprise Premium provides user-centric access control evaluated on every API request and rejects user traffic that fails device or network conditions. Virtual Private Cloud Service Controls provides a resource-centric perimeter within which resources can communicate and applies to both user identities and service account identities to mitigate data exfiltration.
Your enterprise organization needs to standardize and enforce the CLI toolchain (including the gcloud CLI, kubectl, and terraform) across hundreds of developer environments and automated deployment pipelines.
You must prevent toolchain version drift, ensure developers and CI systems only consume approved and security-vetted toolchain versions, and establish a repeatable mechanism to review and promote version updates safely.
Which strategy should you implement?
Commit compiled binary executables of gcloud, kubectl, and terraform directly into each application's Git source repository.
Use Compute Engine VM Manager OS policies to enforce apt-get upgrade and yum update package executions across developers' local machines.
Configure developer shell profiles to run gcloud components update and download latest upstream binary releases of terraform and kubectl on every login session.
Host approved versioned toolchain packages and container images in a private Artifact Registry, pin toolchain versions across environments, and automate version review workflows using Dependabot.
Last updated